SSO w/ GSSAPI failing OF 3.7 SP 2.6 NTLM works

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/

ktpass -princ xmpp/ -mapuser -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/  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: {



 keyTab="C:/Program Files (x86)/Openfire/resources/xmpp.keytab"





Edited the openfire.mxl and addes the sasl section
<?xml version="1.0" encoding="UTF-8"?>


    This file stores bootstrap properties needed by Openfire.
    Property names must be in the format: ""
    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, 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
        secure first.
        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
Value: 1
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.