Export (0) Print
Expand All

Configuring Alternate Login ID


Updated: April 10, 2014

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.


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 with AAD without modifying your on-premise UPNs. It also enables you to support line-of-business service applications with consumer-provisioned identities.


The Alternate Login ID feature is not compatible with Exchange Online Hybrid Deployments.  Customers that wish to configure Exchange Online Hybrid Deployments with Office 365 must not configure Alternate Login ID.

The Alternate Login ID feature may impact various other Azure AD and Office 365 scenarios including:

  • Office 365 ProPlus activation may require explicit sign-in

  • InTune customers using SCCM connectors may require additional configuration.

Contact your Account representative for more information on these incompatibilities.

In order for the authentication request to succeed, the AD DS attribute that you want to configure as the alternate login ID must satisfy the following requirements:

  • The alternate login ID attribute must be indexed

  • The alternate login ID attribute must be in the global catalog. (If the isMemberOfPartialAttributeSet property on the schema object of the alternate logon ID is set to true, it will mean the alternate login ID is present in the global catalog.)

  • The alternate login ID attribute must be a well-formed SMTP address and conforms to the UPN rules outlined in Password policy in Azure AD 

  • The alternate login ID attribute must have a single value

  • The CanonicalName attribute on the user object must be accessible to the service account that is used to run the AD FS servers

  • The value of the alternate login ID attribute must be unique across all the forests that AD FS is configured to use when enabling this feature

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

  1. Install KB2919355 (you can get it via Windows Update Services or locate it on https://support.microsoft.com.) For more information, see http://go.microsoft.com/fwlink/?LinkID=396590.

  2. 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
  3. To disable this feature, set the value for both parameters to be null.

    Set-AdfsClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL
  4. To enable alternate login ID with AAD, additional configurations steps are needed including modifying the Directory Sync configuration to use the attribute selected in the steps above and updating relying party claim issuance rules for AAD. For detailed steps on modifying the Directory Sync configuration, see Using Alternate Login IDs with Azure Active Directory.

  • 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 http://schemas.microsoft.com/ws/2013/11/alternateloginid

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


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}

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft