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!

Archive for the ‘Identity Stores’ Category

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

Posted in Active Directory Federation Services (ADFS), Identity Stores | 9 Comments »

(2014-10-03) ADFS In vNext To Support Other Identity Stores Than AD Only

Posted by Jorge on 2014-10-03


Taken from: http://technet.microsoft.com/en-US/library/hh831502.aspx#BKMK_preview

For the Windows Server Technical Preview, the AD FS server role includes the same functionality and feature set that is available in Windows Server 2012 and Windows Server 2012 R2. It also includes new features that enable you to configure AD FS to authenticate users stored in non-AD directories, such as X.500 compliant Lightweight Directory Access Protocol (LDAP) directories and SQL databases. In many organizations, identity management solutions consist of a combination of Active Directory, AD LDS and third-party LDAP directories, as well as SQL databases. With the AD FS support of the non-AD identity stores, you can benefit from the entire enterprise-ready AD FS feature set regardless of where your user identities are stored

YES!, YES!, YES!, YES!, YES!, YES!, YES!, YES!, YES!, YES!. F-I-N-A-L-L-Y !!!

For more information, see Configure AD FS to authenticate users stored in LDAP directories.

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

Posted in Active Directory Federation Services (ADFS), Identity Stores | 2 Comments »

 
%d bloggers like this: