What’s happening is I’ll log into my test Windows Server 2008 Terminal Server using my profile, called user1, and SSO works like a champ. I then login to a second session on the same terminal server, with user2. SSO attempts to log user2 in, but fails, advising me to check principal and server settings, blah blah. I click ok, and in the username field, user1 is listed, while the account name is *user2. *If I modify the username and log in once manually, I get in. Each subsequent SSO login for *user2 *after that initial successful manual login works beautifully. Why is it populating the username field with the previous user’s username?
One thing to note: We’re running in Server 2008 Native Mode for AD, with roaming profiles. Plus, the user profile hierarchy has changed since Server 2003. My GPO for copying a predefined spark.properties is placing the Spark\spark.properties folder and file in C:\Users*user2, *rather than *C:\Documents and Settings\user1\Spark\spark.properties. *Perhaps I’m placing the spark.properties in the wrong location? Thanks in advance for any help you guys can muster.
When you make a change in Spark preferences that affects spark.properties, at least in my roaming profile environment, it creates the Spark folder inside of c:\Users*username* and places the spark.properties inside of the new Spark folder. Is there a better location than that if you’re using roaming profiles?
are you certain that SSO is being used at all? It sounds more like its just saving the username and password. SSO should not even need your username (its in the credential cache)
Sorry, my Raw Sent would probably be better proof that the client’s at least attempting SSO. Here’s the pertinent Raw Sent data, prior to the iq roster chatter.
I dont know Windows well, and Terminal Server stuff just adds more complexity. I wonder if java is getting confused about credentials. Not sure how to go about checking that, though. Java (I think maybe only in the SDK) has a klist command- what does that show for either user?
The native Kerberos implementation in Server 2008 has a klist command, and when I run it under my account, it displays my current tickets, none of which show an xmpp spn. Should there be one? Also, does it make a difference if I use the native klist versus the one that was bundled with Java?
The native klist will not show an XMPP spn, since java dosnt retain the ticket after obtaining it. And the native client will give the correct creds, because if it didnt all sorts of other things would be broken. Im curious what java is saying, if the klist command can even read that ticket cache- it may not be able to.
OK, I think we’re getting somewhere now. The native klist does show my credentials. When I run Java’s klist in /bin, it says “Credentials cache not found”, and it’s looking for a file/folder named krb5cc_*myusername. *Java is looking for it in my Desktop folder.