objectSid and ADFS

If you are upgrading from Shibboleth to OpenAthens and will be using the ADFS connector you are likely to run into a difference between how Shibboleth read the default identifier from AD using LDAP... and how ADFS sends objectSid as a Claim.

The short version is that despite being the same value, LDAP and ActiveDirectory see them differently.

What happens is that LDAP is not aware of the way any attributes are encoded and just returns whatever it sees - e.g. if you look at an objectSid using LDAP you will see a value like [B@74fd2e5e. What that value actually is when you look at it in AD itself is more like this: S-1-5-21-1806619730-96226714-1499285776-1101 and that's how ADFS will send it as a claim.

This is only a problem if you want to maintain your end-users' targetedID values as those are based, in part, on the user's unique identifier.

How to work around it to maintain targetedID values

This assumes you have already set up the connection for ADFS according to the instructions:

• ADFS connector
• Migrating from your own IdP

1. Send objectSid as a claim with a specific name: 'objectSidEncodedString' - e.g:
   
   

   

   
   
   
2. Map the value on your connection - e.g:
   
   

   

Once this is done and saved, when our end is sent a claim with that specific (and case sensitive) name it will translate the objectSid value into the the string that would have been seen by Shibboleth via LDAP and use that instead of the uniqueID to generate targetedIDs.

Anything to watch out for?

If the objectSid you send is invalid the sign-in will fail and the end user will see an error.