Let me start off by saying I have a running Openfire 3.7.0server working with NTLM and the spark client 2.5.8 but mostly 2.6.0. Myissue becomes when I try to get the sso w/ GSSAPI to work.
On the domain controller (Win 2003 STD):
Created an account in AD called xmpp-openfire put it domainusers group /Cannot change password/password never expires/ Do not requireKerberos preauthentication
setspn -A xmpp/jabber.gsprecision.com@GSPRECISION.COMxmpp-openfire
ktpass -princ xmpp/jabber.gsprecision.com@GSPRECISION.COM -mapuser email@example.com -pass * -ptype KRB5_NT_PRINCIPAL
On Jabber (openfire 3.7.0 server):
From the c:\Program Files\Java\jre6\bin
ktab -k xmpp.keytab -a xmpp/jabber.gsprecision.com@GSPRECISION.COM NOTE: I have also tried creating the keytab file from the DC itself
Moved the xmpp.keytab into c:\Program Files (x86)\Openfire\resources
Created a gss.conf file:
com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab="C:/Program Files (x86)/Openfire/resources/xmpp.keytab" doNotPrompt=true useKeyTab=true realm="gsprecision.com" principal="xmpp/Jabber.firstname.lastname@example.org" debug=true;
<?xml version="1.0" encoding="UTF-8"?>
Edited the openfire.mxl and addes the sasl section
This file stores bootstrap properties needed by Openfire.
Property names must be in the format: "prop.name.is.blah=value"
That will be stored as:
Most properties are stored in the Openfire database. A
property viewer and editor is included in the admin console.
-<!-- Networksettings. By default, Openfire will bind to all network interfaces.
Alternatively, you can specify a specific network interfaces that the server
will listen on. For example, 127.0.0.1. This setting is generally only useful
on multi-homed servers. -->
-<!-- Include acomma-separated list of the authentication mechanisms
to advertise support for to clients. Make sure GSSAPI is listed,
and best if it's listed first. The order of mechanisms is important;
clients should try to use the first mechanism they support
(although not all will). Some clients will try to use the most
You can add other mechanisms in order to support non-GSSAPI clients,
or clients who cannot authenticate to the realm (like Windows 9X,
off-site, and so on). Keep in mind that by allowing other mechanisms
you are compromising the security of your realm. Be sure to talk
to the Security Officer/Directory/Manager/Administrator about any
policies your organization might have before enabling less secure
mechanisms. By removing PLAIN and ANONYMOUS from the list, you will
also disable non-SASL authentications.
Keep in mind that a mechanism listed here might not actually be
advertised, such as when the authProvider can't support the mechanism.
PLAIN and ANONYMOUS mechanisms also enable non-SASL authentication
(the old style XMPP auth), so removing them from this list will
disallow non-SASL authentication. -->
-<!-- Use true toturn on debugging information. This adds a lot
of noise to your log files, but it can help you spot problems
sooner in the initial setup. -->
“c:/Program Files(x86)/openfire/conf/gss.conf” NOTE: I have also tried the slashes both ways and just /Program Files(x86)/openfire/conf/gss.conf
-<!-- Sets thesystem property with the same name. You’ll probably want
"false" here (the default). For more details, see
On the client:
Windows 7 / XP SP3 running Spark 2.6.0
Checked the reg and the key was already there.
Value Name: AllowTGTSessionKey
Value Type: REG_DWORD
When we start debugging I do not see any errors but get the message on the client Unable to connect using Single Sign-On. Please check the principal and server settings. Some other users are getting Unable to determine whe SSO is checked. When I turn debugging on in the client I do not see any error but I do not get anything in the All Packets section. and I do not see any errors that stand out any other place.