(2014-10-20) Configuring A New Identity Store As A Claims Provider In ADFS

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

–

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 vNext, currently in Technical Preview, 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!

–

At the time of writing, for the passive federation protocols (e.g. SAML, WS-Federation and Oauth) and the active federation protocols (e.g. WS-Trust), ADFS v4.0 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.

—

I have the following ID Store:

• Type: ADLDS (LDAP)
• Server (1): IDSTORE.ADCORP.LAB
• LDAP Port (1): 5389
• LDAPS Port (1): 5636
• Account UserName: SVC_R1_IDSTORE@ADLDSCORP.LAB
• Account Password: pwd

–

# Import The ADFS PowerShell Module

Import-Module ADFS

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

$idStoreAccountUserName = ‘SVC_R1_IDSTORE@ADLDSCORP.LAB’
$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 IDSTORE.ADCORP.LAB -Port 5636 –SslMode SSL –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"

# Create The Local Claims Provider Trust  (HRD Through List Of Claims Providers)

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

Figure 1a: Creating A Local Claims Provider Based Upon ADLDS In ADFS v4.0 (HRD Will Be Through List Of Claims Providers)

–

REMARK: in this case the yellow error occurs because I did not specify anything for the organizational suffix for this local claims provider

–

# Create The Local Claims Provider Trust (HRD Through UPN Suffix)

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

Figure 1b: Creating A Local Claims Provider Based Upon ADLDS In ADFS v4.0 (HRD Will Be Through UPN Suffix)

–

REMARK: in this case the yellow error occurs because I have not enable and also not configured device registration

–

Now let’s try this!

Figure 2: Targeting The "Show My Claims App" And Selecting ADFS v4.0 As The Proposed IdP

–

Figure 3a: Home Realm Discovery Page In ADFS v4.0 Showing All Configured/Available Identity Providers (Claims Providers)

–

Selecting/clicking "ADLDS-ID-Store", presents the Forms Based Logon Page In ADFS v4.0 (figure 4)

Figure 3b1: Home Realm Discovery Page In ADFS v4.0 NOT Showing All Configured/Available Identity Providers (Claims Providers)

–

Selecting/clicking "Other Organization", presents the Home Realm Discovery Page Based Upon UPN Suffixes of organizational accounts

Figure 3b2: Home Realm Discovery Page In ADFS v4.0 Based Upon UPN Suffix Of Organizational Accounts

–

Figure 4: Forms Based Logon Page To Enter The Credentials Of A User Account In The Configured ID Store

–

Figure 5: The List Of Issued Claims To The "Show My Claims" App Based Upon What Was Extracted From The ADLDS ID Store

–

SOME REMARKS: During my tests I also tried to the following setup:

Specifying just 3 attribute-to-claim mappings

$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

–

…And then use a file with the content of the Acceptance Transform Rules

File Name: D:\TEMP\ADLDS-ID-Store_AcceptanceTransformRulesFile.txt

Contents:
@RuleName = "Identity Claims – UPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – GivenName"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – SurName"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – DisplayName"
c:[Type == "http://temp.org/identity/claims/displayName", Issuer == "urn:adlds:idstore"]
=> issue(claim = c);

@RuleName = "Identity Claims – EmployeeID"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer == "urn:adlds:idstore"]
=> issue(store = "ADLDS ID Store", types = ("http://temp.org/identity/claims/employeeID"), query = ";employeeID;{0}", param = c.Value);

–

All the claims rules worked, except the last one called "Identity Claims – EmployeeID". The reason for that is that when you specify store = "ADLDS ID Store", ADFS expects to find an attribute store with that name, but for which in this case it is not an attribute but rather an identity store. It is possible to extract identity info from attribute stores when using a local claims provider trust, as long as the attribute store definition exists in ADFS and it actually 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/ ########
———————————————————————————————

Advertisement