Win7 roaming profile and SSO

Spark Spark Support
1

Good day!

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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

  1. 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)

2

hmm…im more familiar with running sso against AD, so I’m not sure I’ll be much help in your case.

3

Can you change the LDAP lookup? I got the not authorized error when I had valid accounts, but they were outside of the scope of the LDAP lookup.

4

Its AD level 2008 R2 , but Samba works as a domain controller.

5

Please see the paragraph 6. The problem is not in access to Ldap.

6

I checked SSO with problematic users:

  1. By using Miranda IM - SSO works.

  2. On entering a local site with HTTP-authorization(by kerberos) - SSO works.

It 100% Spark problem. Or I do not understand anything.

7

The only other thing I can think of why it would work for some users and not other is access to the TGTSessionKey in the registry.

8

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.

9

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.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]

“AllowTGTSessionKey”=dword:00000001

10

If everything was so easy))

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.

11

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.

12

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)

13

I’m updated Spark to 2.7.6. The same problem.

14

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)

15

Finaly, I launched Spark in debug mode, log file in attachment.
spark_debug.txt.zip (1873 Bytes)

16

Spark 2.8.2. Problem still actual.

17

Hi to all!

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.

Thanx.