Trying to use SSO (WIndows environment)

[JCSR]

I’m trying to use SSO with SPARK and I get the message:

Spark is unable to find the principal to use for Single Sign-On. This will prevent SSO from working.

However, if I query about SPN, I get this:

C:>setspn -Q xmpp/myxmppserver.mydomain.local@MYDOMAIN.LOCAL
Comprobando el dominio DC=mydomain,DC=local
CN=KEYTAB,OU=Service Accounts,OU=myOU,DC=mydomain,DC=local
xmpp/myxmppserver.mydomain.local
xmpp/myxmppserver.mydomain.local@MYDOMAIN.LOCAL

Se encontró un SPN existente.

So my question is, if I just installed spark, how does it know where to look for that principal to use for SSO?

Obviously, Spark connections to my Openfire server (all running under Windows) work perfectly and without any problems.

I think I have properly configured everything necessary for SSO in Openfire, but I think I am at a previous step before this can be validated, checked and/or corrected.

Thanks in advance.

Kind regards.

[speedy]

Take a look at this video I made a while ago. it should still hold true today.

How To: Video on setting up SSO/AD with Openfire

Warning…this video is pretty boring! This was my first attempt at creating a “how to” video. Hopefully someone will find it useful. The video only covers some basics. as Guus has stated in his video “…This video is intended as a demo that you can use to base your own process on. Don’t blindly follow these instructions, without giving thought to security, interoperability and performance.” Use at your own risk! feel free to use this as a reference as well

[JCSR]

I knew and followed your video. It helped me a lot and I only had to make a few small changes.
But everything you said in that video is about the Openfire server and I was wondering why Spark says it’s unable to find the primary to use for SSO.
I mean, how does Spark know which SPN to query?
In this link https://discourse.igniterealtime.org/t/sso-configuration/49064, Jay was talking about Principal vs Service Principal.
So, If Spark is looking for about Principal, how does Spark know who that user is?

Thanks in advance.

Kind regards.

[speedy]

it reads it from kerberos ticket and using dns. did you make the correct registry edits on your windows client running spark so that java can read the ticket?

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

How to Setup Openfire SSO on Windows Server 2008r2/2012r2 with a Domain level of 2008r2/2012r2 Verified DNS - Must have PTR record for openfire server or SSO will not work. Create a user account that will be used for the keytab. I used “keytab” in this example. Under account properties, check “This Account Supports Kerberos AES 128 bit encryption” On the domain controller set spn to username ‘keytab’ and other mappings. Note: The spn should match what you are using for xmpp.domain.…

mainly
On workstations make the following registry change

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

reg dword allowtgtsessionkey value 1

[JCSR]

Sorry for not mentioning it, but I had already added that entry to the registry.

C:>reg query HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v AllowTGTSessionKey

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
AllowTGTSessionKey REG_DWORD 0x1

[speedy]

can you post your logs. spark and openfire, as there may be clues there. usually the issue is related to DNS, keytab file, or incorrect case being used in the config files.

[JCSR]

First of all, thank you very much for your help.

The Spark logs are (I only logged in once after installing it).

• errors.log.0 file:
  errors.log.0 (5.9 KB)

• warn.log.0 file:
  warn.log.0 (9.5 KB)

The Openfire logs are:

• openfire.log:
  openfire.log (470.4 KB)

• stderror.log file:
  stderror.log (34 Bytes)

• stdout.log file is empty.

[JCSR]

And those are my files:

• gss.conf
  gss.conf (332 Bytes)
  This file is located in the folder “C:\Program Files\Openfire\conf”

• krb5.ini
  krb5.ini (566 Bytes)
  This file is located in the folder: “C:\Windows”

In fact, I have also copied this file in the path "C:\Windows" of the client.

And to get the xmpp.keytab file I ran this:

ktpass -princ xmpp/myxmppserver.mydomain.local@MYDOAMIN.LOCAL -crypto all -mapuser keytab@MYDOMAIN.LOCAL -pass * -ptype KRB5_NT_PRINCIPAL -out C:\xmpp.keytab

The xmpp.keytab is located in the folder: “C:\Program Files\Openfire\resources”

Thanks in advance.

Kind regards.

[speedy]

in your krb5.ini

[libdefaults]
default_realm = MYDOMAIN.LOCAL
dns_lookup_realm = false
udp_preference_limit = 1
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
allow_weak_crypto = true
rdns = false

[realms]
MYDOMAIN.LOCAL = {
kdc = mydc.mydomain.local
admin_server = mydc.mydomain.local
default_domain = mydomain.local
}

[domain_realms]
mydomain.local = MYDOMAIN.LOCAL
.mydomain.local  = MYDOMAIN.LOCAL

remove

dns_lookup_realm = false
udp_preference_limit = 1
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
allow_weak_crypto = true
rdns = false

you’re limited the enc types to old types that are now disable by default in current windows. in your AD for your keytab user account, check the box for aes128, and recreate your keytab file.

also, the logs in spark indicate that you might be having some connection issues due to certificate. or testing, in spark, set it to accept all certificates

[JCSR]

You are right, I had been doing some tests in order to replace the self-signed certificate with another one from my internal CA, and nowdays it’s working properly.

All right, I remove those lines from the libdefaults section in the krb5.ini file on both computers.

About keytab file, the keytab user in account options they are checked: user cannot change password, password never expires and this account supports 128-bit Kereros AES encryption (I was using 256 bits because I had read that nowadays you should use 256 bits).

Then I recreate the keytab file running this command:

ktpass -princ xmpp/myxmppserver.mydomian.local@MYDOMAIN.LOCAL -mapuser keytab@MYDOMAIN.LOCAL -pass * -ptype KRB5_NT_PRINCIPAL -out C:\xmpp.keytab -crypto AES128-SHA1

And it returns:

pp.keytab -crypto AES128-SHA1
Targeting domain controller: MYDC.mydomain.local
Successfully mapped xmpp/myxmppserver.mydomain.local to keytab.
Password successfully set!
Key created.
Output keytab to C:\xmpp.keytab:
Keytab version: 0x502
keysize 77 xmpp/myxmppserver.mydomain.local@MYDOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 7 etype 0x11 (AES128-SHA1) keylength 16 (0xb5758f6c602ece6afa3118798740116a)

After that, I copy the file to the right location on the openfire server.

Finally, I restart the Openfire server (I know that restarting the service is enough, but I prefer the first option).

P.S.: I have noticed that after running the keytab command, in the properties of the keytab user, in its account tab, the user login name has been changed from keytab to xmpp/myxmppserver.mydomain.local.
In fact, if I undo this change and rerun the command, it happens the same.
The user login name pre-Windows 2000 (under MYDOMAIN) is never changed

I’m using Windows Server 2022 Standard in both servers (DC & Openfire)

[JCSR]

And I get the same message:

[JCSR]

Futhermore, I had added these properties in the Openfire console (under Server Manager → System Properties):

	sasl.gssapi.config --> C:\Program Files\Openfire\conf\gss.conf
	sasl.gssapi.useSubjectCredsOnly --> false
	sasl.realm --> MYDOMAIN.LOCAL
	sasl.gssapi.debug --> true
	xmpp.fqdn --> myxmppserver.mydomain.local
	sasl.mechs.00002 --> PLAIN
	sasl.mechs.00008 --> GSSAPI
	authorization.classList --> org.jivesoftware.openfire.auth.DefaultAuthorizationPolicy

[speedy]

You should then check use single sign on and use dns. does spark not let you do this?
256 is recommended, but its only works if your JRE supports it. Older versions don’t include the needed libraries out of the box. I’m not sure if that’s changed or not.

[JCSR]

I follow your instructions and after configuring SSO (clicking on the checkbox " Use Single Sign-On (SSO) via GSSAPI" and selecting the checkbutton “Use DNS”, when I click on the login button I get this:

If I click in “Details” It give back this:

org.jivesoftware.smack.sasl.javax.SmackJavaxSaslException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
at org.jivesoftware.smack.sasl.javax.SASLJavaXMechanism.getAuthenticationText(SASLJavaXMechanism.java:127)
at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:202)
at org.jivesoftware.smack.sasl.SASLMechanism.authenticate(SASLMechanism.java:169)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:200)
at org.jivesoftware.smack.AbstractXMPPConnection.authenticate(AbstractXMPPConnection.java:897)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(XMPPTCPConnection.java:382)
at org.jivesoftware.smack.AbstractXMPPConnection.login(AbstractXMPPConnection.java:638)
at org.jivesoftware.gui.LoginUIPanel.login(LoginUIPanel.java:1273)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))]
at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(Unknown Source)
at org.jivesoftware.smack.sasl.javax.SASLJavaXMechanism.getAuthenticationText(SASLJavaXMechanism.java:124)
… 12 more
Caused by: GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null))
at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Unknown Source)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Unknown Source)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Unknown Source)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source)
… 14 more
Caused by: javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication
at com.sun.security.auth.module.Krb5LoginModule.promptForName(Unknown Source)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Unknown Source)
at com.sun.security.auth.module.Krb5LoginModule.login(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at sun.security.jgss.GSSUtil.login(Unknown Source)
at sun.security.jgss.krb5.Krb5Util.getInitialTicket(Unknown Source)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Unknown Source)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
… 21 more

[speedy]

P.S.: I have noticed that after running the keytab command, in the properties of the keytab user, in its account tab, the user login name has been changed from keytab to xmpp/myxmppserver.mydomain.local.

this is the expected behavior

[speedy]

this might require a bit more troubleshooting. try closing spark/ending the application and refresh your tgt ticket. you can do this by locking and unlocking our screen. then start spark and see if you get your username password prefilled? if not, close spark and try running as administrator.

[JCSR]

I restart the computer rather than lock and unlock it.

After that, if I start spark and I get both username and domain prefilled.

Finally, if I start spark running as administrator, I also get both textboxs prefilled, but SSO settings aren’t configured.

Once I configure SSO setting and click on login button, I get this:

org.jivesoftware.smack.sasl.SASLErrorException: SASLError using GSSAPI: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:286)
at org.jivesoftware.smack.AbstractXMPPConnection.lambda$new$2(AbstractXMPPConnection.java:407)
at org.jivesoftware.smack.NonzaCallback$ClassAndConsumer.accept(NonzaCallback.java:177)
at org.jivesoftware.smack.NonzaCallback$ClassAndConsumer.access$200(NonzaCallback.java:166)
at org.jivesoftware.smack.NonzaCallback.onNonzaReceived(NonzaCallback.java:46)
at org.jivesoftware.smack.AbstractXMPPConnection.parseAndProcessNonza(AbstractXMPPConnection.java:1440)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1700(XMPPTCPConnection.java:131)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1010)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:916)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:939)
at java.lang.Thread.run(Unknown Source)

As usual, thank you very much for your help.

Kind regards.

[JCSR]

klist command returns this:

C:>klist

El id. de inicio de sesión actual es 0:0x2213bf

Vales almacenados en caché: (4)

#0> Cliente: my_user @ MYDOMAIN.LOCAL
Servidor: krbtgt/MYDOMAIN.LOCAL @ MYDOMAIN.LOCAL
Tipo de cifrado de vale Kerberos: AES-256-CTS-HMAC-SHA1-96
Marcas de vale 0x60a10000 → forwardable forwarded renewable pre_authent name_canonicalize
Hora de inicio: 8/19/2024 19:27:56 (local)
Hora de finalización: 8/20/2024 5:27:50 (local)
Hora de renovación: 8/26/2024 19:27:50 (local)
Tipo de clave de sesión: AES-256-CTS-HMAC-SHA1-96
Marcas de caché: 0x2 → DELEGATION
KDC llamado: MYDC.mydomain.local

#1> Cliente: my_user @ MYDOMAIN.LOCAL
Servidor: krbtgt/MYDOMAIN.LOCAL @ MYDOMAIN.LOCAL
Tipo de cifrado de vale Kerberos: AES-256-CTS-HMAC-SHA1-96
Marcas de vale 0x40e10000 → forwardable renewable initial pre_authent name_canonicalize
Hora de inicio: 8/19/2024 19:27:50 (local)
Hora de finalización: 8/20/2024 5:27:50 (local)
Hora de renovación: 8/26/2024 19:27:50 (local)
Tipo de clave de sesión: AES-256-CTS-HMAC-SHA1-96
Marcas de caché: 0x1 → PRIMARY
KDC llamado: MYDC.mydomain.local

#2> Cliente: my_user @ MYDOMAIN.LOCAL
Servidor: cifs/MYDC.mydomain.local/mydomain.local @ MYDOMAIN.LOCAL
Tipo de cifrado de vale Kerberos: AES-256-CTS-HMAC-SHA1-96
Marcas de vale 0x40a50000 → forwardable renewable pre_authent ok_as_delegate name_canonicalize
Hora de inicio: 8/19/2024 19:27:56 (local)
Hora de finalización: 8/20/2024 5:27:50 (local)
Hora de renovación: 8/26/2024 19:27:50 (local)
Tipo de clave de sesión: AES-256-CTS-HMAC-SHA1-96
Marcas de caché: 0
KDC llamado: MYDC.mydomain.local

#3> Cliente: my_user @ MYDOMAIN.LOCAL
Servidor: LDAP/MYDC.mydomain.local/mydomain.local @ MYDOMAIN.LOCAL
Tipo de cifrado de vale Kerberos: AES-256-CTS-HMAC-SHA1-96
Marcas de vale 0x40a50000 → forwardable renewable pre_authent ok_as_delegate name_canonicalize
Hora de inicio: 8/19/2024 19:27:54 (local)
Hora de finalización: 8/20/2024 5:27:50 (local)
Hora de renovación: 8/26/2024 19:27:50 (local)
Tipo de clave de sesión: AES-256-CTS-HMAC-SHA1-96
Marcas de caché: 0
KDC llamado: MYDC.mydomain.local

[speedy]

not-authorized is good. that means it reading your session ticket, but there is a likely mismatch somewhere. review your openfire logs. what do you have for the system setting, xmpp fqdn?

[ilyaHlevnoy]

maybe there is a problem with the encryption method? look at this topic

Unable to connect using Single Sign-On

Yes it is, but it is still a default microsoft option when you creating keytab. Everybody who can have this problem after Windows Update (Especially Novemeber 2022 and later) recreate a new keytab file with this command: ktpass /princ xmpp/openfireserver.domain.local@DOMAIN.LOCAL -mapUser xmpp-openfire@DOMAIN.LOCAL /pass * /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out c:\file.keytaab