Sending AD ObjectGuid as assertion attribute prints some weird characters
<ns2:AttributeStatement>
<ns2:Attribute Name="ObjectGuid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<ns2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">sºÂyî2C»</ns2:AttributeValue>
</ns2:Attribute>
</ns2:AttributeStatement>
So this ObjectGuid value is what you want to pass over to the SP as an Assertion Attribute and the value is throwing error at the SP side.
Policy Server: 12.8.x
Below is the output from LDAPSearch
As you can see the ObjectGUID value appears as "c7rCee4yAkOWu9QprYaU3A==". This is not the real value in AD but it is being base64 encoded so it does not mess up the screen.
This is what the ldapsearch tool translated before displaying the value.
When Policy Server(as an LDAP client) fetch the ObjectGUID from AD, it is going to be what the AD returns to the Policy Server. If AD returns "ABC" then Policy Server will see the value as "ABC". If AD returns "{123-BBB-AAA-123}" then Policy Server will see the value as "{123-BBB-AAA-123}".
If you logon to your AD and use ADSI-Edit tool to take a look, you will find it is not this "c7rCee4yAkOWu9QprYaU3A==" value.
Microsoft is interpreting the value to be something else which does not match the LDAP queried value.
Now if you try reading this user attribute from Federation Partnership, you will get the characters you are currently getting. The raw value.
There is a way to base64 encode this by specifying this is a binary attribute, "ObjectGuid;binary".
And here is the result.
This value is simply a base64 encoded value of the raw value sºÂyî2C»
So there are 2 options. You can send the raw value(which is failing at the SP side) or you can send the base64 encoded value.
If the SP is not accepting the base64 encoded ObjectGUID and if you must return exactly how it appears in the ADSI-Edit, that will be something you need to build a custom assertion generator to do that.