Home› Asset Import
Options

Key value in Connector SID vs UserName

Roman_NepomniashchiiRoman_Nepomniashchii Customer IT Monkey ✭
in Asset Import
Capture.JPG

Hi, Team! 


In our SCSM we use AD connector, but in AD we don't have required attributes for us in class "user". We want extension standard class "user" in AD with additional attributes and fill this attributes using Cireson Asset management Connector from SQL DataBase but in Active Directory value key is user name(login). We want to use AD SID as value key, because we can change user name (if man changed his last name, our username(login) consist of FirstName.LastName) 

It is possible to use SID as value key? 


In attachment you can see the screenshot of my custom Cireson Asset management Connector 


Or are other way resolve this problem.

Answers

  • Options
    Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭

    The asset import connector is going to bring up the fields that are part of the primary key in the database so as to positively identify the exact user object(s) to modify. SID probably would have been a better choice, but it was not the one that was made when SCSM was designed.

    If your UserName field is not matching the samAccountName in AD, then that is the issue to solve here.

    The AD Connector does not like it when UserName changes. The best advice here that you probably cannot use is to make it a policy that usernames will never be changed, and that something other than name/surname should be used. That would help you avoid this issue altogether. But since I am sure you cannot do that (neither could I!) you will probably see cases where SCSM still has the old user name but continues to work with it since the SID matches.

    In my experience, you can force the connector to sync by doing these general steps:

    1. Create a temp user object in SCSM
    2. Use powershell to transfer any related data over from the "old" user to the new user object that you care about and/or any extension properties that won't sync over later from some other process (e.g. manually entered metadata)
    3. Delete the "old" user object then remove it from deleted items
    4. Modify the DB table used by the connector (LFXSTG.AD_User if memory serves) by changing the date stamp on the user object that has the updated UserName to a time a few minutes after you expect the next AD Connector sync to occur.
    5. Let the AD Sync occur
    6. Use powershell to transfer over everything you copied in step 2 to the new user object.

    Warning: step #4 is almost certainly not supported by Microsoft. You may want to open a ticket with them and run through this with them rather than doing it on your own. They may even have other/better advice depending on the specifics of your environment.

    After doing all of this, the asset import connector will have no trouble syncing other properties to your user object.

  • Options
    Roman_NepomniashchiiRoman_Nepomniashchii Customer IT Monkey ✭
    https://community.cireson.com/discussion/comment/18926#Comment_18926

    Thank you, but this is not resolved our problem, key value is string it very bad, we want change this but the probably impossible(((

  • Options
    Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭

    True, what I said does not get the Asset Import connector to use the SID as the primary key, but it isn't the PK (I agree with you that it should be, but it isn't). For that reason, I do not believe that the connector will sync to it. If that is the problem, then only Cireson could solve it with a change to the way their connector works, or if you could convince Microsoft to use a different key combination on the table, I think.

    If the problem is getting your extra properties to sync from AD to your class extension, this is exactly how I have solved that here, for users with UserName (samAccountName in AD) that has been changed against all my warnings and established practice. So it can work if you want it too. If you have a high volume of UserName changes then I could see how you may not want to be doing this very often, though, even if it is automated in Orchestrator/SMA/Azure/etc.

Sign In or Register to comment.