When setting up DirSync And Federation between your on-premise AD and Windows Azure AD to support identity sync and SSO, the most important attribute to make sure everything works are the immutableID and the userPrincipalName.
–
Paul Williams from msresource.net has written a great number of blog posts about this, touching all kinds of related stuff. See the following blog posts:
- Multi-forest SSO to O365: implementing multiple immutable IDs
- Windows Azure Active Directory Connector part 1: when, where and why
- Windows Azure Active Directory Connector part 2: multi-forest directory synchronization
- Windows Azure Active Directory Connector part 3: immutable ID
- Implementing Exchange Online with an existing on-premises identity management solution that provisions mailboxes
–
With regards to the implementation I used the string version of the objectGUID (AD) as the immutableID (sourceAnchor in AAD)) and the UPN as the userPrincipalName (AAD). I achieved that by leveraging FIM with the AAD connector. Because of that I also had to implement slighty different claims rules in ADFS for Azure AD/Office 365. The rules in my ADFS v2.0 looked like:
@RuleName = "Identity Claims – objectGUID (Base64) To objectGUID (String)"
c:[Type == "http://temp.org/identity/claims/adObjectGuidBase64org"]
=> add(store = "String Processing Store", types = ("http://temp.org/identity/claims/adObjectGuidString"), query = "fromBase64GuidtoStringGuid", param = c.Value);
@RuleName = "Identity Claims – upn To UPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN", Value = c.Value);
@RuleName = "Identity Claims – objectGUID (String) To ImmutableID"
c:[Type == "http://temp.org/identity/claims/adObjectGuidString"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
@RuleName = "Identity Claims – ImmutableID To Name ID"
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");
–
I swear everything was working, until some day I started to get the following errors:
….when navigating to: https://outlook.office365.com/owa/
Figure 1: Error When Using Federated Logon And Navigating To Office 365 Portal
–
….when navigating to: https://manage.windowsazure.com/default.aspx
Figure 2: Error When Using Federated Logon And Navigating To Azure AD Management Portal
–
….when navigating to: https://portal.office.com/
Figure 3: Error When Using Federated Logon And Navigating To Office 365 Management Portal
–
By giving the correlation ID to someone at Microsoft that is able to check it in the system logs, they most likely will be able to tell you what would be wrong. In this case unfortunately I as not able to do that. The logs on my system did not given me any clue!
As I have another ADFS v3.0 system in my environment, I therefore decided to configure that ADFS instance with all default values for DirSync and federation. After configuring all this, I was able to access Azure AD and Office 365 through federated logon on my ADFS v3.0 box, but still not on my ADFS v2.0.
–
After comparing the federation trusts between ADFS v2.0 and Azure AD, and between ADFS v3.0 and Azure AD I saw the following difference:
Figure 4: Signature Hash Algorithm On The RP Trust On ADFS v3.0 For Azure AD/Office 365 (Default Config) – WORKING
–
Figure 5: Signature Hash Algorithm On The RP Trust On ADFS v2.0 For Azure AD/Office 365 (Custom Config) – NOT WORKING
–
For whatever reason, in the past I had changed the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 AND I had forgotten about it. It took me some time to find this one, but by just changing the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 from SHA-256 to SHA-1, everything started to work again! Yiiihhaaaaaa!
–
PS: this has NOTHING to do between the usage of ADFS v2.0 and ADFS v3.0. This was a configuration mistaken I made when playing around in the test/demo environment
–
Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————
Jorge's Quest For Knowledge! 