SSO with Spark 2.7.3.715 on Openfire 3.10.2

Our company is currently undergoing a name change that has required me to build a brand new domain/forest along with all of its servers (exchange, sql, sharepoint), etc. The old domain has the same version of domain controllers (2012 R2) and same forest/domain level (2012 R2), it only has a different name. Openfire and Spark SSO works great on the old domain (I set it up 5+ years ago back when domain was likely in 2003 or 2008 functional level). Details as follows:

Old domain (SSO working great for 5+ years, possibly more):

Domain name: olddomain.local

DC: companydc1.olddomain.local (Server 2012 R2)

Openfire server: companyapps.olddomain.local (Server 2008)

Spark 2.6.3.12555.588

Openfire 3.7.1

New domain (SSO not working):

Domain name: ad.newdomain.com

DC: s-dc1.ad.newdomain.com (Server 2012 R2)

Openfire server: s-apps2.ad.newdomain.com (Server 2012 R2)

Spark 2.7.3.715

Openfire 3.10.2

Users on openfire server on the old domain cannot talk to users in the openfire server on the new domain (openfire servers are not linked in any way).

I have followed numerous HOW TO’s on getting SSO working, including the older one that I believe I followed 5+ years ago for the old domain, and newer ones as well such as: Openfire+Spark on Windows Server 2008 R2 with SSO , however, I am stuck on the following error @ the Spark client (warn.log):

Oct 27, 2015 11:21:37 AM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
SASL authentication failed:
  -- caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))]
  at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:196)
  at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:152)
  at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:324)
  at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:243)
  at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:1079)
  at org.jivesoftware.LoginDialog$LoginPanel.access$1400(LoginDialog.java:307)
  at org.jivesoftware.LoginDialog$LoginPanel$4.construct(LoginDialog.java:841)
  at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:141)
  at java.lang.Thread.run(Unknown Source)
Nested Exception:
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))]
  at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(Unknown Source)
  at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:192)
  at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:152)
  at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:324)
  at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:243)
  at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:1079)
  at org.jivesoftware.LoginDialog$LoginPanel.access$1400(LoginDialog.java:307)
  at org.jivesoftware.LoginDialog$LoginPanel$4.construct(LoginDialog.java:841)
  at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:141)
  at java.lang.Thread.run(Unknown Source)
Caused by: GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))
  at sun.security.jgss.krb5.Krb5Context.initSecContext(Unknown Source)
  at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
  at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
  ... 10 more
Caused by: KrbException: Server not found in Kerberos database (7)
  at sun.security.krb5.KrbTgsRep.<init>(Unknown Source)
  at sun.security.krb5.KrbTgsReq.getReply(Unknown Source)
  at sun.security.krb5.KrbTgsReq.sendAndGetCreds(Unknown Source)
  at sun.security.krb5.internal.CredentialsUtil.serviceCreds(Unknown Source)
  at sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(Unknown Source)
  at sun.security.krb5.Credentials.acquireServiceCreds(Unknown Source)
  ... 13 more
Caused by: KrbException: Identifier doesn't match expected value (906)
  at sun.security.krb5.internal.KDCRep.init(Unknown Source)
  at sun.security.krb5.internal.TGSRep.init(Unknown Source)
  at sun.security.krb5.internal.TGSRep.<init>(Unknown Source)
  ... 19 more

I’ve spent about 8 hours on this today, and have google’d the heck out of it… but to no avail.

Here are my various config files:

gss.conf (Openfire server C:\Program Files (x86)\Openfire\conf):

com.sun.security.jgss.accept {
  com.sun.security.auth.module.Krb5LoginModule
  required
  storeKey=true
  keyTab="C:/Program Files (x86)/Openfire/resources/xmpp.keytab"
  doNotPrompt=true
  useKeyTab=true
  realm="AD.NEWDOMAIN.COM"
  principal="xmpp/s-apps2.ad.newdomain.com@AD.NEWDOMAIN.COM"
  debug=true;
};

openfire.xml (Openfire server C:\Program Files (x86)\Openfire\conf):

<?xml version="1.0" encoding="UTF-8"?> <!--
    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:
        <prop>
            <name>
                <is>
                    <blah>value</blah>
                </is>
            </name>
        </prop>     Most properties are stored in the Openfire database. A
    property viewer and editor is included in the admin console.
-->
<!-- root element, all properties must be under this element -->
<jive>   <adminConsole>     <!-- Disable either port by setting the value to -1 -->      <port>9090</port>      <securePort>9091</securePort>   </adminConsole>    <locale>en</locale>    <!-- Network settings. 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. -->    <!--
    <network>
        <interface></interface>
    </network>
    -->    <!-- SPDY  Protocol is npn.     (note: npn does not work with Java 8)     add -Xbootclasspath/p:/OPENFIRE_HOME/lib/npn-boot.jar to .vmoptions file    -->    <!--         <spdy>     <protocol>npn</protocol>     </spdy>     -->    <connectionProvider>     <className>org.jivesoftware.database.DefaultConnectionProvider</className>   </connectionProvider>  <!-- sasl configuration -->
<sasl>
<mechs>GSSAPI</mechs>
<!-- Set this to your Keberos realm name which is usually your AD domain name in all caps. -->
<realm>AD.NEWDOMAIN.COM</realm>
<gssapi>
<!-- You can set this to false once you have everything working. -->
<debug>true</debug>
<!-- Set this to the location of your gss.conf file created earlier -->
<!-- "/" is used in the path here not "\" even though this is on Windows. -->
<config>C:/Program Files (x86)/Openfire/conf/gss.conf</config>
<useSubjectCredsOnly>false</useSubjectCredsOnly>
</gssapi>
</sasl>
<authorization>
<classList>org.jivesoftware.openfire.auth.DefaultAuthorizationPolicy</classList>
</authorization>  <database>     <defaultProvider>       <driver>net.sourceforge.jtds.jdbc.Driver</driver>        <serverURL>jdbc:jtds:sqlserver://s-sql2014a/openfire;appName=jive</serverURL>        <username encrypted="true">C8ZhOJQMCQiy4CorTX5GoA==</username>        <password encrypted="true">/fWIehSRPJY6PmfzJF2cQq3f1ISgVGdBkT/28N6GfzY=</password>        <testSQL>select 1</testSQL>        <testBeforeUse>false</testBeforeUse>        <testAfterUse>false</testAfterUse>        <minConnections>5</minConnections>        <maxConnections>25</maxConnections>        <connectionTimeout>1.0</connectionTimeout>     </defaultProvider>   </database>    <setup>true</setup> </jive>

krb5.ini (various locations, all Spark workstations under C:\Windows, s-dc1 under C:\Windows. openfire server under C:\ and C:\windows [was desperate, tried everywhere…]):

[libdefaults]
default_realm = AD.NEWDOMAIN.COM
default_tkt_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
default_tgs_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
permitted_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
[realms]
AD.NEWDOMAIN.COM = {
kdc = s-dc1.ad.newdomain.com
admin_server = s-dc1.ad.newdomain.com
default_domain = ad.newdomain.com
}
[domain_realms]
ad.newdomain.com = AD.NEWDOMAIN.COM
.ad.newdomain.com = AD.NEWDOMAIN.COM

AllowTGTSessionKey is set to DWORD 1 on all workstations (Windows 7 32/64bit) and the OpenFore server - it was actually set prior to being migrated from old domain to the new one also… and worked great with SSO on the old domain and old OpenFire server).

I have tried creating a keytab with both the windows ktpass and java 1.7.0’s ktab, no difference…

C:\Program Files (x86)\Java\jdk1.7.0_80\bin>ktab -k c:\xmpp.keytab -a xmpp/s-apps2.ad.newdomain.com@AD.NEWDOMAIN.COM

…and also tried…

C:\Windows>ktpass -princ xmpp/s-apps2.ad.newdomain.com@AD.NEWDOMAIN.COM -mapuser openfire.xmpp@ad.newdomain.com -pass * -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out c:\xmpp.keytab

openfire.xmpp AD account SPN info:

Object Name =  openfire.xmpp
DN      =       CN=openfire.xmpp,OU=Service Accounts,OU=Stuff,DC=ad,DC=newdomain,DC=com
Object Cat. =  CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=newdomain,DC=com
servicePrincipalNames
SPN( 1 )   =       xmpp/s-apps2.ad.newdomain.com 1+=1
SPN( 1 )   =       xmpp/s-apps2.ad.newdomain.com@AD.NEWDOMAIN.COM 1+=1

SPN’s above were set with these commands:

setspn -A xmpp/s-apps2.ad.newdomain.com openfire.xmpp
setspn -A xmpp/s-apps2.ad.newdomain.com@AD.NEWDOMAIN.COM openfire.xmpp

DNS PTR records are also created…

10.20.8.6 <----> s-apps2.ad.newdomain.com

If anyone can offer any assistance I would really appreciate it. Believe it or not out of 30 servers and dozens of services and applications this is the only single thing i have not been able to figure out on our new AD domain… and I’m starting to migrate 150 users over to the new domain now so I’d like to get this Spark SSO figured out soon!

I can post additional logs or details from new or old domains if required. Please let me know, thanks!

Give this ago, How to Setup SSO on Windows Server 2008r2/2012r2 with a Domain level of 2008r2/2012r2

more so, recreate your keytab file making sure you did #2 and #4

That was actually the first one I had followed yesterday (since it was very modern and applied to 2K12 R2), no luck (same error). I tried 2 more HOWTO’s since including the one linked in my post. I’ll look through it again, however, will report back (Oh I see you were the one who wrote it also )

I’ll be around all day, so just post if you run into any problem. I’ll do what I can to help

Cool thanks

Well I redid the config again following your guide (I delete the SPN’s and delete the AD account and started over). I am still getting the same error message on the client (Server not found in Kerberos database). Very perplexing…

I’m going to keep hacking away at this… I recall having trouble 5+ years ago on this too, but not THIS much lol…

try simplifying your krb5.ini file. remove all

  1. default_tkt_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
  2. default_tgs_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5
  3. permitted_enctypes = rc4-hmac des3-cbc-sha1 des-cbc-crc des-cbc-md5

maybe try the one in the link.

also, make sure your time is sync. I almost pulled my hair out a few days ago setting one up because of it!

Yes because I redid everything following your guide I removed those 3 lines and used a copy/paste of yours in the link:

[libdefaults]
    default_realm = AD.NEWDOMAIN.COM [realms]
    AD.NEWDOMAIN.COM = {
        kdc = s-dc1.ad.newdomain.com
  admin_server = s-dc1.ad.newdomain.com
        default_domain = ad.newdomain.com
    } [domain_realms]
    ad.newdomain.com = AD.NEWDOMAIN.COM
    .ad.newdomain.com = AD.NEWDOMAIN.COM

I just tried another freshly installed Windows 7 laptop with a new install of SPark 2.7.3, same result, so I know it’s not just my test Win7 VM, hmm…

Just to confirm, our old domain did not have a prefix like our new domain does… that said, the Kerberos REALM should include the prefix, right? It should be “AD.NEWDOMAIN.COM”, not “NEWDOMAIN.COM”, right? I’ve been using “AD.NEWDOMAIN.COM”, but just double checking…

oh, what version of java are you running on your openfire server?

Initially just what came with OpenFire 3.10.2 (under /jre folder). It shows "JAVA_VERSION=“1.7.0"” in readme.

I have since, however, installed JDK 7 Update 80 on the server… but I’m not sure if OpenFire is using it? I only installed it on there to create a keytab file earlier with the java method of doing so, I should probably remove it now… let me know if it may be the problem (although I think this error existing prior to loading Java onto the Openfire server).

you can check from the openfire admin console what version openfire is using. you’ll want to see if its using jre 1.7.u79 or lower

Java Version:
1.7.0_76 Oracle Corporation – Java HotSpot™ Client VM

hmmm…what happens if you run spark “as administrator”

Good idea, when I read that I thought, hmm, I recall issues with Spark and UAC in the distant past with users that have local-administrator rights (about 1% of our staff do) and I remember having to do something in the registry to make it work… but alas, in this case it is not the problem… the test users are regular users when running Spark, and I even tried just now making them local administrators and then right clicking and running as administrator, but it results in the same error, darn…

Any other ideas? Or care to take a peek via remote control or something? lol… only 2 ‘production’ users on the new domain so far, so can break it without too many repercussions

Willing to try anything and everything

sure…pm me the info

speedy assisted me remotely on this issue. Took about an hour of head-scratching but it turns out that our Openfire server name (xmpp.domain) was set to “chat.newdomain.com” which did not match the SPN, so it failed to authenticate. Thing is, on my old domain, the xmpp.domain was set to “chat.olddomain.com” which did not match the SPN, and SSO worked just fine, so not sure how I managed to get it to work 5+ years ago on there. But, no matter! I redid the SPN to be “chat.newdomain.com” and left the xmpp.domain Openfire property as “chat.newdomain.com” and boom, SSO worked.

Quickly rebranded 2.7.3 of Spark with company name and logos and pushed out to workstations on new domain via AD group policy, rebooted their computers and BOOM, all done!

Thanks speedy!

Hi, I am facing the same issue. Can anyone help me on this how to solve ? Appreciating your valuable help.