Skip to main content

We have a user whose last name was updated in AD (affecting logon name, email, name, etc.) -- SID stays the same. That user should have access to the K2 forms via membership in an AD security group, but ever since the name change, the user receives a "Server Error in '/Identity/STS/Windows' Application" message when they navigate to the form in their browser.

 

I'm trying to piece together information about how K2's identity cache works and how it might be contributing to the issue. I do see an entry in the Identity.Identity table that matches the user's SID but references the user's old name. The ExpireOn and ContainersExpireOn dates have passed and Enabled is marked 0.

 

It seems like maybe the identity service is choking because there's already an entry for that SID but maybe it can't renew it since the other fields have changed or something like that. Any advice on clearing this up or explanation of the identity cache would help. All I've had to go on is this page.

 

Thanks!

Is that user able to browse to the windows sts web application url similar to the URL below:


 


https://k2.denallix.com/Identity/Sts/Windows


 


Does it return the user's logon name?


 


16045iFFA06B2A2F065C96.png


 


 

Thanks for your reply.

 

The user is able to navigate to the page and authenticate using their "new"/current logon name and password.

 

The page displays "You have successfully logged into the K2 blackpearl Windows Security Token Service" as shown in your screenshot, although the "Logged on as:" displays the user's OLD logon name.

You may be experiencing a similar issue to the one described in the post below:


 


http://stackoverflow.com/questions/5551489/wrong-authentication-after-changing-users-logon-name


 


Where the local security authority (LSA) caches the mapping between the SID and the user name in a local cache; and returns the old user name (after a name change) instead of the new one.


 


"The cache entries do time out, however chances are that recurring queries by applications keep the existing cache entry alive for the maximum lifetime of the cache entry."


 


To workaround this issue, I believe you just need to temporarily disable/clear the cache by adding the registry key as per the KB below on the IIS server:


 


https://support.microsoft.com/en-us/kb/946358


 


Testing the identity page again to see if the new name gets returned or not, and then removing the registry key afterward to re-enable the cache i believe.

Thank you!

 

I believe that was the underlying issue. A bit of googling around that KB article led me to this blog, which reported that you could force the user's info to update in the LSA cache without messing with the registry. Just run this bit of PowerShell on the app server:

 

$objUser = New-Object System.Security.Principal.NTAccount "mydomain<new account name>"
$objUser.Translate(eSystem.Security.Principal.SecurityIdentifier])

I ran that this morning and the user is now able to access the site successfully. I appreciate your help!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings