Spark 2.6.0 SSO Problem

Spark Spark Support
1

Hi all,

I have been using Spark 2.5.8 with Openfire 3.6.3, XP SP3 and SSO on our domain for a long time now with no problems. We are planning a Windows 7 upgrade and I decided to test Spark 2.6.0 as part of the Windows 7 deployment but I cannot get SSO working. When I try to login I get the error “Unable to connect using Single Sign-On. Please check your principle and server settings”. If I upgrade an existing working XP client to Spark 2.6.0 I get the same error. The only thing that is changing is the Spark version which seems to break SSO. When I check each clients SSO settings under the Advanced - SSO tab, version 2.5.8 reports the Desktop Account as “USERNAME” where as version 2.6.0 reports the Desktop Account as USERNAME@DOMAIN_NAME.LOCAL. This is the only thing that I can identify as different between the two versions. Please help - any advice greatly appreciated.

2

There is an issue recorded for that http://issues.igniterealtime.org/browse/SPARK-1327

We are unable to reproduce this and it would need some more knowledge on Win7 registry and install4j than we have.

If you can work out proper registry settings, the community may provide a suitable installer. Code changes in Spark will be possible until 31.12.11 (pending contacts)

3

The issue above implies that this could be a Windows 7 / Spark 2.6.0 issue, however the same problem is also affecting XP SP3 machines running Spark 2.6.0. I will try running Spark with elevated permissions to see if it fixes the problem. If I downgrade back to Spark 2.5.8 on XP and W7 then it starts working again.

Is there any way in version 2.6.0 to change the SSO Desktop Account setting to exclude the @DOMAIN_NAME.LOCAL portion of the logon account name since on the surface this appears to be the only difference between 2.5.8 and 2.6.0?

4

I’ll let Holger check, but tomorrow is release for 2.6.1 fore sure (I’m running out of developer ressources)

5

I tested SSO with OF 3.7 (running on Win 2003) and Spark 2.60 and it works OK.

My domain is AD 2003

Client OS - w7 64bit

In spark I selected “Use Single Sing-ON” on SSO tab, and under advanced prefference I choose “Use DNS”

(Advanced tab is not checked after I click OK)

Spark user is also shown in format “user@domain.domain_suffix”

Server LDAP base DN pointing to the root of my AD (meaning any account) - then I use LDAP search filter to specified allowed OUs.

I had issues with LDAP base DN was not pointing to the root of AD, though LDAP test came up OK but filtering did not work.

6

Thanks for reporting. I’ll move the SSO / Win 7 issue out of the 2.6.1 stream and prevent changes in the SSO code (as far as I’m in charge of it :wink: )

7

As per http://community.igniterealtime.org/thread/44524 , this issue is related to UAC being enabled (which is the default setting in Win7/Vista) and is dependant on whether the user is running Spark as a regular user or an administrator.

Feel free to ask me any questions you may have. Suffice it to say the issue does exist and I can help you to replicate it in your environment if necessary.

8

Thanks trafsta, although as I mentioned in my above posts I get the same problem when using 2.6.0 on Windows XP SP3 so It can’t be solely related to UAC.

If I take an existing XP SP3 machine with Spark 2.5.8 and SSO enabled and working then upgrade to 2.6.0 SSO fails.

If I downgrade back to 2.5.8 SSO works again.

If I use 2.6.0 on Win 7 SSO fails.

If I use 2.5.8 on Win 7 SSO works.

All configs use the same domain, user logons, openfire server and krb5.ini config.

If I disable SSO and manually logon then all configurations work.

9

Sorry, my bad, I never fully read your post. I just got here via Walter’s comment @ http://issues.igniterealtime.org/browse/SPARK-1327 which was a bug fix request for this type of SSO issue which was created as a result of the thread @ http://community.igniterealtime.org/thread/44524 … SPARK-1327 referred to this thread here and kind of indicated (via @J2567’s post) that there was no issue that could be reproduced… but clearly there is an issue

Oh well, the workaround I am using seems to be good enough for 2.6.x… hopefully in time it gets fixed fully.