An Active Directory (AD) ObjectGUID attribute value mapped to the Okta externalID does not match the value in AD because Okta converts the hexadecimal value into Base64. Resolve this discrepancy by using PowerShell commands to convert the Base64 version back to the AD ObjectGUID value. The observable issue occurs when the externalID in Okta differs from the original AD ObjectGUID.
- Okta Classic Engine
- Okta Identity Engine (OIE)
- Active Directory (AD)
- Universal Directory
Okta converts the hexadecimal value of a user's ObjectGUID into Base64. As a result, the value displayed in Okta is the same as the AD value but in Base64 format, which appears different.
How is the Active Directory ObjectGUID mismatch issue in Okta resolved?
Convert an ObjectGUID value to Base64 or convert the Base64 version back to the Active Directory ObjectGUID value by executing the appropriate PowerShell commands detailed in either the video demonstration or the written instructions.
- Execute the following PowerShell command to convert the Base64 version back to the AD ObjectGUID value:
[Guid]([Convert]::FromBase64String("<Base64_Value>"))
NOTE: Replace <Base64_Value> with the actual Base64 string.
- Execute the following PowerShell command to convert an ObjectGUID value to Base64:
[Convert]::ToBase64String([guid]::New("<ObjectGUID_Value>").ToByteArray())
NOTE: Replace <ObjectGUID_Value> with the actual ObjectGUID.
Can Okta map the ObjectGUID directly without Base64 formatting?
There is no method to convert the value within Okta or to map AD's objectGUID directly to an Okta attribute without this Base64 formatting being applied. If a downstream application requires the objectGUID value without Base64 formatting, store the value in a different AD attribute and map it using that attribute. Alternatively, add the value to the user profile via another method, such as CSV import.
