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.
System configuration:
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:
SSO works:
administrator
ajaickaja
eabramovatest
tsmirnova
msimanov
NOT work:
eabramova
eabramova1
eabramova2
eabramova3
eabramova123
akopylcov
akopylcovtest
akopylcov1
mkaravaeva
aborzenko
I tried to add the word “test” to the directory of another user, but this also did not get a result.
Does anybody know what is the problem, and how to make SSO working for all users? Can anybody suggest a solution? debug.log.zip (693 Bytes) warn.log.zip (451 Bytes)
What do you mean? More in detail, please. So far, I have established a strict dependence of SSO work of the directory name for the synchronization on a server. Tomorrow I will try without leaving the system change the setting in the registry, in which the path to the directory on the server, and see what happens.
Make sure that all client computers have this key enabled that you are testing on. It sounds like the users cannot access this key to make Kereberos work. Without this key the users will not be able to get SSO working.
Please look at the screenshot, which I added to the first post. According to it, we can say that Spark sees the principal, but does not want to use the ticket.
Without registry parameter Spark does not see principal name.
Not sure, we do not have roaming profiles in our environment for reasons just like this. Those were the things I had to get through to get it working. It could very well be a deep Kereberos issue.
I used WireShark to see the work of Kerberos. We discover interesting facts. In those cases when SSO is not working, Kerberos uses the UDP protocol instead of TCP. Enclosed logs Wireshark. All other Kerberos traffic use TCP. The only exception is packets in logs(attachment to this post). not_work.pdf (25815 Bytes) work.pdf (30546 Bytes)
So, I was collect information about Spark through ProcMon. In full version - starting, connecting and stopping Spark, processes filtered by name “Spark.exe”. In lite - processes, collected only when Spark connect to server, but without filtering. error_full.7z.zip (1586773 Bytes) success_full.7z.zip (1634139 Bytes) error_lite.7z.zip (94979 Bytes) success_lite.7z.zip (853039 Bytes)
Spark 2.8.3 with options “Disable certificate hostname verification” and “Accept all certificates”. SSO fine works for all users. So, the problem is solved.
