I’ve looked over countless posts about getting SSO to work and none seem to quite apply. I have SSO working, it did so ‘out of the box’ so to speak, but it randomly doesn’t work for some users.
I had issues with it once before but discovered that was due to the AD account openfire was using being a regular user, not a domain admin. We fixed this problem and then had to make some changes to the server, including hostname. At that point I made sure to reconfigure openfire since the hostname change caused everything to stop working. Before the hostname changed everyone we’d set spark up for so far had been able to use SSO without any problems. Once the hostname changed and we reconfigured it most that could before were still able to use SSO, however one suddenly could not. Other new users being added to the system could not use it either. I have yet to determine if no new users will be able to use it, or if this is an isolated problem for those few that currently can’t. I can’t seem to come up with any common factor between those users either.
This is almost entirely a windows setup, AD is on server 2003, the client machines are all windows XP SP2+. The only linux machine is the openfire server.
Any help or suggestions would be greatly appreciated!
In attempting to pin down the exact cause of the problem I tried reinstalling the server and reconfiguring it. This had almost no change except that a couple more users were suddenly able to use SSO.
I also enabled the debugger console on the clients to see if I could find any useful information and discovered this. In the information it sends to the server it sends a packet/message that should look like this:
testuser
password.here
spark
however the clients that are unable to connect send this:
testuser
spark
The password is missing which would definitely cause a login problem… does anybody know why this might be happening and how to fix it?
openfire user a domain admin? that seems excessive, my openfire user is definitly not a domain admin, its not even an admin of the server.
Are you sure those that are working are actually working? Is it possible they have stored passwords, since when sso fails it will fallback to a stored password (if there is one).
Anyway, kerberos is very picky about hostnames, so more than likely your spn is incorrect on that domain account as well as the key openfire is using is probably wrong now.check the keytabs you have setup for that user with the command:
setspn -l
to list any keytabs. you can then do setspn -d xmpp/hostname username to delete it
then recreate the keytab.
before doing the last steps I would be doubly sure people using sso are actually using sso, open their spark.properties file and remove the password line if it exists.
SSO can be pretty tricky. Everything is case sensitive. Also, if you have a dns server, you’ll need to make sure your PTR record for your server is correct.