Home Analyst Portal

Cachebuilder Error Message : Unable to locate user

Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
edited November 2022 in Analyst Portal

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_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭
    Answer ✓

    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.

Answers

  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭

    @Simon_Zeinhofer - Did you force the user out of Deleted Items in the SCSM console?

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @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.

  • Moritz_FreiMoritz_Frei Customer IT Monkey ✭

    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?

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @Justin_Workman

    We deleted the user again, disabled the AD connector for 2 days and now after a resync it works :)

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
    edited November 2022

    @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?

  • Justin_WorkmanJustin_Workman Cireson Support Super IT Monkey ✭✭✭✭✭
    Answer ✓

    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.

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
    edited December 2022

    @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

Sign In or Register to comment.