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!

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

Posted by Jorge on 2014-02-10


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…

image

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

image

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.

image

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.

image

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.

image

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.

image

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…

image

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

image

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.

image

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.

image

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.

image

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.

image

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.

image

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…

image

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

image

Figure 15: The ADFS SignIn Page

Voila it works! Smile

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

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

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

  2. […] Step 3: I’m kind of surprised to see the so called require claims rules for both the OWA relying part trust as the EAC relying party trust. Like I said, I have not done this myself yet, but I would expect to only require the pass-through of the UPN claim on both RP trusts. Of course you need to ask yourself "if I pass it through, where do I pass it from then?" Right! You gather the UPN claim by using a claim rule on the claims provider trust. How you do that differs from ADFS v2.x and ADFS v3.0. With ADFS v2.x you need to perform an LDAP query (using the LDAP Claim Rule Template) and in ADFS v3.0 you can pass it through (see: "(2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0" and "(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS …") […]

  3. Mandeep said

    Hi Jorge, both your blogs on this were outstanding. I have a follow up question though: Is it possible, by ADFS claim rules, to allow Outlook Anywhere to connect to O365 from anywhere (from company’s network and internet) BUT only for domain joined machines or only company issued laptops? In other words, I should be able to use Outlook Anywhere from home over internet, without a VPN, using my company issued laptop but cannot configure an Outlook profile on my personal laptop?

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: