Jorge's Quest For Knowledge!

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

(2018-10-11) Configuring A New Identity Store As A Local Claims Provider In ADFS

Posted by Jorge on 2018-10-11


In ADFS v1.0 and ADFS v1.1 it was possible to use both AD and ADLDS/ADAM as an identity store. One of the very common scenarios is to use the AD identity store for internal users and use the ADLDS/ADAM identity store for external users (e.g. partners, customers, vendors, etc.). After ADFS v1.x Microsoft released ADFS v2.0 (separate download for W2K8 and W2K8R2), ADFS v2.1 in W2K12 and ADFS v3.0 in W2K12R2. All the ADFS versions starting with ADFS v2.0 and higher only supported AD as the identity store and nothing else. That could be one of the reasons why some companies remained using ADFS v1.1 and did not move one.

If you would like to support a similar scenario, where you would like to have a separate identity store for externals, you would need to:

  1. Configure a separate AD with its own ADFS infrastructure and configure federation between (also see: (2013-09-24) AD User Accounts For Which The ADFS STS Can Generate Security Tokens)
    OR
  2. Use Azure AD to store those identities and configure federation

The biggest advantage of using [2] instead of [1] is that you do not need a complete new infrastructure just to support externals. The basic Azure AD features are free, but as soon as you need something special from the Azure AD Premium list, you need to pay licensing.

With the release of the Windows Server 2016, a third option has become available as already mentioned in the blog post (2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only. YES! YES! YES! Finally!

For the passive federation protocols (e.g. SAML, WS-Federation and Oauth) and the active federation protocols (e.g. WS-Trust), ADFS v4.0 (ADFS in Windows Server 2016) and higher will support the following identity stores:

  • Identity Stores As Claim Providers:◦Active Directory (Trusted AD forests)
  • Identity Stores As Local Claim Providers:◦Active Directory (NON-Trusted AD forests)
    • ADLDS/ADAM
    • Apache DS
    • IBM Tivoli DS
    • Novell DS
    • Open LDAP
    • Open DJ
    • Open DS
    • Radiant Logic Virtual DS
    • Sun ONE v6, v7, v11

The local claims providers can only be configured through PowerShell and authentication through ADFS against those local claims providers can only be done by using forms-based authentication. One last thing to note is that you can only configure local claims providers when the Farm Behavior/Level is higher than Win2012R2. Also see: (2014-10-12) Migrating Or Upgrading To A New ADFS Version.

For more information also see:

I have the following Identity (ID) Store:

  • Type: ADLDS (LDAP)
  • Node Server (1): R1FSRWDC1.IAMTEC.NET
    • LDAP Port: 5389
    • LDAPS Port: 5636
  • Node Server (2): R1FSRWDC2.IAMTEC.NET
    • LDAP Port: 5389
    • LDAPS Port: 5636
  • Account UserName For ADFS To Access data In The IDStore: SVC_R1_LDAPQuery@CORP

# Define The Credentials For ADFS To Use When Connecting To The ID Store

$idStoreAccountUserName = ‘SVC_R1_LDAPQuery@CORP’

$idStoreAccountPassword = ‘pwd’ | ConvertTo-SecureString -asPlainText -Force

$idStoreAccountCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $idStoreAccountUserName,$idStoreAccountPassword

# Define All The Server Instances Hosting The Identity Store

$idStoreInstance1 = New-AdfsLdapServerConnection -HostName R1FSRWDC1.IAMTEC.NET -Port 5389 -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

$idStoreInstance2 = New-AdfsLdapServerConnection -HostName R1FSRWDC2.IAMTEC.NET -Port 5389 -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

PS: If you have a load balanced ADLDS farm than you would only need to define one connection instance as the load balancer would figure out which node to use. For more information about load balancing ADLDS please see: https://www.itprotoday.com/management-mobility/load-balance-ad-lds-microsoft-nlb-6-steps. If you do not have a load balanced ADLDS farm you need to define all connection instances so that ADFS can figure out which one to use. In the connection above I’m using the custom LDAP port (5389) configured by me. I did this as I was too lazy for this post to get an SSL certificate for LDAPS. For production systems I do suggest you use LDAPS!. For more information please see: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725767(v=ws.10)

# Define All The Attribute-To-ClaimType Mappings For Which You Want ADFS To Automatically Retrieve From The ID Store

# (These are the attributes and their values, if any, automatically retrieved from the ID store and stored in claims, whether or not these are issued later on in a security token)

$mappingGivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"

$mappingSurname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"

$mappingDisplayName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute displayName -ClaimType "http://temp.org/identity/claims/displayName"

$mappingEmployeeID = New-AdfsLdapAttributeToClaimMapping -LdapAttribute employeeID -ClaimType "http://temp.org/identity/claims/employeeID"

$mappingDescription = New-AdfsLdapAttributeToClaimMapping -LdapAttribute description -ClaimType "http://temp.org/identity/claims/description"

# Create The Local Claims Provider Trust To Appear In The HRD Screen Through A List Of Claims Providers

Add-AdfsLocalClaimsProviderTrust -Name "External ID Store" -Identifier "urn:adlds:external:idstore" -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer "OU=People,O=CORP" -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription) -Enabled $true -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => issue(claim = c);"

OR

# Create The Local Claims Provider Trust To Appear In The HRD Screen Through UPN Suffix

Add-AdfsLocalClaimsProviderTrust -Name "External ID Store" -Identifier "urn:adlds:external:idstore" -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer "OU=People,O=CORP" -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription) -Enabled $true -AcceptanceTransformRules "@RuleName = `"Issue All Mapped Claims`"`nc:[] => issue(claim = c);"

Now when running either of the “Add-AdfsLocalClaimsProviderTrust” CMDlets you may see the following error at the end. It is really vague and does not tell you anything about what is really wrong. At first I thought something was wrong with the database.

image

Figure 1: Creating The Local Claims Provider Trust Fails With An Error

When things go wrong, the first thing I look at is the event log of the specific application/system. In this case it was the ADFS Admin Event Log. It did not say anything about this error. Knowing that I thought it would took me hours to figure this out. Au contraire!. Looking at the ADFS Debug Event Log, I saw the following message. It was referencing the Certificate Sharing Container.

image

Figure 2: Error Message In The ADFS Debug Event Log

An error occurred while trying to add an object:
Message: MSIS0013: Encrypted property ‘AccountStoreData’ cannot be set when a certificate sharing container is not configured in AD FS properties.

It was a weird error, because my ADFS farm is NOT using automatic certificate rollover and therefore it does not need the Certificate Sharing Container. You can see in the figure below that is the case. My farm is using CA issued certificates for the Token Signing Certificate and the Token Encryption Certificate.

image

Figure 3: Certificate Rollover NOT Being Enabled And The Certificate Sharing Container Not Being Configured

The Certificate Sharing Container is related to ADFS using ADFS Managed Self-Signed Certificates for the Token Signing Certificate and the Token Encryption Certificate. When the “AutoCertificateRollover” is set to TRUE, the “CertificateSharingContainer” property MUST specify the DN of the Certificate Sharing Container in AD. The ADFS servers and the Certificate Sharing Container must be in the same AD domain. When the “AutoCertificateRollover” is set to FALSE, the “CertificateSharingContainer” property CAN have a DN specified but in that case it is not being and can be removed if needed (but only when you are not going to use it in the future!).

Well, because the error was mentioning the Certificate Sharing Container and I did not have a Certificate Sharing Container, I decided to create one. When doing so you need to specify the service account in use by ADFS. I did that by reading the account from the ADFS service. Please be aware that by configuring the Certificate Sharing Container in ADFS, it will also be created in AD. Because of that you need to have Domain Admin equivalent permissions to be able to successfully do this!

$adfsService = Get-WmiObject win32_service -filter "name=’ADFSSRV’"
$adfsServiceAccount = $adfsService.StartName
Set-AdfsCertSharingContainer -ServiceAccount $adfsServiceAccount

image

Figure 4: Configuring The Certificate Sharing Container For ADFS

Now looking at the ADFS properties you can see the Certificate Sharing Container is configured in ADFS.

image

Figure 5: The Certificate Sharing Container Being Configured For ADFS

Before the configuration in ADFS you can see AD did not have a Certificate Sharing Container.

image

Figure 6: The AD Domain The ADFS Servers Are In With NO Certificate Sharing Container

After the configuration in ADFS you can see AD now does have a Certificate Sharing Container.

image

Figure 7: The AD Domain The ADFS Servers Are In With Certificate Sharing Container

Now when running either of the “Add-AdfsLocalClaimsProviderTrust” CMDlets above succeeds!

image

Figure 8: Creating The Local Claims Provider Trust Now Succeeds

Below you can see the properties of the Local Claims Provider trust that was created.

image

Figure 9: The Configuration Of The Local Claims Provider Trust That Was Just Created

And now you also see the local Claims Provider Trust is displayed and therefore available in the HRD page in ADFS.

image

Figure 10: The HRD Page In ADFS Showing The Newly Created Local Claims Provider Trust

Choosing the IdP “External ID Store” and logging on with an account from the ADLDS based ID Store through Forms Based Authentication, show amongst others the claims as displayed in the figure below.

image

Figure 11: My Show My Claims Application Displaying The Claims That Were Retrieved From The ID Store Based Upon ADLDS

You can see the values for the following claims that were configured above:

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisements

2 Responses to “(2018-10-11) Configuring A New Identity Store As A Local Claims Provider In ADFS”

  1. […] UPDATED VERSION HERE: (2018-10-11) Configuring A New Identity Store As A Local Claims Provider In ADFS […]

  2. Jorge said

    Based upon the above if you want to retrieve the groups from a user, you need to extract the values in the memberOf attribute. This values are DNs and those claim values can then be sent to whatever application that can consume those. Now I can imagine you do not want to use the full DN, but just the first part right after the CN, or in words the Group Name. In that case you need to use some RegEx magic to convert from the one to the other.

    Below you can find the info that I used to achieve this goal:

    # Define The Credentials For ADFS To Use When Connecting To The ID Store
    $idStoreAccountUserName = ”
    $idStoreAccountPassword = ” | ConvertTo-SecureString -asPlainText -Force
    $idStoreAccountCreds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $idStoreAccountUserName,$idStoreAccountPassword

    # Define All The Server Instances Hosting The Identity Store
    $idStoreInstance1 = New-AdfsLdapServerConnection -HostName “” -Port “” -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic
    $idStoreInstance2 = New-AdfsLdapServerConnection -HostName “” -Port “” -SslMode None -Credential $idStoreAccountCreds -AuthenticationMethod Basic

    # Define All The Attribute-To-ClaimType Mappings For Which You Want ADFS To Automatically Retrieve From The ID Store
    # (These are the attributes and their values, if any, automatically retrieved from the ID store and stored in claims, whether or not these are issued later on in a security token)
    $mappingGivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname”
    $mappingSurname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname”
    $mappingDisplayName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute displayName -ClaimType “http://temp.org/identity/claims/displayName”
    $mappingEmployeeID = New-AdfsLdapAttributeToClaimMapping -LdapAttribute employeeID -ClaimType “http://temp.org/identity/claims/employeeID”
    $mappingDescription = New-AdfsLdapAttributeToClaimMapping -LdapAttribute description -ClaimType “http://temp.org/identity/claims/description”
    $mappingGroupDN = New-AdfsLdapAttributeToClaimMapping -LdapAttribute memberOf -ClaimType “http://temp.org/authZ/claims/GroupDN”

    # Define The Acceptance Transform Rules
    $acceptanceTransformRules = @”
    @RuleName = “User Identity Claims – UPN”
    c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”]
    => issue(claim = c);

    @RuleName = “User Identity Claims – Given Name”
    c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname”]
    => issue(claim = c);

    @RuleName = “User Identity Claims – SurName”
    c:[Type == “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname”]
    => issue(claim = c);

    @RuleName = “User Identity Claims – Display Name”
    c:[Type == “http://temp.org/identity/claims/displayName”]
    => issue(claim = c);

    @RuleName = “User Identity Claims – Employee ID”
    c:[Type == “http://temp.org/identity/claims/employeeID”]
    => issue(claim = c);

    @RuleName = “User Identity Claims – Display Name”
    c:[Type == “http://temp.org/identity/claims/description”]
    => issue(claim = c);

    @RuleName = “AuthZ Claims – Group DNs”
    c:[Type == “http://temp.org/authZ/claims/GroupDN”]
    => issue(claim = c);

    @RuleName = “AuthZ Claims – Group Names”
    c:[Type == “http://temp.org/authZ/claims/GroupDN”]
    => issue(Type = “http://temp.org/authZ/claims/GroupName”, Value = RegexReplace(RegexReplace(c.Value, “,.*?$”, “”), “CN=”, “.”));
    “@

    # Create The Local Claims Provider Trust (HRD Through List Of Claims Providers)
    Add-AdfsLocalClaimsProviderTrust -Name “External ID Store” -Identifier “urn:adlds:external:idstore” -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer “OU=People,O=CORP” -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn” -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription,$mappingGroupDN) -Enabled $true -AcceptanceTransformRules $acceptanceTransformRules

    # Create The Local Claims Provider Trust (HRD Through UPN Suffix)
    Add-AdfsLocalClaimsProviderTrust -Name “External ID Store” -Identifier “urn:adlds:external:idstore” -Type Ldap -LdapServerConnection @($idStoreInstance1,$idStoreInstance2) -UserObjectClass user -UserContainer “OU=People,O=CORP” -LdapAuthenticationMethod Basic -AnchorClaimLdapAttribute userPrincipalName -AnchorClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn” -LdapAttributeToClaimMapping @($mappingGivenName, $mappingSurname, $mappingDisplayName, $mappingEmployeeID, $mappingDescription,$mappingGroupDN) -Enabled $true -AcceptanceTransformRules $acceptanceTransformRules

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: