Need help setting up Openfire for SSO (Kerberos/GSSAPI) authentication againts Active Directory

Openfire Openfire Support
1

Hey Everyone

We’ve configured an Openfire Server (4.2.3 on Ubuntu) and tested it against our AD setup using LDAP and regular challenge/response passwords but are trying to now switch over to using SSO. We followed the instructions here: SSO Configuration to setup a new server and everything appears to be configured properly but clients still cannot authenticate with SSO/GSSAPI.

When they connect we get the error saying they are unauthorized. I’m suspected that the issue might be the keytab file but we verified the creation of it and regenerated it a second time with no change in results. We’ve also verified that the clients (ubuntu) are able to use kerberos properly by testing with kinit and klist and similarly we have verified that the XMPP service is registered in the KDC using: setspn -L openfire

We also noticed that the AD service (user) account has the checkboxes for the AES encryption but we have the DES option not checked. Perhaps we need to specify the encryption method to match in Openfire?

Any help that could be given to troubleshoot this or even get better logging would be great. Thanks.

Here is the output we get from the clients at login:

Refreshing Kerberos configuration
Acquire TGT from Cache
Principal is username@DOMAIN.NET
Commit Succeeded

May 15, 2018 3:22:19 PM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using GSSAPI: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:365)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1052)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:956)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:971)
at java.lang.Thread.run(Thread.java:748)

2

That guide is probably outdated. Try this one How To: Video on setting up SSO/AD with Openfire

3

Watched the video and found a few things that thought might make a difference, but in the end, no joy.

We changed the Service Principle in the KDC to point to jabber.dmz.domain.tld and then created a CNAME for this name to point to the actual machine hostname. We then recreated SVR records for xmpp-client and xmpp-server to point to the CNAME entry. This fixed the SSO “use DNS” and “automatically find server” options. They now work properly.

We also regenerated the keyfile explicitly stating -protocol AES128_SHA1 and moved it to the resources directory on the server.

However, we are still getting “SALSError using GSSAPI: not-authorized” when the clients try to connect to the server. We need to get this working and are fast running out of time.

The complete output from the client below. The server doesn’t seem to be providing any errors in the logs despite having debugging enabled in the openfire.xml GSSAPI directive.

Client debug output:
17:01:45 systems02:~$
Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is username@REALM.TLD
Commit Succeeded

Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is username@REALM.TLD
Commit Succeeded

Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is username@REALM.TLD
Commit Succeeded

May 16, 2018 5:02:04 PM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using GSSAPI: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:365)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1052)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:956)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:971)
at java.lang.Thread.run(Thread.java:748)

Here is the krb5.conf files (both server and workstations match):
[libdefaults]
default_realm = REALM.TLD
dns_lookup_realm = true
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac

[realms]
REALM.TLD = {
kdc = pdc-01.domain.tld
admin_server = pdc-01.domain.tld
master_kdc = pdc-01.domain.tld
default_domain = domain.tld
}

[domain_realm]
.REALM.TLD = REALM.TLD

[login]
krb4_convert = true
krb4_get_tickets = false

[logging]
kdc = SYSLOG:INFO
admin_server = FILE=/var/kadm5.log
~

Here is the gss.conf file:
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule
required
storeKey=true
keyTab="/usr/share/openfire/resource/xmpp.keytab"
doNotPrompt=true
useKeyTab=true
isInitiator=false
realm="REALM.TLD"
principal="xmpp/jabber.dmz.domain.tld@REALM.TLD"
debug=true;
};

4

I noticed today that under the server registration / SASL Mechanisms in the admin console there is NOT a checkmark next to GSSAPI offered to clients. Their used to be one here but not anymore. How do I offer GSSAPI to clients?

5

I added (through the web admin console) properties:

sasl.gssapi.config /etc/openfire/gss.conf
sasl.gssapi.debug true
sasl.gssapi.useSubjectCredsOnly false
sasl.realm REALM.TLD

Now the check mark for authenticate through GSSAPI to clients is available again and I can see the client trying to authenticate through the mechanism.

I thought I would test the keyfile to make sure it is good on the box, and it seems to be working fine…

root@wdmz-jabber-03:/home/user# kinit -V -k -t /usr/share/openfire/resources/xmpp.keytab xmpp/jabber.wdmz.domain.tld
Using default cache: /tmp/krb5cc_1484267142_0qsf7k
Using principal: xmpp/jabber.wdmz.domain.tld@REALM.TLD
Using keytab: /usr/share/openfire/resources/xmpp.keytab
Authenticated to Kerberos v5

root@wdmz-jabber-03:/home/user# klist
Ticket cache: FILE:/tmp/krb5cc_1484267142_0qsf7k
Default principal: xmpp/jabber.wdmz.domain.tld@REALM.TLD

Valid starting Expires Service principal
05/16/2018 20:13:31 05/17/2018 06:13:31 krbtgt/REALM.TLD@REALM.TLD
renew until 05/17/2018 20:13:31

6

Most annoying is that there isn’t any errors or logging for the GSSAPI login attempts on the server to help troubleshoot…

The error on the clients is still the same:

May 16, 2018 8:20:43 PM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using GSSAPI: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:365)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1052)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:956)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:971)
at java.lang.Thread.run(Thread.java:748)

7

I have no experience with SSO myself, maybe @speedy will have something to suggest.

8

I just noticed that the property xmpp.domain is set to the entire hostname (not CNAME) and tried changing it to just the domain and to the CNAME, but after doing either then I can no longer log into the admin console.

These are the current settings:
xmpp.domain wdmz-jabber-03.wdmz.domain.tld
xmpp.fqdn wdmz-jabber-03.wdmz.domain.tld

9

It almost seems like Kerberos is doing what is supposed to do but that the authorization for the user is not being accepted. Like the username from kerberos is not matching up against the LDAP user and thus the account is being denied access. Does the LDAP user mapping need to be different for SSO?

10

That is expected as your users are still with the old domain and your admin user’s JID is not matching now. You also had to change admin’s username (maybe you can still do this directly in the database). Changing domain like that is not recommended. You should go through a setup process again or start from scratch.

11

Well, I think I figured out why there isn’t any logging… The system is logging to /var/log/openfire at startup but I noticed in the admin console no logs are visible. It looks like the admin console is looking in /usr/share/openfire/logs…

12

Ok, but is this supposed to be the domain (without the host)? Or is how it configured now fine?

13

For that you will have to wait for speedy to reply. I’m not sure what is the requirement for LDAP/SSO, but usually domain should be what you want your users to login to and have in their JID (user@domain). I think it might match the hostname generally. Not sure about your case though.

14

It looks like it is supposed to be the hostname… or rather probably the CNAME so that it matches the generic name you’d want the XMPP profiles to have as their address. I just did some SQL server foo and replaced it and restarted the server and now I can login to the admin console and everything matches the CNAME.

No effect on the SASL GSSAPI problem, however.

15

Looks like the match for username is against LDAP’s sAMAccountName in AD. I just tried matching against userPrincipalName but that seemed to prevent logins from working as I think it is parsing out to username@domain.tld@jabber.wdmz.domain.tld. I’m done messing this this tonight. We might have to role out this server without SSO working which isn’t going to make some people happy.

16

This morning it hit me that maybe since the JIDs don’t match the kerberos principals for the user accounts this could be resulting in the denied access. I changed them all in the database from username@jabber.wdmz.domain.tld to just username@domain.tld as a test. I also changed the xmpp.domain property to domain.tld as well. Unfortunately… no change.

I’m still lamenting the fact that I don’t have better debugging / logging to troubleshoot things…

17

its been a busy week…so for the delay. do you still need help with this?

18

Yes, this still is not working and have run out of ideas on how to troubleshoot it more.

19

When they connect we get the error saying they are unauthorized. I’m suspected that the issue might be the keytab file but we verified the creation of it and regenerated it a second time with no change in results. We’ve also Check This Working Kat proxy verified that the clients (ubuntu) are able to use kerberos properly by testing with kinit and klist and similarly we have verified that the XMPP service is registered in the KDC using: setspn -L openfire

We also noticed that the AD service (user) account has the checkboxes for the AES encryption but we have the DES option not checked. Perhaps we need to specify the encryption method to match in Openfire?

20

It looks like it is supposed to be the hostname… or rather probably the CNAME so that it matches the generic name you’d want the XMPP profiles to have as their address. I just did some SQL server foo and replaced it and restarted the server and now I can login to the admin console and everything matches the CNAME.
Click here | Homepage