Spark SSO error: Empty nameStrings not allowed

Hello. I’ve spent about 2 week testing strange error with Spark SSO login procedure with Samba4 Active Directory domain. My Openfire settings are typical and working with Miranda NG (with and w/o SSO), web client conversejs.js (w/o SSO) and Spark w/o SSO. With SSO in Spark there is a mentioned in subject error if User’s domain account satisfies at least 1 of 2 conditions:

  1. displayName attribute length > 4 symbols
  2. sAMAccountName attribute length > 9 symbols

Otherwise SSO in Spark works.
OS for clients are Windows 7 and 10 tested.
Spark versions tested are 2.9.4, 3.0.0 and 3.0.1 (all with embedded jre).
Openfire 4.7.3, build ac717b3 (works under Ubuntu 20.04 LTS server) with MariaDB backend.
Samba domain is ad.loc
Realm is AD.LOC
XMPP domain is ad.loc
OF FQDN is of.ad.loc
DNS records are fine.

Full error log:

java.lang.IllegalArgumentException: Empty nameStrings not allowed
	at sun.security.krb5.PrincipalName.validateNameStrings(Unknown Source)
	at sun.security.krb5.PrincipalName.<init>(Unknown Source)
	at sun.security.krb5.PrincipalName.parse(Unknown Source)
	at sun.security.krb5.internal.KRBError.init(Unknown Source)
	at sun.security.krb5.internal.KRBError.<init>(Unknown Source)
	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)
	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)
	at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(Unknown Source)
	at org.jivesoftware.smack.sasl.javax.SASLJavaXMechanism.getAuthenticationText(SASLJavaXMechanism.java:124)
	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)

There are no errors in Openfire and Samba.
xmpp servicePrincipal is binded to a computer account OF$ (of.ad.loc).
Tried to run Spark with smack debug - there are no raw packets, only mentioned error…

Maybe someone meet such a problem or have some thoughts to help?

Hello!
Well first Miranda NG uses NTLM and Spark Kerberos.
Secondly, for Kerberos to work in a Windows environment, all computers in the domain must have the krb5.ini file in the Windows folder, and the following steps have been taken (https://discourse.igniterealtime.org/t/openfire-sso-ubuntu-guide please see this thread):
1)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Value Name: AllowTGTSessionKey
Value Type: REG_DWORD
Value: 1

2)Create a Kerberos configuration file and save it as krb5.ini in Openfire server and in each Windows client

[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

And I see Spark can’t even find the name, for example Spark 2.9.4, the window should look like this (the user did not enter the name, it itself came from the Kerberos ticket)
image

Thanks for quick answer. Hmm, ntlm_auth is turned off on my Samba4 DC, so I think that Miranda uses GSS-API like Spark othewise Miranda won’t successfully SSO log in.
Let me answer according to your steps:

  1. That was done ofcourse, I’ve just forgot to mention it
  2. This step must be for Server and it was done ofcourse, but, as far as I know, it isn’t necessary for clients if there are DNS records configured and not using MIT Kerberos app. However, I did these steps for clients in my long testing weeks without success - trouble still here.

Also if something was wrong with Kerberos there is no way Spark was successfully SSO log in with short values of displayName and sAMAccountName attributes. Here are screenshots of successfull SSO in Spark with domain account test2:

image

image

Hm. At my last company, we used Spark 2.8.3 and Spark 2.9.4 for 5 years along with Kerberos. I remember that we had users with short last names (2-3 letters) and never had a problem.
And there were also users with long logins. Now I’ll try to find them…

We used these settings in Spark.
image

And + krb5.ini in C:/Windows folder ( It is still better to use krb5.ini, without it we encountered problems with some users. And it will be better to enter the addresses of all your DCs into it. )

For example(all user connectred via Kerberos)
We used Linux Ubuntu 16.04
All client Spark 2.9.4
login =
first letter of first name + dot + last name ( Proskuryakova Alesya = a.proskuryakova = 16 characters)

я в krb5.ini для windows и в конфиге на linux-сервере использовал

default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac

как указано тут
Configuring the krb5 file for encryption in Kerberos/SPNEGO SSO in ELM - IBM Documentation

распространил этот krb5.ini и необходимый твик реестра через gpo

sso работает

p.s.: ktpass /crypto All

By the way, RC4 and 3DES are now deprecated, try to use more secure protocols. As in the @john-doe example.

https://bugs.openjdk.org/browse/JDK-8139348

Ok, thank you all for the advices. I’ll try more with other secure protocols and maybe with other domain and realm (maybe AD is too short and is cause such bugs).
PS. In my other infrastructure with 1000 users domain ksc.loc (it is working for about 4 years now) there are almost no such problem. But sometimes some clients have this error (in different user environments). Usually we remove or add displayName to fix this for such users.

I remember that a couple of years ago we encountered the fact that the user could not connect, maybe you should also pay attention to the cache, maybe it is full and you need to increase its value.

we had 200 users online and cache Roster we did 20-30mb.
Unfortunately, I don’t remember what other values ​​we increased…
image

I did many experiments with different domain realms lengths. Well for now I figured out 4 rules to make sure that account will successfully login using SSO in Spark without “Empty nameStrings not allowed” error:

  1. cn, name and samaccountname must not be equal if you want to fill displayname attribute
  2. samaccountname must not contain special symbols (such ., _ and so on)
  3. samaccountname lenght must be less or equal 20 symbols (it is Microsoft limitation, if this attribute will be 21 or longer length than you will not be able even to login into system with error “The data area passed to a system call is too small”)
  4. (it is additional step) if you want cn, name and samaccountname to be equal you must not fill displayname attribute (it must be empty)

If your user account is capable with these 4 rules than your SSO in Spark will be successfull. Otherwise you will face troubles like I described in the my first message (if domain realm is 6 symbols long sAMAccountName attribute length must be less then 10 symbols). Maybe this info will be useful for someone who faced the same or for the developers of Spark to reproduce this error and find out how to fix it in newer versions of the app.
PS. Always relogin into system when testing SSO with different attribute lengths and values! It is very important!