First published on TechNet on Apr 20, 2014
With all of this great talk on the Windows 8.1 Client Update we here at ASKPFEPLAT didn’t want to leave out one important Active Directory Federation Server (AD FS) feature released with the Windows Server 2012 R2 Update.
My Name is Keith Brewer and I am here to introduce this AD FS login enhancement feature called AlternateLoginID.
This blog is designed to discuss this new feature so you can test in your own AD FS lab. Don’t have a Lab? Head here to get started
AlternateLoginID is a feature introduced with Windows Server 2012 R2 Update that facilitates login to AD FS with an administratively defined user attribute.
Many customers would like their end users to only know about their email address for ease of use when signing in. However, within a customer's AD DS environment, administrators may be unable to ensure that user UserPrincipalName (UPN) and email addresses match. In addition, in some AD DS environments UPNs are not publically routable and that may pose challenges for some SaaS providers.
In Windows Server 2012 R2 Update, AD FS provides the capability for an administrator to enable user sign in via an alternate login ID that is an attribute of the user object in AD DS.
Once configured AD FS will prefer to locate the user account within AD DS by the defined alternate attribute first instead of UPN.
End users can still sign in to applications that rely on AD FS using any form of user identifier that is accepted by Active Directory Domain Services (AD DS). These include UPN ( johndoe@contoso.com ) or domain qualified SamAccountName (Contoso\johndoe or contoso.com\johndoe).
To support this feature, when a user authenticates successfully via the value of AlternateLoginID, a new claim will be entered into the claims pipeline. There is a new claim type for alternate login ID, described as follows:
http://schemas.microsoft.com/ws/2013/11/alternateloginid
· Display Name: Alternate Login ID
· Description: Alternate login of the user
(Updated 5-11-14 to provide additional clarity on the claim description)
The Alternate Login ID claim description need not be present for the AlternateLoginID feature to be implemented. However if administrators wish to author claims rules with this claim (as we do in the lab below for demonstration purposes) it may be necessary for administrators to add the claim description manually.
The Alternate Login ID claim description will only be present by default on AD FS Farms created on Windows 2012 R2 with the update applied. Administrators of existing AD FS Farms on 2012 R2 that are subsequently updated with 2919355 (who wish to author a claims rule with the new claim) will need to add the claim description manually. This can be done via the AD FS MGMT UI or with PowerShell
On one of the federation servers, open PowerShell .
Add-AdfsClaimDescription -Name "AlternateLogin ID" -ClaimType http://schemas.microsoft.com/ws/2013/11/alternateloginid -ShortName AlternateLoginID -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Alternate login ID of the user"
Prerequisites
· The AD FS Service Account must have read permission to the Canonical Name attribute for all users in the directory.
o By default, Authenticated Users have this permission and should be sufficient for the AD FS Service Account.
o If multiple forests are identified in “LookupForests’ these permissions are required for all users in each forest.
· Only supported on 2012 R2 with the Windows Server 2012 R2 Update applied
o This update must be applied to all federation servers
· The alternate login ID attribute must be indexed
o This is required for PowerShell to complete the configuration
· The alternate login ID attribute must be in the global catalog
o This is required for PowerShell to complete the configuration
· The alternate login ID attribute must be UPN format compatible
o Schema Details for UPN:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx
o The attribute value must be in UPN format (Prefix@suffix), or domain qualified samAccountNames (NETBIOS Domain\SamAccountName or DOMAIN FQDN\SamAccountName). This is due to that format being required on the AD FS Sign-On Page.
· The value of the alternate login ID attribute must be unique across all the users
o If multiple forests are identified in “LookupForests’ the value of the alternate login ID must be unique across all forests
Enabling AlternateLoginID
Install Windows Server 2012 R2 Update
Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update April 2014
http://support.microsoft.com/kb/2919355
Enabling AlternateLoginID via PowerShell
The AlternateLoginID feature is enabled via PowerShell, as follows:
More information on this Powershell Command is here
Set-ADFSClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
Verifying that AlternateLoginID is enabled
PowerShell is also used to verify the AlternateLoginID feature, as follows:
Get-ADFSClaimsProviderTrust –Identifier “AD Authority” | ft AlternateLoginID,LookupForests
Disabling AlternateLoginID
The AlternateLoginID Feature is disabled via PowerShell, as follows:
Set-ADFSClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL
How AlternateLoginID Works
Conversation Flow:
1.) Credentials are provided to the AD FS Server
The AlternateLoginID lookup only occurs for the following scenarios
· User signs in using AD FS form-based page (FBA)
· User on rich client application signs in against username & password endpoint
· User performs pre-authentication through Web Application Proxy (WAP)
· User updates the corporate account password with AD FS update password page
2.) Is AlternateLoginID Enabled
If enabled the AD FS Server will issue an LDAP Search against all defined lookup forests targeting enabled user objects with a matching user supplied value in the defined AlternateLoginID attribute.
This query will return the user objects SamAccountName, CanonicalName & DistinguishedName attributes.
3.) Was Value Found
If no then attempt to logon user with supplied credentials
4.) Was Value Found for a unique user object across all lookup forests
If no then there was a conflict, throw an error, Logon Failure
5.) Are the values for Canonical Name and SamAccountName properly formatted
If no, Throw and Error, Logon Failure.
If yes, build logon credentials from results of the LDAP query to logon the user.
Best Practices
When selecting the attribute that will serve as the AlternateLoginID, administrators should consider the following:
· The value of the AlternateLoginID attribute must be unique across all users in all defined lookup forests
· The value for AlternateLoginID attribute should be unique across all users AlternateLoginID attribute as well as all users UserPrincipalName attribute.
· Users should not be able to update/edit their own (or other users) value for Alternate Login ID attribute
When considering AlternateLoginID it is important to carefully consider each relying party trust and how they may / may not be affected by this change. If current relying party’s claims rules depend on UserPrincipalName value, the rules may need to be updated with the value of the defined AlternateLoginID attribute.
If multiple lookup forests are defined, administrators should consider placing a global catalog for each forest in close proximity to the AD FS Servers.
Test lab overview
In this test lab, AD FS is deployed with:
(Updated 4-28-14 to provide additional clarity on lab portion.)
· One Server that is configured as a Domain Controller (Per AD FS Requirements on Windows Server 2012 R2, “For AD FS to be supported, domain controllers in all user domains and in the domain that AD FS servers are joined to must be running Windows Server 2008 or later".)
· One Member Server running Windows Server 2012 R2 with KB2919355 that is configured as an Active Directory Federation Server
· One standalone server running Windows Server 2012 R2 with KB2919355 that is configured as an Web Application Proxy (WAP) Server
· One Member Server that is configured as a Web Server and host a relying party claims aware application (any supported server operating system is fine for the Web Server for the purposes of this lab)
· One standalone client computer (any supported client operating system is fine for the internet client for the purposes of this lab.)
This lab configuration is originally based on the following setup:
How to Build Your AD FS Lab on Server 2012 Part 1 http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-AD FS-lab-on-server-2012...
How to Build Your AD FS Lab on Server 2012, Part2: Web SSO http://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-AD FS-lab-on-server-2012...
How to Build Your ADFS Lab on Server 2012 Part 3: ADFS Proxy http://blogs.technet.com/b/askpfeplat/archive/2014/03/17/how-to-build-your-adfs-lab-on-server-2012-...
AD FS Servers were then migrated to Windows Server 2012 R2
No worries there ASKPFE has you covered as well
Migrating Active Directory Federation Services Role Service to Windows Server 2012 R2 http://technet.microsoft.com/en-us/library/dn486815.aspx
Lastly the Windows Server 2012 R2 April 2014 Update was applied
Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update April, 2014 http://support.microsoft.com/kb/2919355
Important
The following instructions are for configuring an AD FS test lab using the minimum number of computers. Individual computers are needed to separate the services provided on the network and to clearly show the desired functionality. This configuration is neither designed to reflect best practices nor does it reflect a desired or recommended configuration for a production network. The configuration, and all other configuration parameters, is designed only to work on a separate test lab network.
Attempting to adapt this AD FS test lab configuration to a production deployment can result in availability, configuration or functionality issues.
This AD FS lab consists of three subnets that simulate the following:
· The Internet
· A DMZ network
· An internal network
Software requirements
The following are required components of the test lab:
All AD FS and WAP servers must be running Windows Server 2012 R2 with KB2919355
Step 1: Enable the Alternate Login ID Feature in AD FS
The default configuration is for this feature to be disabled.
Below are the steps required to enable this feature:
To enable alternate login ID
1. On one of the federation servers, open Power Shell .
Set-ADFSClaimsProviderTrust –Target Identifier “AD AUTHORITY” –AlternateLoginID <attribute> -LookupForests <forest domain>
Step 2: Configure Claims Rules for Demonstration
Add Pass through rule to Relying party for UPN
1. Log onto AD FS Server as Administrator
2. In Server Manager, Select the Tools Menu
3. In the Tools Menu, Select AD FS Management
4. In AD FS Management, On the console tree expand Trust Relationships
5. Under Trust Relationships, Expand Relying Party Trusts
6. Right Click the Relying Party Trust for your Claims Aware Application
7. In the context menu, Select Edit Claims Rules…
8. In Edit Claims Rules, Select Add Rule…
9. In Add Transform Claim Rule, in the Claim Rule Template dropdown
a. Select “Pass Through or Filter an Incoming Claim”
10. In the Add “Transform Claim Rule Wizard”
a. Choose any appropriate name
b. Incoming Claim type, Select UPN
c. Leave default selection “Pass Through all Claim Values”
11. Select Finish
Add Pass through rule to Relying party for Alternate Login ID
1. Log onto AD FS Server as Administrator
2. In Server Manager, Select the Tools Menu
3. In the Tools Menu, Select AD FS Management
4. In AD FS Management, On the console tree expand Trust Relationships
5. Under Trust Relationships, Expand Relying Party Trusts
6. Right Click the Relying Party Trust for your Claims Aware Application
7. In the context menu, Select Edit Claims Rules…
8. In Edit Claims Rules, Select Add Rule…
9. In Add Transform Claim Rule, in the Claim Rule Template dropdown
a. Select “Pass Through or Filter an Incoming Claim”
10. In the Add “Transform Claim Rule Wizard”
a. Choose any appropriate name
b. Incoming Claim type, Select Alternate Login ID
(Updated 5-11-2014 to provide additional clarity on Claim Description.)
If your AD FS Farm was built on Windows Server 2012 R2 and then 2919355 was applied the Alternate Login ID claim description will need to be added manually.
Add-AdfsClaimDescription -Name "AlternateLogin ID" -ClaimType http://schemas.microsoft.com/ws/2013/11/alternateloginid -ShortName AlternateLoginID -IsAccepted $True -IsOffered $True -IsRequired $False -Notes "Alternate login ID of the user"
c. Leave default selection “Pass Through all Claim Values”
Select Finish
Step 3: Take Note of Test User Attribute Values
1. Log on to Domain Controller as Administrator
2. Open PowerShell
3. Run the following command
Get-ADUser –Filter ‘SamAccountName –eq “TESTUSERNAME”’ –Properties * | fl SamAccountName,UserPrincipalName,Mail
If you receive the following Error:
Import the Active Directory Powershell Module with:
Import-Module ActiveDirectory
Step 4: Navigate to ClaimsWeb Application from External Client
1. Log onto External Client
2. Open Internet Explorer, Navigate to ClaimsWeb Application
3. On Forms Based Logon (WAP) enter user Email Address and Password
4. Notice that since we logged in via an Alternate Login ID that claim type is included (due to the above claims rules)
Additional Information
For additional information including event’s and performance counters specifically added for this feature see:
Configuring Alternate Login ID
http://technet.microsoft.com/en-us/library/dn659436.aspx
(Updated 5-11-2014 to provide additional information on this feature and Azure Active Directory.)
Using Alternate Login ID’s with Azure Active Directory
Keith “What’s your ALTID” Brewer