2 Replies Latest reply on Oct 25, 2017 9:45 AM by WillSchultze

    2 Key Values for Employee

    WillSchultze Rookie

      Our org uses two identifiers for employees: login (internally "UVID"; this is also the cn of the user's AD record) and employee number (internally "LID"). LID is unique; UVID is not unique due to ID recycling.


      The issue is this: when our tenant was brought online, the LDAP import process was validated on cn = LoginId. However, since users may get married/have name changes/etc there are times when the UVID is changed. If this happens, a duplicate record with a bogus LoginId would get generated. To stop this happening, I changed LDAP import to validate on employeenumber = LID (a custom field in our Employee object).


      One problem solved. New problem is, if a UVID expires, gets removed from AD, and recycled, the new user will never generate an Employee record via LDAP import because there is an existing LoginId value that doesn't match the LID for the new user. Argh!


      I have no idea how to get around this problem except to manually address it when it occurs -- but then unless it gets reported to me or I scrub the LDAP import logs, I'll never know. When a UVID gets expired, the AD record is just wiped out -- this happens several years after the person has been gone but I don't know then how to remove them, since they won't be in AD anymore to trigger an update in the Employee records. Is there anyone else dealing with this particular problem or one like it? Is it obvious and I'm missing it, or am I out of luck?


      Thanks in advance for your insight on this issue,


        • 1. Re: 2 Key Values for Employee
          florian1 Expert

          Hi Will,


          that's why you should always use a unique identifier instead.

          Since we take the user's "objectGUID" attribute as a unique identifier we don't have any issue with name changes anymore (see SID vs. GUID) as long as you don't create completely new objects for the same user:

          When a new domain user or group account is created, Active Directory stores the account's SID in the Object-SID (objectSID) property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise but also across the world. GUIDs are assigned to every object created by Active Directory, not just User and Group objects. Each object's GUID is stored in its Object-GUID (objectGUID) property.

          Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object's GUID will yield results if the user has an account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of finding the object you want to find. The values of other object properties can change, but the Object-GUID never changes. When an object is assigned a GUID, it keeps that value for life.

          Don't forget to add some business rules for this case (e.g. Update Windows-Integrated-Login to match the new loginid etc.) and you won't have any issues anymore. :-)

          • 2. Re: 2 Key Values for Employee
            WillSchultze Rookie

            Thanks for your reply, Florian. Unfortunately it's not really a solution to my problem. I'm not in a position to change the way we run ID provisioning at my institution, and I'm well aware of the fact that it's sub-optimal. Does anyone have an idea of how I can work around the issue? Alternately, is there a way I'm not thinking of that I can use to "expire" accounts based only on their non-presence in Active Directory?