GSSAPI/Kerberos and Jabberd Domain != FQDN

Openfire Openfire Dev
1

There is an issue in the GSSAPI/Kerberos implementation.

I want my JIDs to be:

username@gurulabs.com

and not

username@mail.gurulabs.com (which is the actual host running Wildfire at the moment)

I have DNS SRV records setup to point at the actual host such as:

xmpp-client.tcp IN SRV 5 0 5222 mail.gurulabs.com.

In Wildfire GSSAPI/Kerberos auth DOES WORK if I set xmpp.domain = “mail.gurulabs.com” but if I set xmpp.domain = “gurulabs.com” (which I believe is what I need to do so I have my JIDs like I want them) then it does not work and I get the following error:

javax.security.sasl.SaslException: Failure to initialize security context Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)

at com.sun.security.sasl.gsskerb.GssKrb5Server.(GssKrb5Server.java:78)

… 8 more

Jay Kline was able to reproduce and verify this problem. For know I have to stick with jabberd2, but I would like to migrate to Wildfire as soon as this problem is fixed.

Can there be an issue opened to track this problem? (you might make it related to JM-281.

2

Hi,

is it be possible to fix your problem by changing

/*SASLAuthentication.java:193 (old 190)*/
SaslServer ss = Sasl.createSaslServer(mechanism, "xmpp", session.getServerName(), props, new XMPPCallbackHandler());

to

SaslServer ss = Sasl.createSaslServer(mechanism, "xmpp", "mail." + session.getServerName(), props, new XMPPCallbackHandler());

I know that this solution looks really ugly but if it works one may think about the necessary changes (probably an option to use a SaslServerName property).

LG

3

With windows native kerberos, you have to assign a SPN (Service Principal Name) to the account before stuff works. I’‘m not sure how you’‘d do this with Java’'s Kerberos implementation - perhaps in the gssapi.conf file.