I’'ll have a test server up by tomorrow morning against a test domain.
I’'ll report back if I have any success!
Abject failure I’'m afraid, even using other clients (Pandion 2.5.0)
It would seem that by adding the
to the config file. I’'ve also run filemon.exe on the server and gssapi.conf is never read by the server.
DeeJay,
Please check out this posting: http://www.igniterealtime.org/forum/thread.jspa?threadID=26606
That’'s great, thanks.
I expect that should be really help - it was the backwards ''s that seems to have messed me up.
However, there are a few typo’'s in your config which may confuse (I think). For example when specifying authentication mechanisms, I was expecting them to be comma separated?
They can be comma, space, or tab seperated. Basicly any normal delimiters should work. Note the name change though, in Openfire 3.3.1 its Loose not Lazy.
You also missed a ‘‘L’’ off class.
Your config hasn’'t change the behaviour of my Openfire instance; no logs, and no attempts to read the gssapi.conf file.
Since you don’‘t want to troubleshoot personal issues I won’‘t hassle you anymore, but I’‘m of the belief that the config instructions you gave arent’’ complete or you’'re using different software versions to me.
Openfire 3.3.1 on Windows 2003 sp1 really just won’'t work with those instructions, IMHO.
Good luck everyone - I think you’'ll need it!
If there is a typo in my directions, I would like to know about it, but I dont see any issues. Keep in mind, the directions from the WIKI are out dated, and will not work on Windows.
With the limited logging, it’'s a very tedious setup/troubleshooting process!
My current theory is that the Openfire config could be ok, but because the client does not get the service principal ticket, the server never actually needs to validate it.
I’‘ll take another look next week when I’'m less annoyed at it!
Ok, so looking at this further, and enabling debugging on the client, it would appear I’'m failing to get a ticket to access the service.
Klist.exe doesn’'t show me having a ticket for service principal xmpp/server@REALM.COM
I’‘ve set the registry key to allow exporting the TGT (which is a different key different on XP SP2 and Windows 2003 than on older OS’'s), so that should not be it.
Spark reports the following:
KinitOptions cache name is C:\Documents and Settings\username\krb5cc_username
Acquire default native Credentials
Obtained TGT from LSA: Credentials:
server=krbtgt/REALM.COM@REALM.COM
authTime=20070519095953Z
startTime=20070519095953Z
endTime=20070519195953Z
renewTill=20070526095953Z
flags: FORWARDABLE;RENEWABLE;INITIAL;PRE-AUTHENT
EType (int): 23
Principal is username@REALM.COM
Commit Succeeded
Found ticket for username@REALM.COM to go to krbtgt/REALM.COM@REALM.COM expiring on Sat May 19 20:59:53 BST 2007
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException:
No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)
]
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(Unknown
Source)
at org.jivesoftware.smack.sasl.SASLGSSAPIMechanism.authenticate(SASLGSSA
PIMechanism.java:75)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentica
tion.java:192)
Any clues?
DeeJay,
Klist.exe wont show the ticket, even if it is successful, because Java requested the ticket, and never stores it back in the LSA.
From the error message you show, its seems like it is unable to get the TGT session key. What I said about not being able to get the TGT is not entirely true- it will be able to get the TGT, but no key will be in it, so it cant really use it. You also stated that XP and Win2k3 use the same registry key, but from what I read they do not- what registry setting did you use?
Its also possible that there is a realm mismatch. That the realm you are in is not the same as the realm of the server, or that you typoed the servername, or that DNS returns a name in a different realm. Are you using SRV records? Or is your xmpp domain name an A/CNAME record to your server?
I added both reg keys; under LSA -> Kerberos and LSA -> Kerberos -> Parameters (IIRC). Anyway, I did the one you suggest in the config post.
Interestingly, it logs the same regardless of whether the setting is there or not. I’‘m beginning to wonder whether it’'s set to disallow it in a GPO. Should check really.
Also, I’‘m not sure whether the workstation requires a reboot or not after making the changes (I rebooted after turning it, but not off when I was checking the logs for differences). I’'m tempted to try an old Windows 2000 pre sp4 machine just to see if this key is my issue.
My basic is real simple; the name of the server is the name of the XMPP domain in wildfire. No aliases, no SRV records or anything fancy.
My realm is a production AD system. I presume the config needs the FQDN of the Windows domain, and in upper case? That’‘s how it’‘s configured. I’‘ve also checked the account in AD, and the attribute is set correctly (stored as xmpp/serverfqdn@AD.DOMAIN). I’‘m confident the Spark config is correct. I’'ll double check for typos though.
Would you mind posting a copy of your Spark output when it successfully connects using SSPI?
It’'d be useful to attempt to work out at which stage mine if breaking.
Message was edited by: DeeJay
No reboot is needed after making the registry change, though you will want to log out and back in.
The realm is the portion after the @ when you did a klist. There are known problems if your AD realm is lowercase, though. The realm, unlike DNS, is case sensitive. Typically it is upper case, but Ive heard of cases where the AD realm ends up lower case.
Ok, then for your service principal, you need to make sure you have the right name. Do an nslookup on the openfire server name to get the IP. Then do an nslookup on the IP to get the fqdn. This may not be the same, that is ok. So for example, lets say your xmpp domain is im.example.com, and your realm is EXAMPLE.COM.
im.example.com -> 10.12.13.14
10.12.13.14 -> server.example.com
You would use xmpp/server.example.com@EXAMPLE.COM in this case. Im apologies if you think Im beating a dead horse here- but correct DNS is vital, and since you are masking your real host names I just want to be certain.
My server is called server02.ad.com, my xmpp domain is server2.ad.com, the name looks up forwards and backwards and my service principal in the directory is xmpp/server2.ad.com/AD.COM
My domain and realm are both upper case in klist.exe.
So, it should not be DNS. I still believe that I’'m not getting a valid TGT from the credential cache.
However, I’'ll triple check all of the above for any stupid typos before I say anything else!
I’‘ll also message you the real results (no name masking) when I get back on my work network just to show you I’'ve not messed up the config!
thanks,
D
Message was edited by: DeeJay
OK, tried again and got much further.
Authentication still fails, but with " error Message is Response too big for UDP, retry with TCP"
I assume this is because of my accounts group membership and the implementations inability to use TCP for Kerberos, as is required?
D
Well - it works!
I ended up going through all the steps again and this time, it worked OK.
I’'ve still got 101 questions about the way it does actually work (cross-realm authentication changes required to the krb5.ini files, how to make the java options apply to Openfire running as a service etc etc etc) , but now have something to experiment on to answer them.
Thanks for all the help that I’‘ve been offered and I hope once I really understand this I’'ll be able to help other achieve the same.
D
edited to add: A tip to getting this to work is not to specify the Kerberos settings in the parameters for Spark and Openfire, but instead to create a krb5.ini file. Both work, but it’'s more difficulty manually passing parameters, especially when running Openfire as a service.
Message was edited by: DeeJay
Our users login to a domain other than the one on which the Openfire server is located. These two domains don’'t know about one another, and they are unrelated (no trust relationship, not in the same forest, etc).
Our users have a duplicate account on both domains (same username, same password). If they login to DOMAIN-A and Openfire is on DOMAIN-B, is SSO still possible?
Yes, it’‘s possible (I think). However, it’'ll depend on why your setup is done the way it is.
When you login to your workstation on domain A you’'re get a TGT from that domain. Your workstation will then go to domain A for the security principal for the XMPP service.
Therefore, the server will need the private key to match that.
In theory, all you need to do is export the private key from domain A and store the resulting keytab file on the Openfire Server. It won’‘t matter that the openfire server is in a different domain (or not domain at all). If you’‘ve configured LDAP against domain B that shouldn’'t matter either, as long as the user names match
However, I believe for this to work, and to validate the client, your Openfire server will need to be able to ‘‘see’’ a domain controller (KDC) from domain A.
D
It is possible, but might seem a little confusing. Set up the openfire server as if it were in domain A, ignore domain B completely. Since the realm is normally based on the domain, the service principal will look a little funny:
xmpp/server.domainb.com@DOMAINA.COM
But this is perfectly valid, and should work without a problem. But, DOMAINB.COM users will not get SSO to the server then.