(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…
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 « Jorge's Quest For Knowledge! said
[…] UPDATE: See a newer and more up-to-date and accurate version of this blog post here. […]
LikeLike
Exchange OWA Through ADFS « Jorge's Quest For Knowledge! said
[…] 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 …") […]
LikeLike
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?
LikeLike
Jorge said
Taking a guess here…
I think you would need to additionally register those computers (at least win7, and for win7 you need to install the MSI package) in AD through device registration. Through device registration, ADFS is able to distinguish between registered and not registrated device.
device registration –> https://technet.microsoft.com/en-us/library/dn486831.aspx
LikeLike