Configuring Alternate Login ID

Article
08/31/2016

Users can sign in to Active Directory Federation Services (AD FS)-enabled applications using any form of user identifier that is accepted by Active Directory Domain Services (AD DS). These include User Principal Names (UPNs) (johndoe@contoso.com) or domain qualified sam-account names (contoso\johndoe or contoso.com\johndoe).

Oftentimes, you want your end users to only be aware of and know their email addresses when signing in. However sometimes for various reasons your AD DS environment is not able to ensure that user UPNs match their email addresses. Also, SaaS providers such as Office 365 with Azure Active Directory (AAD) require user login IDs to be fully internet routable since the non-routable domain names cannot be verified. In other words, if your on-premises UPNs are using non-routable domains (i.e. "contoso.local", fabrikam) or your cannot change your existing UPN's to match your cloud domain due to application dependencies on your on-premises UPN, you cannot use your on-premises UserPrincipalNames to authenticate your users with AAD.

To solve this problem, you can enable the alternate login ID functionality. This allows you to configure a sign-in experience where this alternate login ID is an attribute of a user object in AD DS other than the UPN.

Note

Using the 'mail' attribute for alternate login ID functionality is strongly recommended.

One of the benefits of this feature is that it enables you to adopt SaaS providers, such as Office 365 without modifying your on-premise UPNs. It also enables you to support line-of-business service applications with consumer-provisioned identities.

Important

We have recently changed our support statement on using Alternate ID with Exchange Hybrid. For the best user experience in an Exchange Hybrid environment, we recommend using the same set of credentials for on-premises and Exchange Online. It is also recommended that customers that use Office 2013 clients enable Modern Authentication. Please refer to the table below for the expected user experience using various clients.

Client Types	Support Statement - Regular and Modern Authentication	Description	Additional Information
Outlook	Regular Authentication: You must be on a domain joined machine and connected to the corporate network Modern Authentication: Supported	You can only use Alternate ID in environments that do not allow external access for mailbox users. This means that users can only authenticate to their mailbox in a supported way when they are connected and joined to the corporate network, on a VPN, or connected via Direct Access. If you opt to configure Modern Authentication (Known as ADAL) you can use Outlook from non-domain joined/connected machines, but you will get a couple of extra prompts when configuring your Outlook profile. See the first image below the table for user experience demo.	Modern Authentication in Office 2013
Hybrid Public Folders	Regular Authentication: Not supported Modern Authentication: Supported	Hybrid Public Folders will not be able to expand if Alternate ID's are used and therefore should not be used today with regular authentication methods. If you want to be able to use Public Folder in Hybrid you will have to configure Modern Authentication (Known as ADAL). See the first image below the table for user experience demo.	Modern Authentication in Office 2013
Cross premises Delegation	Not supported	Currently cross premises permissions are not supported in a hybrid configuration, but they also will not work if you use AltID.
Archive mailbox access (Mailbox on-premises - archive in the cloud)	Regular Authentication: Not supported Modern Authentication: Supported	Users will get an extra prompt for credentials when accessing the archive, they will have to provide their alternate ID when prompted. In addition to getting the latest updates and completing Modern Authentication, the following registry key should be deployed on each client to ensure proper connectivity: [HKEY_CURRENT_USER\Software\Microsoft\Exchange] "AlwaysUseMSOAuthForWebServices"=dword:00000001
Office 365 Pro Plus activation page	Supported - client side registry key recommended	With Alternate ID configured you will see the on-premises UPN is pre-populated In the verification field. This needs to be changed to the alternate Identity that is being used. We recommend to use the client side reg key noted in the link column . See the second image below the table for user experience demo.	Office 2013 and Lync 2013 periodically prompt for credentials to SharePoint Online, OneDrive, and Lync Online
Lync / Skype for Business integration with Outlook (free busy, OOF, Calendar, etc)	Supported but there is a potential for user confusion (See Description)	If Skype for Business or Lync says “Exchange needs your credentials”, you need to provide the credentials that are valid for were the mailbox is located. If the mailbox is in the cloud you need to provide the Alternate ID if the Mailbox is on-premises you need to provide the on-premises UPN.
ActiveSync for all mobile devices	Requires MDM solution or manual device configuration	For the autodiscover portion of ActiveSync to work you need to use an MDM solution, otherwise you will have to show your users how to manually configure ActiveSync profiles and be OK with the fact that if there is a reconfiguration needed it will be manual.	Use step 4 in the following: A mobile device can't connect to Exchange Online by using Exchange ActiveSync
Outlook Web Access	Supported
Outlook Mobile Apps for Android, IOS, and Windows Phone	Supported
OneDrive for Business	Supported - client side registry key recommended	With Alternate ID configured you will see the on-premises UPN is pre-populated In the verification field. This needs to be changed to the alternate Identity that is being used. We recommend to use the client side reg key noted in the link column. See the second image below the table for user experience demo.	Office 2013 and Lync 2013 periodically prompt for credentials to SharePoint Online, OneDrive, and Lync Online
OneDrive for Business Mobile Client	Supported

In order to configure alternate login ID, you must perform the following tasks:

Configure your AD FS claims provider trusts to enable alternate login ID

Install KB2919355 (you can get it via Windows Update Services or locate it on https://support.microsoft.com.) For more information, see https://go.microsoft.com/fwlink/?LinkID=396590.
Update the AD FS configuration by running the following PowerShell cmdlet on any of the federation servers in your farm (if you have a WID farm, you must run this command on the primary AD FS server in your farm):
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
```
AlternateLoginID is the LDAP name of the attribute that you want to use for login.

LookupForests is the list of forest DNS that your users belong to.

To enable alternate login ID feature, you must configure both ‘AlternateLoginID’ and ‘LookupForests’ parameters with a non-null, valid value.

In the following example, you are enabling alternate login ID functionality such that your users with accounts in contoso.com and fabrikam.com forests can log in to AD FS-enabled applications with their "mail" attribute.
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests contoso.com,fabrikam.com
```

To disable this feature, set the value for both parameters to be null.

Set-AdfsClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL

To enable alternate login ID with Azure AD, no additional configurations steps are needed when using Azure AD Connect. Alternate ID can be configured directly from the wizard. See uniquely identifying your users under the section Connect to Azure AD.

Additional Details & Considerations

When enabled, the alternate login ID feature is only available for username/password authentication across all the user name/password authentication protocols supported by AD FS (SAML-P, WS-Fed, WS-Trust, and OAuth).
When Windows Integrated Authentication (WIA) is performed (for example, when users try to access a corporate application on a domain-joined machine from intranet and AD FS administrator has configured the authentication policy to use WIA for intranet), UPN will be used for authentication. If you have configured any claim rules for the relying parties for alternate login ID feature, you should make sure those rules are still valid in the WIA case.
When enabled, the alternate login ID feature requires at least one global catalog server to be reachable from the AD FS server for each user account forest that AD FS supports. Failure to reach a global catalog server in the user account forest will result in AD FS falling back to use UPN. By default all the domain controllers are global catalog servers.
When enabled, if the AD FS server finds more than one user object with the same alternate login ID value specified across all the configured user account forests, it will fail the login.
When alternate login ID feature is enabled, AD FS will try to authenticate the end user with alternate login ID first and then fall back to use UPN if it cannot find an account that can be identified by the alternate login ID. You should make sure there are no clashes between the alternate login ID and the UPN if you want to still support the UPN login. For example, setting one’s mail attribute with the other’s UPN will block the other user from signing in with his UPN.
If one of the forests that is configured by the administrator is down, AD FS will continue to look up user account with alternate login ID in other forests that are configured. If AD FS server finds a unique user objects across the forests that it has searched, a user will log in successfully.
You may additionally want to customize the AD FS sign-in page to give end users some hint about the alternate login ID. You can do it by either adding the customized sign-in page description (for more information, see Customizing the AD FS Sign-in Pages) or customizing “Sign in with organizational account” string above username field (for more information, see Advanced Customization of AD FS Sign-in Pages).
The new claim type that contains the alternate login ID value is https://schemas.microsoft.com/ws/2013/11/alternateloginid

Events and Performance Counters

The following performance counters have been added to measure the performance of AD FS servers when alternate login ID is enabled:

Alternate Login Id Authentications: number of authentications performed by using alternate login ID
Alternate Login Id Authentications/Sec: number of authentications performed by using alternate login ID per second
Average Search Latency for Alternate Login ID: average search latency across the forests that an administrator has configured for alternate login ID

The following are various error cases and corresponding impact on a user’s sign-in experience with events logged by AD FS:

Error Cases	Impact on Sign-in Experience	Event
Unable to get a value for SAMAccountName for the user object	Login failure	Event ID 364 with exception message MSIS8012: Unable to find samAccountName for the user: '{0}'.
The CanonicalName attribute is not accessible	Login failure	Event ID 364 with exception message MSIS8013: CanonicalName: '{0}' of the user:'{1}' is in bad format.
Multiple user objects are found in one forests	Login failure	Event ID 364 with exception message MSIS8015: Found multiple user accounts with identity '{0}' in forest '{1}' with identities: {2}
Multiple user objects are found across multiple forests	Login failure	Event ID 364 with exception message MSIS8014: Found multiple user accounts with identity '{0}' in forests: {1}

Additional Details & Considerations

Events and Performance Counters

See Also

Additional resources

Configuring Alternate Login ID

To configure alternate login ID

Additional Details & Considerations

Events and Performance Counters

See Also

Additional resources