I encountered a very strange problem during setup SSO for Spark. I will try to describe details of the problem and my attempts for solving it.
Domain Controller - Samba 4.3 on FreeBSD 10.2.
Jabber server - Openfire 4.0.1 on FreeBSD 10.2.
Jabber clients - Spark 2.7.5 on Windows 7 SP1 x64.
The whole system runs on the same local subnet.
Fun began when I started setting up clients. Next, I will list the facts that are found by now.
On my laptop with Win 7 was originally installed MIT Kerberos and after the correct DNS settings SSO worked fast enough. I used two user accounts: admin - member of Administrators group and restricted user Test. It is worth noting that due to some circumstances, these two domain user on my laptop have local profiles. All other domain users have roaming profiles.
The first user, I tried to configure SSO Spark, did not work. However, when I installed MIT Kerberos Spark was still connected. It looked like this: Login to the desired user, open the MIT Kerberos, see the tickets received by windows. Spark thus refuses to connect. Click “Get tickets” and Spark plugs for SSO.
I tried to logon the computer under my account and SSO worked. Also I tried to logon another computer under problem user and the problem there was repeated.
Then I decided to attempt adding more users and look what happens. The result is following: from 7 users SSO works with three. In this configuration file (spark.properties) all the same. I prepared it after setting up on my laptop and removed from there all the identification data, leaving only the SSO configuration and startup.
I began to look for, what is the problem for users who are not running the SSO. All of them have identical domain accounts. I decided to start experimenting with the first user who tried to install Spark. I completely remove a user from the domain profile and delete the user profile both locally and on the server copy. Then created a user with the same name and … SSO did not work.
Then I noticed the local user profiles on my laptop. I tried to remove the transferability profile and SSO worked for all users! But after the roaming profile also stopped to operate.
Drawing attention to the fact SSO depending on the roaming profile, I decided to try to rename the user directory on the server. (I already tried to change the user name before and it has not led to any result). And here I was faced with a rather puzzling result. Below I will show a list of directory names, which users breakdowns SSO and the names, which I received an error:
- I tried to add the word “test” to the directory of another user, but this also did not get a result.