Posted in : Active Directory, ADFS, Microsoft By Oliwer Sundgren Translate with Google ⟶

3 weeks ago

ADFS is a very powerful tool that is a native Windows Server role. It used to be the go-to system for a Windows administrator for setting up SSO and federation capabilities to LOB and SaaS apps. Even if Azure and other Identity providers are more frequently used in todays cloud oriented environments ADFS is not yet forgotten.

Not long ago I set up a SAML based SSO application with ADFS, the application was required to use the “email” attribute to actually identify the users, easy right? Well yes it was easy, but I quickly realized that a large portion of the users didn’t actually have an email address and we were not allowed to enter any value in the email attribute for these kind of users (Approx 1000 user objects), this now got a little more complicated, but not impossible!

I resolved this challenge by creating a few custom ADFS claims rules that would check if the user object had a value in their “email” attribute, if not, they would get a dummy attribute that would, in another rule, identify that this user does not have a present email value and we would therefore use the value of their “UPN” and use that value for the “email” attribute in the SAML claim.

That was a mouthful! Let’s dive into how I actually resolved this.

How I did it

For the Application (Relying Party trust) I created 4 Claims rules and put them in this specific order as you can see below. I will go over the rules one by one and explain what each does in order to reach the end result of the challenge mentioned in the beginning.

Rule #1: The first rule is the simplest and exists in almost every ADFS application config, extractiong and mapping the attributes we’ll use from LDAP. The attributes we’ll focus on here is the “E-Mail Address” and UserPrincipalName

Rule #2: The second rule is a custom rule that I created, this rule will validate if the user object signing in actually has a value in the “E-Mail Address” attribute, if it does not then a dummy attribute called “noemailaddress” with the value of “notpresent” will be applied to the user object (For this SAML ticket only, not permanently on the AD object)

The rule is written like this:
NOT EXISTS([Type == ””])

=> add(Type = ””, Value = ”notpresent”);


Rule #3: The third rule is also custom, this rule will apply to the users that are affected by rule #2, AKA the users that don’t have a present value in the “E-Mail address” attribute, the rule will then collect the value of the users “UPN” (UserPrincipal Name) attribute and use that value for the “E-Mail Address” attribute instead. The reason for this rule combined with rule #2 is to not accidentally affect users that actually have a valid E-Mail address value already present.

So if the attribute “noemailaddress” is and “UPN” is present for a user, the value of “UPN” will be added to the “E-Mail Address” attribute

The rule is written like this :
c1:[Type == ””, Value == ”notpresent”]

&& c2:[Type == ””]

=> issue(Type = ””, Value = c2.Value);



Rule #4: The 4:th and final rule is very straight forward, it take the “E-Mail Address” attribute and uses it’s value for the “Name-ID” identifier so the user can actually be authenticated towards the application in question. Name-ID is essentially the “Anchor” attribute that verifies the identity of the user on the IDP (Identity Provider) and SP (Service Provider) side.

The rule looks like this:

So in conclusion, these four ADFS claims rules combined made it possible for all users to sign into a SaaS application, even the user accounts that did not have the correct attribute present.

If you have any questions or want to discuss ADFS or SSO in general with me, feel free to contact me on teams or via email at



Tags : Active Directory, ADFS, claims, SAML, Send Claims Using a Custom Rule, SSO, Windows Server

Personlig rådgivning

Vi erbjuder personlig rådgivning med författaren för 1400 SEK per timme. Anmäl ditt intresse i här så återkommer vi så snart vi kan.

Add comment

Your comment will be revised by the site if needed.