LDAP import from AD to SN - ObjectSID is not the same between systems

[dsnyrs]

I've spent the last couple hours searching the Wiki and Google for an answer with no luck.

When I use Powershell to query AD for my ObjectSID I get something like this:   S-1-5-21-3934281687-3809050549-1115651111-12456

When I look at the ObjectSID in my user record in ServiceNow I see:   AQUAAAAAAAUVAAAA11+F6rV/CjPb6MghYtwAAA==

1.   Is ServiceNow encrypting the SID?  

2.   I've read a few times now that it's better to Coalesce on ObjectGUID rather than ObjectSID.   Is this a Best Practice?

3.   If #2 is correct, is this a simple change or could I be setting up for a big mess?

Thanks in advance Friends!

~ Rick

[Valor1]

1.The ObjectSID and ObjectGUID are binary-type fields in AD. The value that you're seeing is the encoded equivalent.

Check to confirm that the property "glide.ldap.binary_attributes" is set to "objectsid,objectguid". This is also how you add additional attributes.

2. ObjectGUID is better to use. Under some (rare) circumstances, ObjectSID can change. As for best practice, ObjectGUID is what we use at Cloud Sherpas

3. Simple to change and not messy if you make sure that to capture BOTH values in the user accounts BEFORE you change the coalesce value on the transform map.

[dsnyrs]

Thanks Valor, I'll give it a try!

[manita_anand]

hi rick,

were you able to achieve this ?

i am having same issue, can you suggest what was done as a solution?

[Valor1]

You will never see the same value in SN as in AD due to it being a binary object. This is okay, as it'll always convert to the sa encoded value, as long as it looks similar to the AQUAAAAAAA... format noted above.