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-10-20) Configuring A New Identity Store As A Claims Provider In ADFS

Posted by Jorge on 2014-10-20


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);"

image

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);"

image

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!

image

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

image

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)

image

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

image

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

image

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

image

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

9 Responses to “(2014-10-20) Configuring A New Identity Store As A Claims Provider In ADFS”

  1. jason said

    This didn’t work for me…. When I go to the IdpInitiatedSignon page and click the secondary IdP, it looks like the browser is trying to redirect me and the querystring contains something like “redirectIdp=urn:adlds:idstore”

    I get this error, any ideas?
    “no authentication provider could be found that supports the authentication methods specified in the claims provider trust.”

    • Jorge said

      my assumption is that redirection works, but that the configured LDAP store is not working properly. can you use LDP to authenticate against it using the service account and the regular user?

  2. jason said

    I am getting errors running add-adfsLocalClaimsProviderTrust: an error occurred parsing the account store specific parameters…

  3. Pen Warner said

    Hi Jorge

    Great article, have got everything setup however whenever I try to run the Add-AdfsLocalClaimsProviderTrust I get the Error The supplied Credential is invalid. No matter what account I use in every conceivable format it gives the same error,

    “Add-AdfsLocalClaimsProviderTrust : MSIS3328: Unable to query the LDAP servers. The supplied credential is invalid.
    Error code: 49
    Server response message: 8009030C: LdapErr: DSID-0C0903C8, comment: AcceptSecurityContext error, data 2030, v2580”

    I know the account has permissions and I can connect and bind using ldp.

    Any ideas what I could be doing wrong?

    Many thanks

    Pen

    PS: the accounts I have tried:

    DOMAIN\Username
    Username@domain

    User DN of LDS user in the administrators group.

  4. Maras said

    Unfortunately I have a problem also. I configured ADFS follow you article and I use application based also on your previous article. When I try to authenticate using account from AD LDS I get an error : Incorrect User ID or password. Obviously credentials are OK. I noticed some ADFS errors in event viewer. It looks like that ADFS is not able to find accounts in AD LDS. error states :
    test2@test1.xx.xx.test-The object does not exist.
    Error code: NoSuchObject

    This error concerns service account (used during establish trust connection) and any other accounts located in AD LDS. The path in -UserContainer parameter looks correct in my opinion.

    • Jorge said

      is the service account in ADLDS?
      Did you assign the service account at least the Readers role in the NC where the objects are?

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: