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:
displayName attribute length > 4 symbols
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…
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
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)
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:
That was done ofcourse, I’ve just forgot to mention it
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:
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.
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)
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…
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:
cn, name and samaccountname must not be equal if you want to fill displayname attribute
samaccountname must not contain special symbols (such ., _ and so on)
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”)
(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!
