"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."
http://technet.microsoft.com/en-us/library/cc961625.aspx
http://msdn.microsoft.com/en-us/library/ms679024(v=vs.85).aspx
Obejctsid = security identifier — related to security
Objectguid = globally unique identifier — each element (contact) in AD has Objectguid. If the user has network id, the user has objectguid. If the user has some email account in AD that is not related to the network ID, AD sees the user as two contacts because 1 objectguid is assigned to the username and another one for
the email address. But if each user has outlook access that is same as network id than user has one objectguid.
For example: user in Example company has network id = user1 & email = user1@example.com.
This user has one objectguid in AD. But If user has email = user1@newexample.com than it would be different
contact in AD and therefore different objectguid.
So if you use objectguid as coalesce field in such situation you might have two users user1,
although they are the same.
During the transform mapping, map fields logicaly — name to the name, userid to userid and use objectguid to objectguid and use it as coalesce field. If you do not have objectguid in your source table you can easily create new field by going to that table. My understanding is that by default user table (sys_user) has all necessary fields, so you will have to map them properly. If you have one LDAP server and do not have issue with emails you should test transform map using objectguid.
You can use obejctsid as coalesece field as well, but I think that you will have to import and sidHistory as well. Objectsid is temporary atribute in AD and could change if the users' data change. Sidhistory, is attribute that holds (collect) all users objectSIDs. So if the user change something in profile in AD, objectsID will change, but because you use sidHistory ServiceNow should not change the profile, because the old objectsid is saved in sidHistory.
I am working on that process now in our organization as we are planning to use multildap configuration.
Currently we use samaccountrname.
