PageRenderTime 118ms CodeModel.GetById 19ms RepoModel.GetById 0ms app.codeStats 0ms

/articles/active-directory/active-directory-aadconnect-user-signin.md

https://gitlab.com/yeah568/azure-content
Markdown | 149 lines | 95 code | 54 blank | 0 comment | 0 complexity | 395e25bd205d4a249c4dabc6419db75f MD5 | raw file
    

  1. <properties
    2. 

  2. 	pageTitle="Azure AD Connect: User Sign In | Microsoft Azure"
    3. 

  3. 	description="Azure AD Connect user sign in for custom settings."
    4. 

  4. 	services="active-directory"
    5. 

  5. 	documentationCenter=""
    6. 

  6. 	authors="billmath"
    7. 

  7. 	manager="stevenpo"
    8. 

  8. 	editor="curtand"/>
    9. 

  9. 

  10. <tags
    11. 

  11. 	ms.service="active-directory"
    12. 

  12. 	ms.workload="identity"
    13. 

  13. 	ms.tgt_pltfrm="na"
    14. 

  14. 	ms.devlang="na"
    15. 

  15. 	ms.topic="article"
    16. 

  16. 	ms.date="05/12/2016"
    17. 

  17. 	ms.author="billmath"/>
    18. 

  18. 

  19. 

  20. 

  21. # Azure AD Connect User Sign on options
    22. 

  22. 

  23. Azure AD Connect allows your users to sign on to both cloud and on-premises resources using the same passwords.  You can choose from several different ways to enable this.
    24. 

  24. 

  25. ## Choosing a user sign-in method
    26. 

  26. For most organizations who just want to enable user sign on to Office 365, SaaS applications and other Azure AD based resources, the default Password synchronization option is recommended.
    27. 

  27. Some organizations, however, have particular reasons for using a federated sign on option such as AD FS.  These include:
    28. 

  28. 

  29. - Your organization already has AD FS or a 3rd party federation provider deployed
    30. 

  30. - Your security policy prohibits synchronizing password hashes to the cloud
    31. 

  31. - You require that users experience seamless SSO (without additional password prompts) when accessing cloud resources from domain joined machines on the corporate network
    32. 

  32. - You require some specific capabilities AD FS has
    33. 

  33. 	- On-premises multi-factor authentication using a third party provider or smart cards (learn about third party MFA providers for AD FS in Windows Server 2012 R2)
    34. 

  34. 	- Active Directory integration features such as soft account lockout or AD password and work hours policy
    35. 

  35. 	- Conditional access to both on-premises and cloud resources using device registration, Azure AD join, or Intune MDM policies
    36. 

  36. 

  37. ### Password synchronization
    38. 

  38. With password synchronization, hashes of user passwords are synchronized from your on-premises Active Directory to Azure AD.  When passwords are changed or reset on premises, the new passwords are synchronized immediately to Azure AD so that your users can always use the same password for cloud resources as they do on-premises.  The passwords are never sent to Azure AD nor stored in Azure AD in clear text.
    39. 

  39. Password synchronization can be used together with password write-back to enable self service password reset in Azure AD.
    40. 

  40. 

  41. <center>![Cloud](./media/active-directory-aadconnect-user-signin/passwordhash.png)</center>
    42. 

  42. 

  43. [More information about password synchronization](active-directory-aadconnectsync-implement-password-synchronization.md)
    44. 

  44. 

  45. 

  46. ### Federation using a new or existing AD FS in Windows Server 2012 R2 farm
    47. 

  47. With federated sign on, your users can sign on to Azure AD based services with their on-premises passwords and, while on the corporate network, without having to enter their passwords again.  The federation option with AD FS allows you to deploy a new or specify an existing AD FS in Windows Server 2012 R2 farm.  If you choose to specify an existing farm, Azure AD Connect will configure the trust between your farm and Azure AD so that your users can sign on.
    48. 

  48. 

  49. <center>![Cloud](./media/active-directory-aadconnect-user-signin/federatedsignin.png)</center>
    50. 

  50. 

  51. #### To deploy Federation with AD FS in Windows Server 2012 R2, you will need the following
    52. 

  52. 

  53. If you are deploying a new farm:
    54. 

  54. 

  55. - A Windows Server 2012 R2 server for the federation server.
    56. 

  56. - A Windows Server 2012 R2 server for the Web Application Proxy.
    57. 

  57. - a .pfx file with one SSL certificate for your intended federation service name, such as fs.contoso.com.
    58. 

  58. 

  59. If you are deploying a new farm or using an existing farm:
    60. 

  60. 

  61. - Local administrator credentials on your federation servers.
    62. 

  62. - Local administrator credentials on any workgroup (non-domain joined) servers on which you intend to deploy the Web Application Proxy role.
    63. 

  63. - The machine on which you execute the wizard must be able to connect to any other machines on which you want to install AD FS or Web Application Proxy via Windows Remote Management.
    64. 

  64. 

  65. #### Sign on using an earlier version of AD FS or a third party solution
    66. 

  66. 

  67. If you have already configured cloud sign on using an earlier version of AD FS (such as AD FS 2.0) or a third party federation provider, you can choose to skip user sign in configuration via Azure AD Connect.  This will enable you to get the latest synchronization and other capabilities of Azure AD Connect while still using your existing solution for sign on.
    68. 

  68. 

  69. ## User sign-in and user principal name (UPN)
    70. 

  70. 

  71. ### Understanding user principal name
    72. 

  72. 

  73. In Active Directory, the default UPN suffix is the DNS name of the domain in which user account created. In most cases, this is the domain name registered as the enterprise domain on the Internet. However, you can add more UPN suffixes using Active Directory Domains and Trusts.
    74. 

  74. 

  75. The UPN of the user is of the format username@domai. For example, for an active directory contoso.com user John might have UPN john@contoso.com. The UPN of the user is based on RFC 822. Although UPN and email share the same format, the value of UPN for a user may or may not be equal to the email address of the user.
    76. 

  76. 

  77. ### User principal name in Azure AD
    78. 

  78. 

  79. Azure AD Connect wizard will use the userPrincipalName attribute or let you specify the attribute (in custom install) to be used from on-premises as the user principal name in Azure AD. This is the value that will be used for signing in to Azure AD. If the value of the user principal name attribute does not correspond to a verified domain in Azure AD, then Azure AD will replace it with a default .onmicrosoft.com value.
    80. 

  80. 

  81. Every directory in Azure Active Directory comes with a built-in domain name in the form contoso.onmicrosoft.com that lets you get started using Azure or other Microsoft services. You can improve and simplify sign-in experience using custom domains. For information on custom domain names in Azure AD and how to verify a domain, please read [Add your custom domain name to Azure Active Directory](active-directory-add-domain.md#add-your-custom-domain-name-to-azure-active-directory)
    82. 

  82. 

  83. ## Azure AD sign-in configuration
    84. 

  84. 

  85. ### Azure AD sign-in configuration with Azure AD Connect
    86. 

  86. Azure AD sign-in experience is dependent on whether Azure AD is able to match the user principal name suffix of a user being synced to one of the custom domains verified in the Azure AD directory. Azure AD Connect provides help while configuring Azure AD sign-in settings, so that user sign-in experience in cloud is similar to the on-premises experience. Azure AD Connect lists the UPN suffixes defined for the domain(s) and tries to match them with a custom domain in Azure AD and helps you with the appropriate action that needs to be taken.
    87. 

  87. The Azure AD sign-in page lists out the UPN suffixes defined for the on-premises Active Directory and displays the corresponding status against each suffix. The status values can be one of the below:
    88. 

  88. 

  89. * Verified : Azure AD Connect could find a matching verified domain in Azure AD and no action is needed
    90. 

  90. * Not verified : Azure AD Connect could find a matching custom domain in Azure AD but it is not verified. User should verify the custom domain in order to ensure that the UPN suffix of the users is not changed to default .onmicrosoft.com suffix after sync.
    91. 

  91. * Not added : Azure AD Connect could not find a custom domain corresponding to the UPN suffix. User must add and verify a custom domain corresponding to the UPN suffix in order to ensure that the UPN suffix of the user is not changed to default .onmicrosoft.com suffix after sync.
    92. 

  92. 

  93. Azure AD sign-in page lists the  UPN suffix(s) defined for the on-premises Active Directory and the corresponding custom domain in Azure AD with the current verification status. In custom installation, you can now select the attribute for user principal name on the **Azure AD sign-in** page.
    94. 

  94. 

  95. ![Azure AD sign-in page](.\media\active-directory-aadconnect-user-signin\custom_azure_sign_in.png)
    96. 

  96. 

  97. You can click on the refresh button to re-fetch the latest status of the custom domains from Azure AD.
    98. 

  98. 

  99. ###Selecting attribute for user principal name in Azure AD
    100. 

  100. 

  101. UserPrincipalName - The attribute userPrincipalName is the attribute users will use when they sign-in to Azure AD and Office 365. The domains used, also known as the UPN-suffix, should be verified in Azure AD before the users are synchronized. It is strongly recommended to keep the default attribute userPrincipalName. If this attribute is non-routable and cannot be verified then it is possible to select another attribute, for example email, as the attribute holding the sign-in ID. This is known as Alternate ID. The Alternate ID attribute value must follow the RFC822 standard. An Alternate ID can be used with both password Single Sign-On (SSO) and federation SSO as the sign-in solution.
    102. 

  102. 

  103. >[AZURE.NOTE] Using an Alternate ID is not compatible with all Office 365 workloads. For more information, please refer to [Configuring Alternate Login ID](https://technet.microsoft.com/library/dn659436.aspx).
    104. 

  104. 

  105. #### Different custom domain states and effect on Azure sign-in experience
    106. 

  106. It is very important to understand the relationship between the custom domain states in your Azure AD directory and the UPN suffixes defined on-premises. Let us go through the different possible Azure sign-in experiences when you are setting up sycnhronization using Azure AD Connnect.
    107. 

  107. 

  108. For the information below, let us assume that we are concerned with the UPN suffix contoso.com which is used in the on-premises directory as part of UPN, for example user@contoso.com.
    109. 

  109. 

  110. ###### Express Settings / Password Synchronization
    111. 

  111. | State         | Effect on user Azure sign-in experience |
    112. 

  112. |:-------------:|:----------------------------------------|
    113. 

  113. | Not added | In this case no custom domain for contoso.com has been added in Azure AD directory. Users who have UPN on-premises with suffix @contoso.com, will not be able to use their on-premises UPN to sign-in to Azure. They will instead have to use a new UPN provided to them by Azure AD by adding the suffix for default Azure AD directory. For example, if you are syncing users to Azure AD directory azurecontoso.onmicrosoft.com then the on-premises user user@contoso.com will be given a UPN of user@azurecontoso.onmicrosoft.com|
    114. 

  114. | Not verified | In this case we have a custom domain contoso.com added in Azure AD directory, however it is not yet verified. If you go ahead with syncing users without verifying the domain, then the users will be assigned a new UPN by Azure AD just like it did in the 'Not added' scenario.|
    115. 

  115. | Verified | In this case we have a custom domain contoso.com already added and verified in Azure AD for the UPN suffix. Users will be able to use their on-premises user principal name, e.g. user@contoso.com, to sign-in to Azure after they are synced to Azure AD|
    116. 

  116. 

  117. ###### AD FS Federation
    118. 

  118. You cannot create a federation with the default .onmicrosoft.com domain in Azure AD, or an unverified custom domain in Azure AD. When you are running the Azure AD Connect wizard, if you select an unverified domain to create a federation with then Azure AD Connect will prompt you with necessary records to be created where your DNS is hosted for the domain. For more information see [here](active-directory-aadconnect-get-started-custom.md#verify-the-azure-ad-domain-selected-for-federation).
    119. 

  119. 

  120. If you selected User sign-in option as "Federation with AD FS", then you must have a custom domain to continue with creating a federation in Azure AD. For our discussion, this means that we should have a custom domain contoso.com added in Azure AD directory.
    121. 

  121. 

  122. | State         | Effect on user Azure sign-in experience |
    123. 

  123. |:-------------:|:----------------------------------------|
    124. 

  124. | Not added | In this case Azure AD Connect could not find a matching custom domain for the UPN suffix contoso.com in Azure AD directory. You need to add a custom domain contoso.com if you need users to sign-in using AD FS with their on-premises UPN like user@contoso.com.|
    125. 

  125. | Not verified | In this case Azure AD Connect will prompt you with appropriate details on how you can verify your domain at a later stage|
    126. 

  126. | Verified | In this case you can go ahead with the configuration without any further action|  
    127. 

  127. 

  128. ## Changing user sign-in method
    129. 

  129. 

  130. You can change the user sign-in method from Federation to Password Sync using the tasks avaialble in Azure AD Connect after the initial configuration of Azure AD Connect using the wizard. Run the Azure AD Connect wizard again and you will be presented with a list of tasks that you can perform. Select **Change user sign-in** from the list of tasks. 
    131. 

  131. 

  132. ![Change user sign-in"](./media/active-directory-aadconnect-user-signin/changeusersignin.png)
    133. 

    134. 

  134. On the next page, you will be asked to provide the credentials for Azure AD.
    135. 

  135. 

  136. ![Connect to Azure AD](./media/active-directory-aadconnect-user-signin/changeusersignin2.png)
    137. 

  137. 

  138. On the **User sign-in** page, select **Password Synchronization**. This will change the directory from federated to a managed one.
    139. 

  139. 

  140. ![Connect to Azure AD](./media/active-directory-aadconnect-user-signin/changeusersignin3.png)
    141. 

  141. 

  142. >[AZURE.NOTE] If you are making only a temporary switch to password synchronization, then check the **Do not convert user accounts**. Not checking on the option will lead to conversion of each user to federated and it can take
    143. 

  143.   
    144. 

  144. ## Next steps
    145. 

  145. Learn more about [Integrating your on-premises identities with Azure Active Directory](active-directory-aadconnect.md).
    146. 

  146. 

  147. Learn more about [Azure AD Connect: Design concepts](active-directory-aadconnect-design-concepts.md)
    148. 

  148. 

  149. 

  150.