Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

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

Posted by Jorge on 2013-10-09


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.

image

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.

image

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.

image

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:

image

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:

image

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…

image

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!

image

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!!!

image

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.

image

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!

image

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:

image

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

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

  1. […] this blog post I wrote and concluded about the bare minimum acceptance transform rules for the default […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: