Cachebuilder Error Message : Unable to locate user
Simon_Zeinhofer
Customer Ninja IT Monkey ✭✭✭✭
We have a user in our company, whose username got changed in Active Directory.
Of course a new user in SCSM has been created. We deleted the old one, changed the relationships etc. etc.
Now we have the situation, that we get the following error in the cachebuilder log:
2022-11-16 09:36:30,897, WARN [ 17]: Unable to locate user: engel\OLDUSERNAME from group: company\domain users, in role: End User Service Request Editor Role
The old username is no longer present in Active Directory so I wonder where this username comes from.
We tried deleting the user from the config items, set back the watermark, cleared the ci$user and lastmodified table multiple times, but the error message reappears everytime.
When I execute the spCheck_UserRequestOfferingPermissions stored procedure with the new username (how it is stored inside AD and scsm) on a request offering, where all our users ("domain users" group in AD) should have permissions, I get back:
DOES NOT Have Permission to Access Request Offering with ID: 8E68564E-00F4-FE18-CA0A-0DB9606220FF
- DOES NOT Have Permission to Access Parent Service Offering with ID: 8E68564E-00F4-FE18-CA0A-0DB9606220FF and Title: SO NAME
Same goes for Work Items, as for this user no scope is created.
The user cannot work in the IT portal right now, as he sees no request offerings.
Why does the cachebuilder still goes for the old username when the old user is no longer present in AD, nor in SCSM. I thought the Cachebuilder service directly gets the users from AD and compares it with the user objects in the database?
Best Answer
-
Justin_Workman
Cireson Support Super IT Monkey ✭✭✭✭✭
The cachebuilder gets users from roles, then looks for their CI in SCSM, then matches the distinguishedName from that CI to AD. This means that a) if a user doesn't have a CI they can't be found and b) if their DN doesn't match, they can't be found.
0
Answers
@Simon_Zeinhofer - Did you force the user out of Deleted Items in the SCSM console?
@Justin_Workman Yes we deleted it and removed it out from the deleted items in the console.
We even set our AD connector schedule to 01:00 AM, so the purging workflow from SCSM runs before that.
Addition to the information of Simon. We also checked the Servicemanagement tables and in some of them there is an entry for the old and the new user. Could this be a problem?
Csn_Portal_User: old and new user
CIToScopedPortalUser: only new user but multiple entries
csnCached_MT_System_Domain_User: only new user
Cireson_Core_PlatformUser: old and new user
Cireson_Core_Userlogin: old and new user
CI$User: only new user
ScopedUser: only new user
There is also this entry in the cachebuilder log where it would look for the new user.
cn=XX,ou=XX,dc=XX,dc=XX is a member of cn=XX,dc=XX,dc=XX, but does not exist in the database.
It would be nice to know where the cachebuilder is exactly looking for the users?
@Justin_Workman
We deleted the user again, disabled the AD connector for 2 days and now after a resync it works :)
@Justin_Workman After one day we have the same situation again :(
I had a look at the [ServiceManager].[dbo].[UserRoleUser] table and we only have an entry for the old user there. The new user is not present :(
Might this be a problem with our connector?
The cachebuilder gets users from roles, then looks for their CI in SCSM, then matches the distinguishedName from that CI to AD. This means that a) if a user doesn't have a CI they can't be found and b) if their DN doesn't match, they can't be found.
@Justin_Workman
So the Cachebuilder is not getting the information from the [UserRole] tables from the Servicemanager DB, it really gets them from the Security role itself? May I sask how you accomplish that? :) Just because I am interested :)
In our case the problem is, that the DN and username in the CI object are correct, BUT from the security group it still receives the old username and therefor does not find the object, because no object with that username exists - at least this is the error message inside the cachebuilder log.
Yesterday I removed the domain users group from our end user security group and added it again and today morning everything is fine - I am totally confused to be honest :D