For perfectly reasonable security reasons the service account password has to change once in a while.
So … we set up SSO while we knew the password and then when it was working we got the Server Admins to change the password and perform the following steps:
Change the password for each SIA and Tomcat.
Change the password in CMC under Authentication.
Create a new keytab for the Tomcat servers.
Now SSO doesn’t work.
It works to a point.
And that point is a manual log on with Tomcat.
kinit works with the wedgetail password but there’s no “credentials obtained” in the stdout.log
Anyone have any thoughts? They have to come up with a simpler way of configuring this. My tenuous grip on sanity is slipping away.
I presume you are using AD.
What happens when you update it?
CMC>Authentication>Windows AD
Are you talking about updating your password under the Java option for Tomcat?
If so, I didn’t think you needed to do that step if you were regenerating the keytab?
No. I meant changing it for the account which Tomcat is running as.
I only dropped back to the wedgetail password in the java option when the keytab wasn’t working, just tracing back to see where it was stopping working.
The password in CMC>Authentication>Windows AD is sufficient to get clients working and they work.
We stepped back so that idm.keytab is no longer in the global.properties file and the wedgetail has the password. Thus removing the keytab from the equation. At this point we should be able to use full SSO, albeit hugely unsecurely. But we’re still on manual logon via Tomcat, as per being after the step where:
Although we used mapuser in the original ktpass and it worked and our AD admin insisted we must use mapuser or no keytab would be generated he can now generate a keytab without mapuser and that works.
(BOB member since 2006-10-05)
.
(BOB member since 2005-01-06)
.