ADFS 2.0 asserts the immutableID value in its SAML assertion during Federation attempts with Office 365.
The ImmutableId is specified at object create time in Office 365. If you use DirSync, the objectGUID is used.
If you have many AD forests that you wish consolidated to one O365 instance, DirSync is not really an option.
So if you can get your users into O365, and set a proper UPN, and ImmutableId, will ADFS be happy? And what format for the objectGUID value (A non-string value, octet/binary, whatever you wish to call it) should be passed when creating your user?
- String based GUID representation
- Base64 encoded binary value
It is easy enough to do either in my case, I just need to know what ADFS is using in its assertion in its basic or default configuration for this support?
A bit late but hopefully helps others.
One option I have seen in real a multi forest O365 deployment was to use a resource forest. FIM 2010 R2 was used to sync all other forests and then use Dirsync (or FIM 2010 R2 with the O365 MA) to sync to the O365 tenant. AS of writing this, the management agent was not freely available and required Microsoft consultancy to obtain it.
The immutable is indeed objectguid attribute of the user in AD by default. Dirsync will write the objectguid from the AD user object into the user object represented in the Azure AD hosting your tenant. But technically, you can use another unique attribute instead if desired. The key thing to ensure is that the value is not reused on other objects. For example an employeeid or similar attribute could be used.
Please also note that Dirsync is a "blackbox appliance" that is not encouraged to be tweaked with beyond what's documented by Microsoft. Please don't run an unsupported configuration.
If you have set the ImmutableID on the object in Azure AD, and AD FS is configured to read the relevant attribute (e.g. employeeid) and send it in assertion O365 will be happy.The ImmutableID attribute is a string. All you need to do is send a value that O365 expects to receive and match in Azure AD.
Check the claim rules created by O365 Powershell cmdlets on AD FS. Specifically the first rule to see how UPN and ObjectGUID are extracted and sent as relevant claims.