Single Sign On (SSO) using OpenFire 3.2.1 and Spark 2.5.4

Amal_Graafstra · June 26, 2007, 1:48am

Hi all… we’‘ve got a strange problem with SSO and can’‘t seem to get it to work… except for one user account on one box. It seems I can only get SSO to work when I log onto the Openfire server itself as jadmin (jadmin is both a domain administrator and an Openfire administrator account). When I log into the Openfire server desktop and launch Spark 2.5.3 with SSO, it works. However, when I log onto any other box (workstation, other servers) using the jadmin domain administrator account, SSO does not work. I’'m thinking there is something seriously wrong with my setup. Might it have something to do with the fact my JIDs are user@mydomain.com while my internal fqdn is different?

I’'ve read the following posts and tried to understand them as best as I could:

http://wiki.igniterealtime.org/display/WILDFIRE/ConfiguringOpenfirefor+Kerberos

http://www.igniterealtime.org/forum/thread.jspa?threadID=26606&tstart=375

http://www.igniterealtime.org/forum/thread.jspa?messageID=148242&#148242

I am not using the startup BAT files referenced in one of the posts, should I be? I’'m also not sure if I need SRV records or how to go about ensuring they are correct.

Here’'s our setup:

Openfire 3.3.1 on Windows Server 2003 SP2 domain member, host name: jhost.mydomain.NET
Openfire configured Server Name: jabber.mydomain.COM
Spark 2.5.3 client on Windows Server 2003 SP2 Terminal Server (domain member)
Openfire using LDAP to Active Directory
Openfire running as Windows service under domain account: mydomain.net\openfire
Openfire host server and all client machines have JRE 6 installed with JCE
Created keytab file using ktpass util, version 5.2.3790.3959:

ktpass -princ xmpp/jhost.mydomain.net@MYDOMAIN.NET -mapuser openfire@mydomain.net -pass xxxxxxxx -out jabber.keytab

Is the WARNING and KRB5_NT_UNKNOWN normal ? :

Targeting domain controller: kdcserv.mydomain.net

Using legacy password setting method

Successfully mapped xmpp/jhost.mydomain.net to openfire.

WARNING: pType and account type do not match. This might cause problems.

Key created.

Output keytab to jabber.keytab:

Keytab version: 0x502

keysize 81 xmpp/jhost.mydomain.net@MYDOMAIN.NET ptype 0 (KRB5_NT_UNKNOWN) vno 14 etype 0x17 (RC4-HMAC) keylength 16 (0x16e4e111f29a8fa04d8bf546fafe5919)

When I run “klist tickets” I see (not xmpp/jhost.mydomain.net ?):

Server: host/jhost.mydomain.net@MYDOMAIN.NET

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

End Time: 6/17/2007 3:16:13

Renew Time: 6/17/2007 3:16:13

Created PTR record for jhost.mydomain.net in DNS
Set “openfire” domain account to “User cannot change password”
Set “openfire” to enable “Password never expires”
Set “openfire” to enable “Use DES encryption types for this account”
Set “openfire” delegation to “Trust this user for delegation to any service (Kerberos only)”
After running ktpass, “openfire” account “User logon name” was set to: xmpp/jhost.mydomain.net
I checked NTFS file perms for “openfire” domain account access to jabber.keytab file on Openfire host and they’'re good
I updated the regsitry on the spark terminal server: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters allowtgtsessionkey (1)
Here is my gss.conf file:

com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab=“C:/Program Files/Openfire/conf/jabber.keytab” doNotPrompt=true useKeyTab=true realm=“MYDOMAIN.NET” principal=“xmpp/jhost.mydomain.net@MYDOMAIN.NET” debug=true; };

I added the
And still, I can use SSO with the jadmin user account if I log directly into the host running Openfire and launch spark from there. Oddly enough though, SSo does not work on the same host using a typical domain user account.
On any host I can still log in with jadmin or any standard domain user by using spark and standard username/password entry.

Jay · June 26, 2007, 3:42am

First of all, yes your JID must match your username (unless you are using something from the latest subversion and really know what you are doing, and are using a client different from spark). The future will likely fix this.

Next, SRV records can make it tricky, you need to make sure you have all the names correct. Having a different domain from the realm is not inhertly a problem, but you might need to take a few extra steps. I assume you have this for DNS; please double check and report anything inconsistant:

xmpp-client.tcp.mydomain.com IN SRV 0 0 5222 jhost.mydomain.net.

jhost.mydomain.net. IN A some.I.P.address

If you have any CNAME’'s in the mix, please let me know. If not, make sure you set the property xmpp.fqdn (in the admin page) to jhost.mydomain.net (this is vital)

The principal you created needs to be xmpp/jhost.mydomain.net@MYDOMAIN.NET When you run the ktpass command, I dont think you should be specifying the domain portion in the mapuser paramater (ie use username not username@domain) I think this may be why you are getting the NT_UNKNOWN error, but Im not 100% certain of that. Also, you dont need the “Use DES” option for any accounts if using Java 6. That is really only needed for certain versions of Java, and is dependent on what encryption options you have availible in your country.

You will not see a ticket for Openfire in your klist output. This is because when Java requests the ticket, it adds it to its own internal credential cache, and never puts it in the LSA. I wish this were different, it would make debugging much easier.

Not using the .bat file is ok, assuming you have set up the krb5.ini file correctly. You will need to have this file on the server and each client. The registry setting is only needed for clients, but since its nice to test things on the server sometimes its not a bad idea to put the registry setting there. Make sure you use the propper setting for the OS.

The SOCKS5 error is completely unrelated to SSO.

The second error you are getting seems to be related to compression, and not SSO. Are you able to sucessfully log in to Openfire without SSO if you add PLAIN to the list in your openfire.xml? Looking at the spark debugging output, it seems the client never attempted to use GSSAPI and fell back to an iq auth packet (which fails, since it has an empty password). Are you sure the admin account is really using GSSAPI? It sounds like it may be getting in some other way, like a saved password or something.

Can you post the contents of your krb5.ini?

Amal_Graafstra · June 26, 2007, 8:34pm

Hi SP,

One thing that might not be clear here is that the entire mydomain.net network is a private, internal network while the mydomain.com zone is has public IPs used to accessing services inside the internal network.

I also made a couple version mistakes in my post, I’‘m running openfire 3.3.1 not 3.2.1… and the client I was using on the jabber host box is Spark 2.5.3. I just upgraded the client to 2.5.4 and now that one instance on that one box where SSO was working, no longer works. I’'ve tried specifying both internal (jhost.mydomain.net) and external (jabber.mydomain.com) as the server and it errors for both.

I then re-ran the ktpass command with your suggestions and I got back this:

====================

Targeting domain controller: kdcserv.mydomain.net

Using legacy password setting method

Successfully mapped xmpp/jhost.mydomain.net to openfire.

WARNING: pType and account type do not match. This might cause problems.

Key created.

Output keytab to jabber.keytab:

Keytab version: 0x502

keysize 81 xmpp/vm-jabber.morpheusinc.net@MORPHEUSINC.NET ptype 0 (KRB5_NT_UNKNOWN) vno 15 etype 0x17 (RC4-HMAC) keylength 16 (0x16e4e111f29a8fa04d8bf546fafe5919)

====================

The only difference I can see is in the last line, the vno is 15 and not 14 as it was previously. I copied the new jabber.keytab file over and restarted openfire.

I double checked my DNS settings and this is what I have (notice COM in address):

xmpp-client.tcp.mydomain.com SRV 0 0 5222 jabber.mydomain.com

jabber.mydomain.com A some.ip

xmpp-client.tcp SRV 0 0 5222 jhost.mydomain.net

jabber.mydomain.com A some.ip

Here is the contents of the krb5.ini file on both the jabber host box and the other boxes I’'ve tried to run SSO on:

====================

default_realm = MYDOMAIN.NET

forwardable = true

proxiable = true

MYDOMAIN.NET = {

kdc = vm-bdc-im.mydomain.net

kdc = vm-bdc.mydomain.net

kdc = vm-admin.mydomain.net

admin_server = vm-admin.mydomain.net

default_domain = mydomain.net

}

.mydomain.net = MYDOMAIN.NET

mydomain.net = MYDOMAIN.NET

autologin = true

forward = true

forwardable = true

encrypt = true

====================

After attempting to use SSO with Spark 2.5.4 on the jabber host box, trying to connect using server jhost.mydomain.net, here are the log file entries:

WARN:

2007.06.26 13:28:48 SaslException

javax.security.sasl.SaslException: Failure to initialize security context Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new ACCEPT credentials failed!)

at com.sun.security.sasl.gsskerb.GssKrb5Server.(Unknown Source)

at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)

… 20 more

Caused by: javax.security.auth.login.LoginException: Unable to obtain password from user

at com.sun.security.auth.module.Krb5LoginModule.promptForPass(Unknown Source)

at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Unknown Source)

at com.sun.security.auth.module.Krb5LoginModule.login(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at javax.security.auth.login.LoginContext.invoke(Unknown Source)

at javax.security.auth.login.LoginContext.access$000(Unknown Source)

at javax.security.auth.login.LoginContext$5.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.login.LoginContext.invokeCreatorPriv(Unknown Source)

at javax.security.auth.login.LoginContext.login(Unknown Source)

at sun.security.jgss.GSSUtil.login(Unknown Source)

at sun.security.jgss.krb5.Krb5Util.getKeys(Unknown Source)

at sun.security.jgss.krb5.Krb5AcceptCredential$1.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

… 26 more

The log file entries look identical when trying to log in from an outside client to jabber.mydomain.com (using SSO). These outside client boxes are domain clients that are authenticating to the domain properly, but they don’‘t have access to the private network that the jabber host is operating on, that’'s why they must attempt a connection from outside using jabber.mydomain.com.

Jay · June 26, 2007, 8:51pm

You have a very confusing setup- and it might make sense to try things out on a test server without the SRV records, and have the xmpp.domain equal to the xmpp.fqdn. Once you get that working, try adding the SRV records and changing the domain- gradually build up what your network looks like.

Comments:

kvno stands for key version number. Each time you make a new key it will be incremented, this is a good thing. I dont know what the pType/Account Type error means, Ive never encountered that one before.

In your krb5.conf, add morpheusinc.com and .morpheusinc.com to the domain_realm section. I dont think that is your problem, but it might cause one later.

Your gss.conf has the principal as xmpp/vm-jabber.morpheusinc.net@MORPHEUSINC.NET right? The error you are getting looks like the server wants to use a principal that is not in the keytab.

The hosts you have outside your network- is there any way for them to reach the jabber server at all? If you use port forwarding through a firewall/bastion host things will fail, since the client will request a principal based on the name of that host and not the server itself. Split-horizon DNS only works properly when you have a clear separation between the sides- having a client someplace in between will make things break from time to time.

Amal_Graafstra · June 26, 2007, 9:02pm

it might make sense to try things out on a test server

Yeah, I’‘ve set that up already but started out trying to duplicate what we’‘ve got already. I’'ll go ahead and do the build-up approach.

If you use port forwarding through a firewall/bastion host things will fail…

Yeah, I’'m trying to run these connections from outside the private network in through a load balancer. Makes sense that it would fail.

At the time we put up the server, SSO was an afterthought. But, with the obvious advantages it has become a primary goal. I’'ll reconstruct our test environment and do this one step at a time.

Thanks for your help SP!

Jay · June 26, 2007, 9:20pm

If you need things to work through the load balancer, it is still possible but you start wandering into some pretty advanced areas. I suggest a support contract with Jive and maybe even using their professional services. To get it working will require perhaps more intimate details of your network than you want to post in a public forum.

Amal_Graafstra · June 26, 2007, 9:22pm

agreed.

thanks!

Amal_Graafstra · June 26, 2007, 9:49pm

PS, I ran the ktpass util using the option -ptype KRB5_NT_PRINCIPAL and was able to create a keytab file with no warning. Just thought that might help someone in the future.

Amal_Graafstra · June 26, 2007, 10:17pm

Hmm… I just ran a “klist tgt” command and found a very strange character at the end of the DomainName, TargetDomainName, and AltTargetDomainName listings. The domain/realm is correct, but there is an ASCII character at the end that looks like a spade (ASCII Char 6).

I’'m betting that could cause some serious issues. My question is, which may be well beyond the scope of this forum and definitely this post… how do I fix that?

Jay · June 27, 2007, 12:24pm

I have no idea. You might try asking on the MIT kerberos mailing list, though.