SSO not working (Openfire 4.5.2, Spark 2.8.3, Windows AD 2008)

Hi everyone,
i’m posting the nth post about SSO-related problem, i’m sorry for this but i’m struggling since before COVID pandemic and i’m unable to get the work done.
I’m administrator of a Windows AD, let’s call it MyDomain.it.
We had Openfire and Spark nicely working for years, but after we made AD elevation from 2003 to 2008 the service is not working. I tried several times but i got stuck in a kerberos problem.
My clients are desktop running Windows 7 or Windows 10.

Before writing the details of my installation, i wanted to state that:

  • plain auth with AD user credentials works fine
  • Spark seems unable to get the Kerberos ticket from the client windows cache (both on W7 and W10)

If i run Windows command “klist” i get the list of all the tickets granted to the user.
If i run the JRE command (both on 1.8.0_181 JRE installed on the client desktop and on 1,8,0_121 JRE inside Spark installation) they try to load the ticket from my user profile and find none.
Running the JRE command “kinit” fails with error:
<<
Exception: krb_error 14 KDC has no support for encryption type (14) KDC has no support for encryption type
KrbException: KDC has no support for encryption type (14)
at sun.security.krb5.KrbAsRep.(Unknown Source)
at sun.security.krb5.KrbAsReqBuilder.send(Unknown Source)
at sun.security.krb5.KrbAsReqBuilder.action(Unknown Source)
at sun.security.krb5.internal.tools.Kinit.(Unknown Source)
at sun.security.krb5.internal.tools.Kinit.main(Unknown Source)
Caused by: KrbException: Identifier doesn’t match expected value (906)
at sun.security.krb5.internal.KDCRep.init(Unknown Source)
at sun.security.krb5.internal.ASRep.init(Unknown Source)
at sun.security.krb5.internal.ASRep.(Unknown Source)

I’ve searched and searched, but can’t find the exact meaning of that. It can be a problem related to the so called Pre-authentication, but i don’t know nothing about this.

As far as i can understand, this problem is related completely to client side: i found the problem as soon as i open Spark UI. Even in the Advanced settings, “SSO” tab, Spark tells me that is unabe to load the user Principal.
Is it possibile that the issue is related to Java security?
Can someone tell me if he succeeded and how he did it in setting up Openfire-Spark SSO with AD 2008 or higher and client W7/W10?

Here is how i made the installation (I followed Speedy nice video posted on Oct 2017 on page How to Setup SSO on Windows Server 2008r2/2012r2 with a Domain level of 2008r2/2012r2 - #2 by speedy):

  1. DNS zone setting
    ===============

In MyDomain.it DNS zone:

New record => other record => SRV record
* Domain: MyDomain.it (OPPURE mydomain.it)
* Service: _xmpp-client
* Protocol: _tcp
* Priority: 0
* Weight: 5
* Port number: 5222
* Host offering the service: xmpp.MyDomain.it

New record => CNAME (Alias)
* Alias name: xmpp
* FQDN: xmpp.MyDomain.it (OPPURE xmpp.mydomain.it)
* FQDN for target host: record of host offering the service (openfire-srv.mydomain.it)

  1. Active Directory accounts
    =====================

New user for LDAP search
es. ldaplookup@mydomain.it

New user for SSO:
* username “keytab”
* account prop => Account: mark “This account supports Kerberos AES 128 bit encryption”

  1. SPN
    ======

    • DOS shell su AD DC with administrator privileges
      SPN creation in AD

      setspn -S xmpp/xmpp.MyDomain.it@MYDOMAIN.IT keytab

      Export del file Keytab

      ktpass -princ xmpp/xmpp.MyDomain.it@MYDOMAIN.IT -mapuser keytab@mydomain.it -crypto AES128-SHA1 -pass * -ptype KRB5_NT_PRINCIPAL -out /path/to/xmpp.keytab

Viene fuori un output che parla di keysize 73 e dell’algoritmo di cifratura 3 etype 0x11 (AES128-SHA1)

  1. Database
    =========
    USING EMBEDDED

  2. Installation & setup Openfire
    ============================

Openfire setup, then after the service is installed open browser to:
http://localhost:9090

Server Settings
* XMPP domain name: MyDomain.it
* Server Host name (FQDN): xmpp.MyDomain.it

Database Settings... none for me

Profile Settings: 
* Directory Server (LDAP)
* Server Type: Active Directory
* Host e Port di un DC di mydomain.it
* Base DN: dc=mydomain, dc=it
* Administrator DN: ldaplookup@mydomain.it
  1. gss.conf
    ========

copy under: /Path/To/openfire/conf/gss.conf

com.sun.security.jgss.krb5.accept {
	com.sun.security.auth.module.krb5LoginModule required
	storeKey true
	keyTab="/Path/To/openfire/resources/xmpp.keytab"
	doNotPrompt=true
	useKeyTab=true
	IsInitiator=false
	debug=true
	realm="MYDOMAIN.IT"
	principal="xmpp/xmpp.MyDomain.it";		
}
  1. krb5.ini
    ========

Copy on Openfire server under C:\Windows\krb5.ini

[libdefaults]
	default_realm = MYDOMAIN.IT
	
[realms]
	MYDOMAIN.IT = {
		kdc = 3v-ws008-01.mydomain.it
		admin_server = 3v-ws008-01.mydomain.it
		default_domain = mydomain.it
	}
	
[domain_realms]
	mydomain.it = MYDOMAIN.IT
	.mydomain.it = MYDOMAIN.IT
  1. keytab file
    ==========

Copy xmpp.keytab from step 3. under:
/Path/To/openfire/resources/xmpp.keytab

  1. Openfire configurations
    ====================

Server Manager => System Properties => Add new property
* sasl.gssapi.config = /Path/To/openfire/conf/gss.conf
* sasl.gssapi.useSubjectCredsOnly = false
* sasl.realm = MYDOMAIN.IT

Server Settings => Registration & Login => SASL Mechanism
Uncheck everything but “GGSAPI”

  1. Restart Openfire Service
    ======================

  2. CLIENT
    =========

    • Registry
      [HKEY_LOCAL_MACHINE]System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
      “allowtgtsessionkey”=dword:00000001

    • Spark installation

That’s all, launch Spark

Spark Advanced Settings => Tab "SSO"
* mark flag "Use Single Sign-On (SSO) via GSSAPI
* Choose "Use DNS"

tab "General" 
* Accept All certificates....

==============================================
As i said, when i open Spark i get the errors described before.
I would be very glad if someone can help me out
Thanks in advance

Max

Hi, please see my guide.
I have AD 2008r2.
But I installed Openfire on Ubuntu.

Hi ilyaHlevnoy, thnx for the response.
I checked out your guide and it seems that mine just stick to it, they’re quite similar.

There are two different things that i want to cite:

  • i’m not setting property “xmpp.fqdn” on the openfire
  • in my krb5.ini there are not default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes

[UPDATE: if i try to insert those properties on krb5.ini on my Openfire server, putting ilyaHlevnoy values, then i’m no more able to login to the administrative console with my AD account previously set as Openfire administrator. Resetting to original resolve issue]

The ckecks on my Openfire server machine looks fine to me.
The problem seems to be on the client side.

I re-run the kinit command with the Spark JRE, with debugging option activated this time, and after the command get the user password this is what is happening (i changed domain name, host names and ip):

Creating KrbAsReq
KrbKdcReq local addresses for MYW7_CLIENT are:

    MYW7_CLIENT/19.168.150.11

IPv4 address

    MYW7_CLIENT/fe80:0:0:0:91aa:debd:8b10:ed2f%11

IPv6 address

KdcAccessibility: reset
default etypes for default_tkt_enctypes: 23 16.
KrbAsReq creating message
KrbKdcReq send: kdc=myDC.mydomain.it UDP:88, timeout=30000, number of retries =3, #bytes=190
KDCCommunication: kdc=myDC.mydomain.it UDP:88, timeout=30000,Attempt =1, #bytes=190
KrbKdcReq send: #bytes read=183
Pre-Authentication Data:
PA-DATA type = 11
PA-ETYPE-INFO etype = 23, salt =

Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null

Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
Pre-Authentication Data:
PA-DATA type = 16

Pre-Authentication Data:
PA-DATA type = 15

KdcAccessibility: remove myDC.mydomain.it
KDCRep: init() encoding tag is 126 req type is 11
KRBError:
sTime is Wed Jul 01 16:37:34 CEST 2020 1593614254000
suSec is 997698
error code is 25
error Message is Additional pre-authentication required
sname is krbtgt/MYDOMAIN.IT@MYDOMAIN.IT
eData provided.
msgType is 30
Pre-Authentication Data:
PA-DATA type = 11
PA-ETYPE-INFO etype = 23, salt =

Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null

Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
Pre-Authentication Data:
PA-DATA type = 16

Pre-Authentication Data:
PA-DATA type = 15

KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ
default etypes for default_tkt_enctypes: 23 16.
default etypes for default_tkt_enctypes: 23 16.

EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
KrbAsReq creating message
KrbKdcReq send: kdc=myDC.mydomain.it UDP:88, timeout=30000, number of retries =3, #bytes=270
KDCCommunication: kdc=myDC.mydomain.it UDP:88, timeout=30000,Attempt =1, #bytes=270
KrbKdcReq send: #bytes read=98
KdcAccessibility: remove myDC.mydomain.it
KDCRep: init() encoding tag is 126 req type is 11
KRBError:
sTime is Wed Jul 01 16:37:34 CEST 2020 1593614254000
suSec is 200499
error code is 14
error Message is KDC has no support for encryption type
sname is krbtgt/MYDOMAIN.IT@MYDOMAIN.IT
msgType is 30
Exception: krb_error 14 KDC has no support for encryption type (14) KDC has no support for encryption type
KrbException: KDC has no support for encryption type (14)
at sun.security.krb5.KrbAsRep.(Unknown Source)
at sun.security.krb5.KrbAsReqBuilder.send(Unknown Source)
at sun.security.krb5.KrbAsReqBuilder.action(Unknown Source)
at sun.security.krb5.internal.tools.Kinit.(Unknown Source)
at sun.security.krb5.internal.tools.Kinit.main(Unknown Source)
Caused by: KrbException: Identifier doesn’t match expected value (906)
at sun.security.krb5.internal.KDCRep.init(Unknown Source)
at sun.security.krb5.internal.ASRep.init(Unknown Source)
at sun.security.krb5.internal.ASRep.(Unknown Source)
… 5 more

So the error is related to “pre-authentication” but i don’t know what does it mean:
what is “encryption type 14” for which my KDC has no support?

is it on your clients windows 7/10?

4.1 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Value Name: AllowTGTSessionKey
Value Type: REG_DWORD
Value: 1

If i run a klist command (Windows command on DOS shell), among other tickets i find:

#0> Client: myadusername @ MYDOMAIN.IT
Server: krbtgt/MYDOMAIN.IT @ MYDOMAIN.IT
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Contrassegni ticket 0x60a00000 → forwardable forwarded renewable pre_authent
Start Time: 7/1/2020 16:33:45 (locale)
End Time: 7/2/2020 2:33:24 (locale)
Renew Time: 7/8/2020 16:33:24 (locale)
Tipo chiave di sessione: AES-256-CTS-HMAC-SHA1-96

#1> Client: myadusername @ MYDOMAIN.IT
Server: krbtgt/MYDOMAIN.IT @ MYDOMAIN.IT
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Contrassegni ticket 0x40e00000 → forwardable renewable initial pre_authent
Start Time: 7/1/2020 16:33:24 (locale)
End Time: 7/2/2020 2:33:24 (locale)
Renew Time: 7/8/2020 16:33:24 (locale)
Tipo chiave di sessione: AES-256-CTS-HMAC-SHA1-96

So i’m thinking that the encryotion type that is being used for the auth request must be “AES-256-CTS-HMAC-SHA1-96”.

yes, sure.

I do not think.
this my “klist”
and i am use keytab “RC4-HMAC-NT”

try to recreate keytab with my encryption type, after that put it in the openfire directory. Then change krb5.ini and reboot the server.

1.3 in CMD run this command and save file openfire.keytab in drive C.

ktpass /princ xmpp/srv-chat.domain.local@DOMAIN.LOCAL /mapuser openfire@domain.local /pass * /ptype KRB5_NT_PRIN

and

2.4 Create a Kerberos configuration file and save it as krb5.ini to /etc/krb5.conf

[libdefaults]
default_realm = DOMAIN.LOCAL
default_keytab_name = /usr/share/openfire/resources/openfire.keytab
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]
DOMAIN.LOCAL = {
kdc = srvdc3.domain.local
admin_server = srvdc3.domain.local
default_domain = domain.local
}

[domain_realms]
domain.com = DOMAIN.LOCAL
.domain.com = DOMAIN.LOCAL

Windows 7 is no longer supported by Microsoft and if you are running Server 2008, it is no longer supported either. I’d build a new server from scratch on an up to date OS, using up to date clients. I imagine your problem will resolve itself.