Unable To Logon With New User ID

[Jim_McCarthy]

I've got a user who just changed departments. As a result she was assigned a new user ID in AD. She can logon to Windows on her new computer (it's new to her, not a freshly built computer) with her new AD credentials without issue. However when she launches the OnBase Web Client, she gets a message saying a connection could not be established because her old ID is not a member of any groups. Her old ID in OnBase and AD was deleted when her new AD account was created.

When she launched the Thick Client, her ID was automatically created in OnBase as I would normally expect. However when I look at the record created in the table UserAccount,  a number of columns contain values that differ from those present for most other users. Specifically, AutoDisplayWin has a value of "0" instead of the value of "1" most users have, UserPref3 has a value of "0" instead of the more common value of "8", and ObUniqueId contains a nine digit integer instead of the more common value of zero. All other columns appear to be populated consistent with values other users have. 

I tried deleting her new ID from OnBase and logging on again to recreate it. She got the same results in the web client, and the same variations in her UserAccount record when she logged on via the thick client. I had her logon to our test system via the web client and that was successful, which leads me to think the problem is in our production OnBase system somewhere, not AD.

I don't understand why the web client would be attempting to connect with her old ID, but the thick client connects with her new ID. Where and how would such a link be established, and perhaps more to the point, how can I break the link? What does the column ObUniqueId represent and why would it contain a non-zero value?

Thanks.

[AdamShaneHyland]

Hi Jim,

Thanks for the post.

This issue can occur if the user account in AD was changed, but it still has the same SID.  Typically this is caused by the Application Server caching the user credentials via the LsaLookUp key.  You can read more about it in this post (link).

Let us know if this works to resolve the issue.

Take care.

[Jim_McCarthy]

Thanks for the link Adam. I was told the user's AD entry was in fact changed, not deleted and added. I disabled the LSA cache on the app server and my user was able to logon this morning. I'll re-enable it and set the cache expiration to something shorter than a week to minimize similar problems in the future.

[AdamShaneHyland]

My pleasure.  Glad that it worked out and thanks for the follow up.

Take care.