Merge pull request #91228 from MicrosoftDocs/master

Merge Master to Live, 3 AM

Author: PMEds28

.vscode/extensions.json

@@ -0,0 +1,5 @@
+{
+    "recommendations": [
+        "docsmsft.docs-authoring-pack"
+    ]
+}

articles/active-directory-domain-services/TOC.yml

@@ -25,6 +25,8 @@
       href: powershell-create-instance.md
 - name: Concepts
   items:
+    - name: Administration basics
+      href: administration-concepts.md
     - name: Common deployment scenarios
       href: scenarios.md
     - name: How Azure AD DS synchronization works

articles/active-directory-domain-services/administration-concepts.md

@@ -0,0 +1,68 @@
+---
+title: Management concepts for Azure AD Domain Services | Microsoft Docs
+description: Learn about how to administer an Azure Active Directory Domain Services managed domain and the behavior of user accounts and passwords
+services: active-directory-ds
+author: iainfoulds
+manager: daveba
+
+ms.service: active-directory
+ms.subservice: domain-services
+ms.workload: identity
+ms.topic: conceptual
+ms.date: 10/08/2019
+ms.author: iainfou
+
+---
+
+# Management concepts for user accounts, passwords, and administration in Azure Active Directory Domain Services
+
+When you create and run an Azure Active Directory Domain Services (AD DS) managed domain, there are some differences in behavior compared to a traditional on-premises AD DS environment. You use the same administrative tools in Azure AD DS as a self-managed domain, but you can't directly access the domain controllers (DC). There's also some differences in behavior for password policies and password hashes depending on the source of the user account creation.
+
+This conceptual article details how to administer an Azure AD DS managed domain and the different behavior of user accounts depending on the way they're created.
+
+## Domain management
+
+In Azure AD DS, the domain controllers (DCs) that contain all the resources like users and groups, credentials, and policies are part of the managed service. For redundancy, two DCs are created as part of an Azure AD DS managed domain. You can't sign in to these DCs to perform management tasks. Instead, you create a management VM that's joined to the Azure AD DS managed domain, then install your regular AD DS management tools. You can use the Active Directory Administrative Center or Microsoft Management Console (MMC) snap-ins like DNS or Group Policy objects, for example.
+
+## User account creation
+
+User accounts can be created in Azure AD DS in multiple ways. Most user accounts are synchronized in from Azure AD, which can also include user account synchronized from an on-premises AD DS environment. You can also manually create accounts directly in Azure AD DS. Some features, like initial password synchronization or password policy, behave differently depending on how and where user accounts are created.
+
+* The user account can be synchronized in from Azure AD. This includes cloud-only user accounts created directly in Azure AD, and hybrid user accounts synchronized from an on-premises AD DS environment using Azure AD Connect.
+    * The majority of user accounts in Azure AD DS are created through the synchronization process from Azure AD.
+* The user account can be manually created in an Azure AD DS managed domain, and doesn't exist in Azure AD.
+    * If you need to create service accounts for applications that only run in Azure AD DS, you can manually create them in the managed domain. As synchronization is one-way from Azure AD, user accounts created in Azure AD DS aren't synchronized back to Azure AD.
+
+## Password policy
+
+Azure AD DS includes a default password policy that defines settings for things like account lockout, maximum password age, and password complexity. Settings like account lockout policy apply to all users in Azure AD DS, regardless of how the user was created as outlined in the previous section. A few settings, like minimum password length and password complexity, only apply to users created directly in Azure AD DS.
+
+You can create your own custom password policies to override the default policy in Azure AD DS. These custom policies can then be applied to specific groups of users as needed.
+
+For more information on the differences in how password policies are applied depending on the source of user creation, see [Password and account lockout policies on managed domains][password-policy].
+
+## Password hashes
+
+To authenticate users on the managed domain, Azure AD DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.
+
+For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD.
+
+For users synchronized from an on-premises AD DS environment using Azure AD Connect, [enable synchronization of password hashes][hybrid-phs].
+
+> [!IMPORTANT]
+> Azure AD Connect only synchronizes legacy password hashes when you enable Azure AD DS for your Azure AD tenant. Legacy password hashes aren't used if you only use Azure AD Connect to synchronize an on-premises AD DS environment with Azure AD.
+>
+> If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM password hash synchronization for Azure AD DS. For more information, see [Disable weak cipher suites and NTLM credential hash synchronization][secure-domain].
+
+Once appropriately configured, the usable password hashes are stored in the Azure AD DS managed domain. If you delete the Azure AD DS managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Azure AD can't be reused if you later create an Azure AD DS managed domain - you must reconfigure the password hash synchronization to store the password hashes again. Previously domain-joined VMs or users won't be able to immediately authenticate - Azure AD needs to generate and store the password hashes in the new Azure AD DS managed domain. For more information, see [Password hash sync process for Azure AD DS and Azure AD Connect][azure-ad-password-sync].
+
+## Next steps
+
+To get started, [create an Azure AD DS managed domain][create-instance].
+
+<!-- INTERNAL LINKS -->
+[password-policy]: password-policy.md
+[hybrid-phs]: tutorial-configure-password-hash-sync.md#enable-synchronization-of-password-hashes
+[secure-domain]: secure-your-domain.md
+[azure-ad-password-sync]: ../active-directory/hybrid/how-to-connect-password-hash-synchronization.md#password-hash-sync-process-for-azure-ad-domain-services
+[create-instance]: tutorial-create-instance.md

articles/active-directory-domain-services/media/password-policy/create-password-policy-adac.png

@@ -10,15 +10,15 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: article
-ms.date: 08/08/2019
+ms.date: 10/08/2019
 ms.author: iainfou
 
 ---
 # Password and account lockout policies on managed domains
 
-To manage account security in Azure Active Directory Domain Services (Azure AD DS), you can define fine-grained password policies that control settings such as minimum password length, password expiration time, or password complexity. A default password policy is applied to all users in an Azure AD DS managed domain. To provide granular control and meet specific business or compliance needs, additional policies can be created and applied to specific groups of users.
+To manage user security in Azure Active Directory Domain Services (Azure AD DS), you can define fine-grained password policies that control account lockout settings or minimum password length and complexity. A default fine grained password policy is created and applied to all users in an Azure AD DS managed domain. To provide granular control and meet specific business or compliance needs, additional policies can be created and applied to specific groups of users.
 
-This article shows you how to create and configure a fine-grained password policy using the Active Directory Administrative Center.
+This article shows you how to create and configure a fine-grained password policy in Azure AD DS using the Active Directory Administrative Center.
 
 ## Before you begin
 
@@ -34,65 +34,68 @@ To complete this article, you need the following resources and privileges:
   * If needed, complete the tutorial to [create a management VM][tutorial-create-management-vm].
 * A user account that's a member of the *Azure AD DC administrators* group in your Azure AD tenant.
 
-## Fine-grained password policies (FGPP) overview
+## Default password policy settings
 
-Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. For example, to secure privileged accounts you can apply stricter password settings than regular non-privileged accounts. You can create multiple FGPPs to specify password policies within an Azure AD DS managed domain.
+Fine-grained password policies (FGPPs) let you apply specific restrictions for password and account lockout policies to different users in a domain. For example, to secure privileged accounts you can apply stricter account lockout settings than regular non-privileged accounts. You can create multiple FGPPs within an Azure AD DS managed domain and specify the order of priority to apply them to users.
 
-The following password settings can be configured using FGPP:
+Policies are distributed through group association in an Azure AD DS managed domain, and any changes you make are applied at the next user sign-in. Changing the policy doesn't unlock a user account that's already locked out.
 
-* Minimum password length
-* Password history
-* Passwords must meet complexity requirements
-* Minimum password age
-* Maximum password age
-* Account lockout policy
-  * Account lockout duration
-  * Number of failed logon attempts allowed
-  * Reset failed logon attempts count after
+Password policies behave a little differently depending on how the user account they're applied to was created. There are two ways a user account can be created in Azure AD DS:
 
-FGPP only affects users created in Azure AD DS. Cloud users and domain users synchronized into the Azure AD DS managed domain from Azure AD aren't affected by the password policies.
+* The user account can be synchronized in from Azure AD. This includes cloud-only user accounts created directly in Azure, and hybrid user accounts synchronized from an on-premises AD DS environment using Azure AD Connect.
+    * The majority of user accounts in Azure AD DS are created through the synchronization process from Azure AD.
+* The user account can be manually created in an Azure AD DS managed domain, and doesn't exist in Azure AD.
 
-Policies are distributed through group association in the Azure AD DS managed domain, and any changes you make are applied at the next user sign-in. Changing the policy doesn't unlock a user account that's already locked out.
-
-## Default fine-grained password policy settings
-
-In an Azure AD DS managed domain, the following password policies are configured by default and applied to all users:
-
-* **Minimum password length (characters):** 7
-* **Maximum password age (lifetime):** 90 days
-* **Passwords must meet complexity requirements**
-
-The following account lockout policies are then configured by default:
+All users, regardless of how they're created, have the following account lockout policies applied by the default password policy in Azure AD DS:
 
 * **Account lockout duration:** 30
 * **Number of failed logon attempts allowed:** 5
 * **Reset failed logon attempts count after:** 30 minutes
+* **Maximum password age (lifetime):** 90 days
 
 With these default settings, user accounts are locked out for 30 minutes if five invalid passwords are used within 2 minutes. Accounts are automatically unlocked after 30 minutes.
 
-You can't modify or delete the default built-in fine-grained password policy. Instead, members of the *AAD DC Administrators* group can a create custom FGPP and configure it to override (take precedence over) the default built-in FGPP, as shown in the next section.
+Account lockouts only occur within the managed domain. User accounts are only locked out in Azure AD DS, and only due to failed sign-in attempts against the managed domain. User accounts that were synchronized in from Azure AD or on-premises aren't locked out in their source directories, only in Azure AD DS.
+
+If you have an Azure AD password policy that specifies a maximum password age greater than 90 days, that password age is applied to the default policy in Azure AD DS. You can configure a custom password policy to define a different maximum password age in Azure AD DS. Take care if you have a shorter maximum password age configured in an Azure AD DS password policy than in Azure AD or an on-premises AD DS environment. In that scenario, a user's password may expire in Azure AD DS before they're prompted to change in Azure AD on an on-premises AD DS environment.
 
-## Create a custom fine-grained password policy
+For user accounts created manually in an Azure AD DS managed domain, the following additional password settings are also applied from the default policy. These settings don't apply to user accounts synchronized in from Azure AD, as a user can't update their password directly in Azure AD DS.
 
-As you build and applications in Azure, you may want to configure a custom FGPP. Some examples of the need to create a custom FGPP include to set a different account lockout policy, or to configure a default password lifetime setting for the managed domain.
+* **Minimum password length (characters):** 7
+* **Passwords must meet complexity requirements**
+
+You can't modify the account lockout or password settings in the default password policy. Instead, members of the *AAD DC Administrators* group can create custom password policies and configure it to override (take precedence over) the default built-in policy, as shown in the next section.
+
+## Create a custom password policy
+
+As you build and run applications in Azure, you may want to configure a custom password policy. For example, you could create a policy to set different account lockout policy settings.
 
-You can create a custom FGPP and apply it to specific groups in your Azure AD DS managed domain. This configuration effectively overrides the default FGPP. You can also create custom fine-grained password policies and apply them to any custom OUs you create in the Azure AD DS managed domain.
+Custom password policies are applied to groups in an Azure AD DS managed domain. This configuration effectively overrides the default policy.
 
-To create a fine-grained password policy, you use the Active Directory Administrative Tools from a domain-joined VM. The Active Directory Administrative Center lets you view, edit, and create resources in an Azure AD DS managed domain, including OUs.
+To create a custom password policy, you use the Active Directory Administrative Tools from a domain-joined VM. The Active Directory Administrative Center lets you view, edit, and create resources in an Azure AD DS managed domain, including OUs.
 
 > [!NOTE]
-> To create a fine-grained password policy in an Azure AD DS managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.
+> To create a custom password policy in an Azure AD DS managed domain, you must be signed in to a user account that's a member of the *AAD DC Administrators* group.
 
 1. From the Start screen, select **Administrative Tools**. A list of available management tools is shown that were installed in the tutorial to [create a management VM][tutorial-create-management-vm].
 1. To create and manage OUs, select **Active Directory Administrative Center** from the list of administrative tools.
 1. In the left pane, choose your Azure AD DS managed domain, such as *contoso.com*.
-1. Open the **System** container, then the **Password Settings** container.
+1. Open the **System** container, then the **Password Settings Container**.
+
+    A built-in password policy for the Azure AD DS managed domain is shown. You can't modify this built-in policy. Instead, create a custom password policy to override the default policy.
+
+    ![Create a password policy in the Active Directory Administrative Center](./media/password-policy/create-password-policy-adac.png)
 
-    A built-in FGPP for the Azure AD DS managed domain is shown. You can't modify this built-in FGPP. Instead, create a new custom FGPP to override the default FGPP.
 1. In the **Tasks** panel on the right, select **New > Password Settings**.
-1. In the **Create Password Settings** dialog, enter a name for the policy, such as *MyCustomFGPP*. Set the precedence to appropriately to override the default FGPP (which is *200*), such as *1*.
+1. In the **Create Password Settings** dialog, enter a name for the policy, such as *MyCustomFGPP*.
+1. When multiple password policies exist, the policy with the highest precedence, or priority, is applied to a user. The lower the number, the higher the priority. The default password policy has a priority of *200*.
+
+    Set the precedence for your custom password policy to override the default, such as *1*.
+
+1. Edit other password policy settings as desired. Remember the following key points:
 
-    Edit other password policy settings as desired, such as **Enforce password history** to require the user to create a password that's different from the previous *24* passwords.
+    * Settings like password complexity, age, or expiration time only to users manually created in an Azure AD DS managed domain.
+    * Account lockout settings apply to all users, but only take effect within the managed domain.
 
     ![Create a custom fine-grained password policy](./media/how-to/custom-fgpp.png)
 
@@ -101,7 +104,7 @@ To create a fine-grained password policy, you use the Active Directory Administr
 
     ![Select the users and groups to apply the password policy to](./media/how-to/fgpp-applies-to.png)
 
-1. Fine-grained password policies can only be applied to groups. In the **Locations** dialog, expand the domain name, such as *contoso.com*, then select an OU, such as **AADDC Users**. If you have a custom OU that contains a group of users you wish to apply, select that OU.
+1. Password policies can only be applied to groups. In the **Locations** dialog, expand the domain name, such as *contoso.com*, then select an OU, such as **AADDC Users**. If you have a custom OU that contains a group of users you wish to apply, select that OU.
 
     ![Select the OU that the group belongs to](./media/how-to/fgpp-container.png)
 
@@ -113,7 +116,7 @@ To create a fine-grained password policy, you use the Active Directory Administr
 
 ## Next steps
 
-For more information about fine-grained password policies and using the Active Directory Administration Center, see the following articles:
+For more information about password policies and using the Active Directory Administration Center, see the following articles:
 
 * [Learn about fine-grained password policies](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770394(v=ws.10))
 * [Configure fine-grained password policies using AD Administration Center](/windows-server/identity/ad-ds/get-started/adac/introduction-to-active-directory-administrative-center-enhancements--level-100-#fine_grained_pswd_policy_mgmt)

articles/active-directory-domain-services/password-policy.md

@@ -91,7 +91,7 @@ Azure Functions Core Tools integrates with Visual Studio Code to let you run and
 
     You can also execute the GET request from a browser.
 
-    When you call the HttpTrigger endpoint without passing a `name` parameter either as a query parameter or in the body, the function returns a 500 error. When you review the code in run.ps1, you see that this error occurs by design.
+    When you call the HttpTrigger endpoint without passing a `name` parameter either as a query parameter or in the body, the function returns a [HttpStatusCode]::BadRequest error. When you review the code in run.ps1, you see that this error occurs by design.
 
 1. To stop debugging, press Shift + F5.