I set xmpp.domain to "cmaohio.org’ and restarted the server and it set itself back to po-test. So, then I set it to po-test@cmaohio.org and it hosed my system!
So, I deleted and re-installed (putting back my SSO) stuff and I set the xmpp.domain value to “po-test.cmaohio.org” and that worked fine. Then I setup the SSO stuff and I can still login but the non-admin (or other users) cannot still with SSO.
I hate to bug about this. I just wanted to make it clear that is issue has not gone away for me. Still the same problem exists. Only me and another domain admin can login, the other normal users cannot. I have determined that even adding someone to the domain admins group and waiting 15 minutes (and restarting the server) did not allow the person to login properly.
According to the debug window when running the openfire in non-service mode. It looks like the user authenticates just fine. However, on the debug log it says that the user@REALM is not authorized to login as user.
My xmpp.domain value is now set to po-test.cmaohio.org my realm is CMAOHIO.ORG my domain is cmaohio.org
I don’t know where else to go. I’m giving all my domain information here, nobody hack me please.
This may be an issue related to the structure of your AD tree. Are the 2 IDs that can authenticate correctly in the same OU (or share a Parent OU)? Are the other users ins a different OU than the working IDs? I have attached a pdf diagram for a visual aid of what I am describing.
The two who can login are both in one OU, however, one of the other people who try to login is in the same OU. He’s not a domain admin but he’s in the same OU. He’s the one I made a domain admin to see if he could get in but couldn’t.
Also, remember, if I don’t use SSO, but just put in their password into the system, they authenticate and login just fine. The issue is that I want to use SSO.
what happens if you try to login and use SSO for your account on one of the problem machines. Does it work?
Yes, when I login on the machine and use SSO I login just fine.
Well then that would imply it is an account level issue. There has to be something with the way the AD accounts for the other users are configured. I do not believe from previous posts that is priviledges levels (Domain Admin vs Domain User). I would recommend creating an entirely new AD user with no specific settings other than the required group membership for openfire. If that account works compare it to the ones that don’t. Sorry I can not make it easier for you but this appears to be an AD issue, either with the accounts or the policies applied to them.
More debugging today. We have a test account we created a bit ago. “Fred Smith” this user can login with SSO. I compared him to Brad Yochum who cannot login with SSO. Their settings from pane to pane are almost identical.
The differences between them (Brad’s username is capital B and capital Y whereas Fred is lowercase) can be debunked by the fact that Me, Thomas, can login just fine and I have capitals in my username.
I have over 120 users I don’t want to have to re-create everyone just so this will work, then again, I don’t want them to have to re-input their password everytime they change their network one. Right now I am testing the system so I can’t roll this out until I get this issue fixed. This is really bad and I can’t believe it’s this hard!
If it’s any help. My AD servers are windows 2000, not windows 2003. Even though Openfire is running on a 2003 server within the domain.
Unfortunately it sounds like spark and openfire are working correctly for SSO. It sounds as if you have an issue with the AD accounts or the AD group policies that were applied.
I don’ t know what that could be. We don’t have any group policies at all except on the computers themselves. So that’s not it. So, the only thing could be new users vs old users. Although that doesn’t even work because one account was created 3 years ago that works and mine was created in january and mine works (as well as fred.smith created in june).
I just can’t imagine what possibly could be the problem.
I still don’t really have an answer to the xmpp.domain value. Should that be my realm name?
xmpp.domain can be whatever you want your server to be called. It is often a simpler configuration if it is the same as your realm, but is by no means required. Provided your realm is correctly listed in the openfire.xml you should be good to go.
SSO using GSSAPI and Kerberos is complicated because the protocols involved are complicated. That makes setting this up very hard, and complicating that fact is every install is going to be different so its almost impossible to have a single concise document for every instance.
A few more things to try/check (separately):
Have an older user change their password, then attempt a SSO login
Do the old or new users have the “use DES” option checked?
check the logs very closely for misspellings
check the logs for which authorization policies are actually being used (Look for “AuthorizationManager: Loaded” in the debug log)
From what you have said, the user is authenticating ok. The authorization code is very very simple, it consists of this:
public boolean authorize(String username, String principal) {
return (principal.startsWith(username + "@"));
}
This should be pretty easy to understand, even for non-programmers. The principal is your Windows full username, which for you will be in the form of first.last@CMAOHIO.ORG . The username is what is being requested, and should be first.last. So everything after the @ is ignored (again, this is NOT secure for multiple realm environments unless you really know what you are doing).
I’m sorry I’m getting frustrated. I know in the SSO configuration page you mention paying people to get this setup. I’m almost there, honestly. Although I don’t know if this is worth it that much for us. We’re a non-profit organization.
However, we have SUCCESS!! At least with the two users I’ve tried so far.
Based on your suggestions I first checked the DES flag in the user’s settings. Interestingly enough, my login has to allow DES but the other user who could use SSO properly did NOT (but they are a domain admin). In either case, I set two others users with DES turned on and after waiting a few minutes. they logged in just fine.
I know in the SSO configuration article it says to turn this on if you’re using windows 2003 AD and older versions of Java. Well, I have the latest java and we’re using Windows 2000 AD so I guess I glazed over that.
I’m going to start changing all the users and see where it gets me with the others.
Thanks to both of you for your hard work on this. I hope this is the last. I do have another weird thing but I’ll post that diferently, it may be an AD/filtering system or something.
Well, I come back hanging my head in shame. After setting all 100+ uses with the DES setting. I waited a bit then visited one of the users. renamed their spark folder and tried SSO, failed.
Then I changed her password logged in and out and still failed.
I’m so confused. I am going to just cool down for a bit.
SSO works fine when account name is in lower case. The comparision in code above are case sensitive.
Kerberos Principals are case sensitive, so this is correct behavior.
So, could that be my problem why it seems randomness in the way someone can use SSO and some can’t? Is the username that’s passed to the openfire system based on what they used to login with? So, if their account was setup as First.Last but they used first.last to login to their system will that fail?
I had someone on a computer using SSO logging in just fine and recently today it failed. I don’t know if she used a different login username/password or not.
I’mgoing to test it now with my own system so I guess I’ll have my answer. I guess I’m wondering, how spark knows what to use for SSO and since you can’t change it what do you do about it.
The problem is Microsoft did some weird things to the Kerberos protocol.
In order to maintain backwards compatibility with NTLM they had to treat
usernames as case insensitive. But Java implements the standard Kerberos
protocol, so you get some mismatching with Windows. Java gets the
credentials from the client, so I presume however the user logged into
the system is what Java see’s even if its not right.
Sure enough, I logged into my computer using uppercase Thomas.Deliduka instead of lowercase and I could not login to Spark/Openfire with SSO.
WHAT IS UP WITH THAT?!
I cannot set out a directive to everyone in the museum to make sure they login the way their AD login is setup (because some are upper and lower and some are all lower.)
What is the answer to this problem!
I’ll throw another wrench in the fire. As you know, if I login with “thomas.deliduka” SSO works fine, “Thomas.Deliduka” fails. However, I just looked up my user account in Active directory and it’s defined as “Thomas.Deliduka”
Now I’m completely confused!!
Look at your Kerberos principal, not the username. It may not be the
same. Its possible AD creates the kerberos principal as the lowercase
of the username. Im not as familiar with AD in this case.