Spark SSO relogin errors after Windows 10 lock out

Openfire Openfire Support
1

Hi all,

An Openfire SSO has been setup using examples from 28 Steps to Single Sign On for Openfire XMPP Server on Windows Server 2012 R2 with Spark and a Spark client can connect successfully to the Openfire server using SSO. However, something odd happens after Windows 10 OS decides to go into the lock screen. It seems that the Spark client cannot re-login again using SSO .

Here are the debug logs shown:

Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false

Refreshing Kerberos configuration

Acquire TGT from Cache

Principle is null

null credentials from Ticket Cache

[Krb5LoginModule] authentication failed

Unable to obtain Principal Name for authentication

I then signed out of the Windows account and signed in again. After which, the Spark client can re-login using SSO. Anyone knows if this is the intended behavior?

Has anyone also encountered this issue before and managed to fix it?

Regards,

Johnny.

2

Hi,

Just found out that there is a bug in Windows 10 that purges the Kerberos tickets after the Windows screen gets unlock.

Regards

1 Like
3

thats odd. I don’t recall coming across that issue when I tested win10

4

Well, there are currently 3 official versions of Windows 10 (RTM, SR1, Anniversary Release - or 1042, 1511, 1607; next one coming in spring). Not counting the Insider builds coming out every few days sometimes. That’s what you have with the “living” OS principle. No way to prepare, plan, standardize anything. Just live with it…

5

just confirmed this issue.

windows 10 purges the ticket cache, but doesn’t refresh it after a successful login to the dc. you can manually refresh by requesting a ticket with

klist get krbtgt/<domain.local>

if you are using elevated rights, you’ll need to run this command “as administrator”

as a work around, you can create a task in task scheduler using the trigger “on workstation unlock of any user”

1 Like
6

The best way to Run it so it does not require elevated rights is to install it in the Users/Public folder. This will allow SSO to work client side without having to give the User any Admin rights. This also works after logging back in after locking the computer.

1 Like