(2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365

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/ ########
———————————————————————————————

(2014-09-29) Default Claims Rules In ADFS To Support SSO Through Federation With Azure AD/Office 365

Just for reference I posting the default claims rules in ADFS to support SSO through federation with Azure AD/Office 365.

@RuleName = "Identity Claims – Windows Account Name To UPN, ImmitableID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN","http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);

@RuleName = "Identity Claims – ImmitableID To Name ID"
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> 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");

–

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/ ########
———————————————————————————————

(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)

In this blog post I wrote and concluded about the bare minimum acceptance transform rules for the default claims provider trust (Active Directory) in ADFS v3.0 (or ADFS 2012 R2). What I wrote is still correct, however, unfortunately the final conclusion is inaccurate. I do not understand what went wrong when I tested that. While both ADFS v2.0 and ADFS v2.1, at a minimum require the "Primary SID" claim, ADFS v3.0 does not only require the "Windows Account Name" claim as I stated in the previous post. It requires an additional claim, being the "UPN" claim, at a minimum. Continue reading to understand and see what goes wrong if any of the two required claims is missing.

–

To enable debug tracing, before trying this yourself see: (2014-02-05) Enabling Debug Tracing In ADFS v2.1 and v3.0

–

If you only have the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

Figure 1: Only Using The Claims Rules For The "Windows Account Name" Claim

–

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

Figure 2: The ADFS Error Page

–

Looking at the ADFS Admin Event Log you will something similar to the figure below.. Pay specific attention to the text "ID4250: The ClaimValue cannot be null". That means, the "UPN" claim is missing or does not have a value.

Figure 3: The Error "System.IO.InvalidDataException: ID4250: The ClaimValue Cannot Be Null" In The ADFS Admin Event Log

–

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below. Now it really tells you what’s wrong! Just like I said earlier.

Figure 4: The Error "Unable To Find Upn Claim In The Incoming Identity Or Claim Value Is Empty" In The ADFS Debug Tracing Event Log

–

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below, which is almost the same error as mentioned earlier.

Figure 5: The Error "Exception: ID4250: The ClaimValue Cannot Be Null" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 6: The Error "Passive Pipeline Error" In The ADFS Debug Tracing Event Log

–

Now, if you only have the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

Figure 7: Only Using The Claims Rules For The "UPN" Claim

–

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

Figure 8: The ADFS Error Page

–

Looking at the ADFS Admin Event Log you will something similar to the figure below.. Pay specific attention to the text "SessionSecurityToken does not contain a single AnchorID claim". That means, the "Windows Account Name" claim is missing or does not have a value.

Figure 9: The Error "SessionSecurityToken Does Not Contain A Single AnchorID Claim" In The ADFS Admin Event Log

–

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below. It is telling you the same as before without really telling you what is actually wrong.

Figure 10: The Error "SessionSecurityToken Does Not Contain A Single AnchorID Claim" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 11: The Error "Token Is Invalid" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 12: The Error "Exception: MSIS7012: An Error Occurred While Processing The Request" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 13: The Error "Passive Pipeline Error" In The ADFS Debug Tracing Event Log

–

Now, if you have both the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

Figure 14: Only Using The Claims Rules For The The "Windows Account Name" Claim And The "UPN" Claim

–

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

Figure 15: The ADFS SignIn Page

–

Voila it works!

–

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/ ########
———————————————————————————————

(2013-10-09) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0

UPDATE: See a newer and more up-to-date and accurate version of this blog post here.

–

This post is about the bare minimum acceptance transform rules for the default claims provider trust (Active Directory) in ADFS v3.0. To read about the same topic in ADFS v2.0 see the following blog post: (2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0

–

Right after installing ADFS v3.0, by default it will have ONE Claims Provider Trust configuration for AD as the one and only supported authentication store. ADFS v3.0, like ADFS v2.0, does not support any other authentication store besides AD. That Claims Provider Trust will also be configure with a default set of Acceptance Transform Rules as shown below in the picture.

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

–

It is of course possible to adjust the default set of Acceptance Transform Rules by removing existing default rules and/or adding your own required rules. Assuming you would do such a thing, you could for example replace the default set of Acceptance Transform Rules, with the Acceptance Transform Rules as shown below. If you look carefully I removed the default Acceptance Transform Rules and put in my own Acceptance Transform Rules.

Figure 2: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

–

If I now try to access a Claims Based SharePoint site that I created and configured on SharePoint 2010, you would see something similar to what you would see below.

–

The default Home Realm Discovery window with the selection list. The logo you see is something that I configured. I  get to this screen because I have multiple Claims Provider Trusts configured, one for the default authentication store being AD and one for an IdP-STS at some other organization.

Figure 3: The Default Home Realm Discovery Page In ADFS v3.0 Using A Selection List Of The Configured Claims Provider Trusts (a.k.a. Identity Providers)

–

After selecting the one you see, which represents in this case the Claims Provider Trust for AD, and clicking “Continue To Sign In”, you will see something similar to the sign-in page for which I already filled in some credentials:

Figure 4: The Default Sign-In Web Page For Forms AuthN In ADFS v3.0 To Collect Credentials For Authentication

–

After clicking “Sign In”, you will see something similar to:

Figure 5: Some Error Stating Something Went Wrong

–

After errors like this, the next step is to check the ADFS Event Logs. Let’s try the Admin log first! Note the detailed information!

You should see something similar like:

Event ID 364…

Figure 6: Event ID 364 In the ADFS v3.0 Admin Event Log Stating The Session Security Token Does Not Contain A Single AnchorID Claim

–

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:app:sharepointclaimsappwap

Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. —> Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnIdentityInvalidException: SessionSecurityToken does not contain a single AnchorID claim.
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.ValidateToken(SessionSecurityToken token, SessionSecurityToken currentToken)
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.AddToken(SessionSecurityToken newToken)
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)
   — End of inner exception stack trace —
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnIdentityInvalidException: SessionSecurityToken does not contain a single AnchorID claim.
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.ValidateToken(SessionSecurityToken token, SessionSecurityToken currentToken)
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.AddToken(SessionSecurityToken newToken)
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)

–

"Does not contain a single AnchorID claim"????? Oh yeah, wait! In ADFS v2.0 you were required to have the objectSID (a.k.a. the PrimarySID) as the minimum claim. So let’s add that!

Figure 7: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0, But NOW With The Primary SID Claim

–

So, let’s try again!

No good, as I got the same error as shown in figure 5 and 6. Hey something changed here!

–

In a previous blog post "(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0" I explain how to restore the default list of Acceptance Transform Rules for the default Claims Provider Trust (AD) in ADFS v3.0 if it is broken and you cannot get it to work anymore. It is really easy to “restore” the default list of Acceptance Transform Rules.

–

However, after some testing I found out that ADFS v3.0 requires AT LEAST one identifier claim that allows an authenticated user to request a security token. In ADFS v2.0, the identifier (a.k.a. the AnchorID Claim) was the "Primary SID" claim, but in ADFS v3.0 that was changed to the "Windows Account Name" claim!!!

Figure 8: The Bare Minimum Acceptance Transform Rules List Required For ADFS v3.0 To Issue A Security Token

–

AND…. there must be only one "Windows Account Name" claim. There should NOT be multiple values for that claim, either passing through or extracted by an LDAP query as shown below.

Figure 9: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0, But NOW With MULTIPLE "Windows Account Name" Claims

–

If you have multiple "Windows Account Name" claims, which resulted from claims rules as shown in figure 9, it will not work and throw similar errors as shown in figure 5 and 6. Read it carefully, It clearly states: "SessionSecurityToken does not contain a single AnchorID claim". SINGLE, not multiple claims for the AnchorID claim, which is the "Windows Account Name" claim!

–

So in my scenario having the following claims rules worked like a charm!

Figure 10: Combination Of Acceptance Transform Rules From Figure 2 And Figure 8

–

Now trying to access my claims based SharePoint web site again will result in the following:

Figure 11: Successful Access To A Claims Based SharePoint Web Site Hosted SharePoint 2010 That Includes A Custom Web Part To Show The Claims Processed By SharePoint 2010

–

So……to summarize

For even ADFS v3.0 to be able to issue a security token, the Acceptance Transform Rule List Must AT LEAST have the claim rule specified as shown in figure 8! The value for the "Windows Account Name" claim must be in the format <NetBIOS Domain Name>\<sAMAccountName> (e.g. ADCORP\ADM.ROOT) as shown in figure 11. When you upgrade, or better migrate from ADFS v2.0 to ADFS v3.0 you need to be aware of this change!

–

UPDATE: See a newer and more up-to-date and accurate version of this blog post here.

–

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/ ########
———————————————————————————————

(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0

In the following post, you can see how to restore the default acceptance transform rules for Active Directory claims provider trust in either ADFS v2.0 (on W2K8 or W2K8R2) or ADFS v2.1 (on W2K12): AD FS 2.0: How to Restore the Default Acceptance Transform Rules for the Active Directory Claims Provider Trust. The only difference between W2K8(R2) and W2K12 is that in W2K8(R2) you need to load a PowerShell snap-in (Add-PSSnapin Microsoft.Adfs.PowerShell) and in W2K12 (and higher) you need to load a PowerShell module (Import-Module ADFS)

–

In this post you can see how to restore the default acceptance transform rules for Active Directory claims provider trust in ADFS v3.0 (on W2K12R2). Has the procedure changed? No not really. Instead of a snap-in you now need to load a module and the default acceptance transform rules have changed a bit. For completeness I have described the procedure in full in this blog post.

–

So if you have modified the default acceptance transform rules for the Active Directory claims provider trust in ADFS v3.0, and you want to restore the defaults you can use this procedure. You need to perform this procedure on an ADFS STS server with write access to the ADFS configuration database. When using SQL you can use any ADFS STS server, but when using WID you must use the primary ADFS STS server.

–

[1] Copy the following text into a file and save that file as C:\TEMP\CP_ActiveDirectory_AcceptanceTransformRules_Default.txt

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Windows account name claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Name claims" 
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Primary SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Group SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Primary group SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Deny only group SID claims" 
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/denyonlysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Deny only primary SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Deny only primary group SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Enhanced Key Usage claims" 
c:[Type == "http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all UPN claims" 
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c); 

[2] Open a PowerShell Command Prompt window

[3] Execute the following commands:

[a] Import-Module ADFS

[b] Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRulesFile "C:\TEMP\CP_ActiveDirectory_AcceptanceTransformRules_Default.txt"

[4] To verify your changes:

[a] Open the AD FS Management MMC

[b] Navigate to the node called "Trust Relationships" and select the sub-node "Claims Provider Trusts"

[c] Right-click the "Active Directory" CP trust and select "Edit Claim Rules"

You should now see something similar to:

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

–

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/ ########

———————————————————————————————

(2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0

Right after installing ADFS v2.0, by default it will have ONE Claims Provider Trust configuration for AD as the one and only supported authentication store. ADFS v2.0 does not support any other authentication store besides AD. That Claims Provider Trust will also be configure with a default set of Acceptance Transform Rules as shown below in the picture.

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v2.0

–

It is of course possible to adjust the default set of Acceptance Transform Rules by removing existing default rules and/or adding your own required rules. Assuming you would do such a thing, you could for example replace the default set of Acceptance Transform Rules, with the Acceptance Transform Rules as shown below. If you look carefully I removed the default Acceptance Transform Rules and put in my own Acceptance Transform Rules.

Figure 2: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v2.0

–

If I now try to access a Claims Based Sharepoint site that I created and configured on Sharepoint 2010, you would see something similar to what you would see below.

–

The default Home Realm Discovery window with the drop down list. The logo you see is something that I configured. I  get to this screen because I have multiple Claims Provider Trusts configured, one for the default authentication store being AD and one for an IdP-STS at some other organization.

Figure 3: The Default Home Realm Discovery Web Page In ADFS v2.0 Using A Drop Down List With The Configured Claims Provider Trusts (a.k.a. Identity Providers)

–

After selecting the one you see, which represents in this case the Claims Provider Trust for AD, and clicking “Continue To Sign In”, you will see something similar to the sign-in page for which I already filled in some credentials:

Figure 4: The Default Sign-In Web Page In ADFS v2.0 To Collect Credentials For Authentication

–

After clicking “Sign In”, you will see something similar to:

Figure 5: Some Error Stating Something Went Wrong

–

After errors like this, the next step is to check the ADFS Event Logs. Let’s try the Admin log first!

You should see something similar like:

Event ID 323…

Figure 6: Event ID 323 In the ADFS v2.0 Admin Event Log Stating It Could Not Authorize The Issuance Of A Security Token To The Requestor

–

The Federation Service could  not authorize token issuance for the caller ” on behalf of the subject ‘ADM.ROOT
‘ to the relying party ‘urn:app:sharepointclaimsapp’. Please see event 501 with the same instance id for caller identity. Please see event 502 with the same instance id for OnBehalfOf identity, if any.

Additional Data
Instance id: ed68adf5-0e12-419e-8092-7cf071a80531
Exception details:
Microsoft.IdentityServer.Service.IssuancePipeline.OnBehalfOfAuthorizationException: MSIS5009: The impersonation authorization failed for caller identity  and delegate  for relying party trust urn:app:sharepointclaimsapp.
   at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.ProcessCoreAsyncResult.End(IAsyncResult ar)
   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.EndProcessCore(IAsyncResult ar, String requestAction, String responseAction, String trustNamespace)
User Action
Use Windows PowerShell comments for AD FS 2.0 to ensure that the caller is authorized on behalf of the subject to the relying party.

–

And…

Event ID 501

Figure 7: Event ID 501 In the ADFS v2.0 Admin Event Log Stating The Caller Identity Requesting A Security Token With Claims From ADFS

–

More information for the event entry with instance id ed68adf5-0e12-419e-8092-7cf071a80531. There may be more events with the same instance id with more information.

Instance id:
ed68adf5-0e12-419e-8092-7cf071a80531
 
Caller identity:
http://temp.org/company
ADCORP.LAB
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/windows
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant
2011-09-12T21:05:54.416Z

–

And…

Event ID 502

Figure 8: Event ID 502 In the ADFS v2.0 Admin Event Log Stating Part Of The Claims That Were Extracted From AD

–

More information for the event entry with instance id ed68adf5-0e12-419e-8092-7cf071a80531. There may be more events with the same instance id with more information.

Instance id:
ed68adf5-0e12-419e-8092-7cf071a80531
 
OnBehalfOf identity:
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant
2011-09-12T21:05:54.058Z
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppTokenViewer
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppTokenContributor
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppTokenOwner
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppClaimsViewer
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppClaimsContributor
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppClaimsOwner
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
ADM.ROOT@ADCORP.LAB
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
ADM.ROOT@ADCORP.LAB

–

And…

Event ID 502

Figure 9: Event ID 502 In the ADFS v2.0 Admin Event Log Stating Part Of The Claims That Were Extracted From AD

–

More information for the event entry with instance id ed68adf5-0e12-419e-8092-7cf071a80531. There may be more events with the same instance id with more information.

Instance id:
ed68adf5-0e12-419e-8092-7cf071a80531
 
OnBehalfOf identity:
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod
http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant
2011-09-12T21:05:54.058Z
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppTokenViewer
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppTokenContributor
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
ROLE_adcorp.app.ADFSAppTokenOwner

–

And…

Event ID 364

Figure 10: Event ID 364 In the ADFS v2.0 Admin Event Log Stating An “Access Denied” For The Issuance Of The Security Token

–

Encountered error during federation passive request.

Additional Data

Exception details:
Microsoft.IdentityServer.Web.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. —> System.ServiceModel.FaultException: MSIS3126: Access denied.
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
   — End of inner exception stack trace —
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, Uri& replyTo)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, String desiredTokenType, MSISSession& session)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSerializedToken(String signOnToken, WSFederationMessage incomingMessage)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseCoreWithSecurityToken(SecurityToken securityToken, WSFederationMessage incomingMessage)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolRequest(FederationPassiveContext federationPassiveContext, SecurityToken securityToken)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)

System.ServiceModel.FaultException: MSIS3126: Access denied.
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClientManager.Issue(Message request, WCFResponseData responseData)
   at Microsoft.IdentityServer.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, WCFResponseData responseData)
   at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.SubmitRequest(MSISRequestSecurityToken request)

–

Although figure 6, 7, 8 and 9 show that claims were extracted from AD by the STS, an “Access Denied” was given for the issuance of the security token. This simply means the caller/requestor, in this case “ADM.ROOT” does not have permission to request a security token. So, the “Access Denied” in this case is related to ADFS itself and not the application you are trying to access.

–

The following TechNet Wiki Page “AD FS 2.0: How to Restore the Default Acceptance Transform Rules for the Active Directory Claims Provider Trust” explains how to restore the default list of Acceptance Transform Rules for the default Claims Provider Trust (AD) if it is broken and you cannot get it to work anymore. It is really easy to “restore” the default list of Acceptance Transform Rules.

–

However, after some testing I found out that ADFS requires AT LEAST one identifier claim that allows an authenticated user to request a security token.

Figure 11: The Bare Minimum Acceptance Transform Rules List Required For ADFS To Issue A Security Token

–

The bare minimum Acceptance Transform Rules list is shown in figure 11 and the detailed configuration is shown in figure 12.

Figure 12: The Configuration Of The Claim Rule To Extract The Primary SID (objectSID in AD)

–

Now by combining the Acceptance Transform Rules list in figure 2 and 11 you will something like:

Figure 13: Combination Of Acceptance Transform Rules From Figure 2 And Figure 11

–

Now trying to access my claims based sharepoint web site again will result in the following:

Figure 14: Successful Access To A Claims Based Sharepoint Web Site Hosted Sharepoint 2010 That Includes A Custom Web Part To Show The Claims Processed By Sharepoint 2010

–

REMARK: On the internet blog posts exist explaining how to implement the custom web part to show the claims processed by Sharepoint 2010. I will also write a blog post providing more detail than any other so that non-developers (like myself) can also try this! SO stay tuned!

–

So……to summarize

For even ADFS to be able to issue a security token, the Acceptance Transform Rule List Must AT LEAST have the claim rule specified as shown in figure 11!

–

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/ ########
———————————————————————————————