You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory-domain-services/active-directory-ds-synchronization.md
+15-6Lines changed: 15 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,41 +14,41 @@ ms.workload: identity
14
14
ms.tgt_pltfrm: na
15
15
ms.devlang: na
16
16
ms.topic: article
17
-
ms.date: 03/06/2017
17
+
ms.date: 05/30/2018
18
18
ms.author: maheshu
19
19
20
20
---
21
21
# Synchronization in an Azure AD Domain Services managed domain
22
22
The following diagram illustrates how synchronization works in Azure AD Domain Services managed domains.
23
23
24
-

24
+

25
25
26
26
## Synchronization from your on-premises directory to your Azure AD tenant
27
27
Azure AD Connect sync is used to synchronize user accounts, group memberships, and credential hashes to your Azure AD tenant. Attributes of user accounts such as the UPN and on-premises SID (security identifier) are synchronized. If you use Azure AD Domain Services, legacy credential hashes required for NTLM and Kerberos authentication are also synchronized to your Azure AD tenant.
28
28
29
-
If you configure write-back, changes occurring in your Azure AD directory are synchronized back to your on-premises Active Directory. For example, if you change your password using Azure AD's self-service password change features, the changed password is updated in your on-premises AD domain.
29
+
If you configure write-back, changes occurring in your Azure AD directory are synchronized back to your on-premises Active Directory. For example, if you change your password using Azure AD self-service password management, the changed password is updated in your on-premises AD domain.
30
30
31
31
> [!NOTE]
32
32
> Always use the latest version of Azure AD Connect to ensure you have fixes for all known bugs.
33
33
>
34
34
>
35
35
36
36
## Synchronization from your Azure AD tenant to your managed domain
37
-
User accounts, group memberships, and credential hashes are synchronized from your Azure AD tenant to your Azure AD Domain Services managed domain. This synchronization process is automatic. You do not need to configure, monitor, or manage this synchronization process. After the one-time initial synchronization of your directory is complete, it typically takes about 20 minutes for changes made in Azure AD to be reflected in your managed domain. This synchronization interval applies to password changes or changes to attributes made in Azure AD.
37
+
User accounts, group memberships, and credential hashes are synchronized from your Azure AD tenant to your Azure AD Domain Services managed domain. This synchronization process is automatic. You do not need to configure, monitor, or manage this synchronization process. Initial synchronization may take from a few hours to a couple of days depending on the number of objects in your Azure AD directory. After initial synchronization completes, it takes about 20-30 minutes for changes that are made in Azure AD to be updated in your managed domain. This synchronization interval applies to password changes or changes to attributes made in Azure AD.
38
38
39
39
The synchronization process is also one-way/unidirectional in nature. Your managed domain is largely read-only except for any custom OUs you create. Therefore, you cannot make changes to user attributes, user passwords, or group memberships within the managed domain. As a result, there is no reverse synchronization of changes from your managed domain back to your Azure AD tenant.
40
40
41
41
## Synchronization from a multi-forest on-premises environment
42
42
Many organizations have a fairly complex on-premises identity infrastructure consisting of multiple account forests. Azure AD Connect supports synchronizing users, groups, and credential hashes from multi-forest environments to your Azure AD tenant.
43
43
44
-
In contrast, your Azure AD tenant is a much simpler and flat namespace. To enable users to reliably access applications secured by Azure AD, resolve UPN conflicts across user accounts in different forests. Your Azure AD Domain Services managed domain bears close resemblance to your Azure AD tenant. Therefore, you see a flat OU structure in your managed domain. All users and groups are stored within the 'AADDC Users' container, regardless of the on-premises domain or forest from which they were synced in. You may have configured a hierarchical OU structure on-premises. However, your managed domain still has a simple flat OU structure.
44
+
In contrast, your Azure AD tenant is a much simpler and flat namespace. To enable users to reliably access applications secured by Azure AD, resolve UPN conflicts across user accounts in different forests. Your Azure AD Domain Services managed domain bears close resemblance to your Azure AD tenant. You see a flat OU structure in your managed domain. All user accounts and groups are stored within the 'AADDC Users' container, despite being synchronized from different on-premises domains or forests. You may have configured a hierarchical OU structure on-premises. Your managed domain still has a simple flat OU structure.
45
45
46
46
## Exclusions - what isn't synchronized to your managed domain
47
47
The following objects or attributes are not synchronized to your Azure AD tenant or to your managed domain:
48
48
49
49
***Excluded attributes:** You may choose to exclude certain attributes from synchronizing to your Azure AD tenant from your on-premises domain using Azure AD Connect. These excluded attributes are not available in your managed domain.
50
50
***Group Policies:** Group Policies configured in your on-premises domain are not synchronized to your managed domain.
51
-
***SYSVOL share:** Similarly, the contents of the SYSVOL share on your on-premises domain are not synchronized to your managed domain.
51
+
***Sysvol share:** Similarly, the contents of the Sysvol share on your on-premises domain are not synchronized to your managed domain.
52
52
***Computer objects:** Computer objects for computers joined to your on-premises domain are not synchronized to your managed domain. These computers do not have a trust relationship with your managed domain and belong to your on-premises domain only. In your managed domain, you find computer objects only for computers you have explicitly domain-joined to the managed domain.
53
53
***SidHistory attributes for users and groups:** The primary user and primary group SIDs from your on-premises domain are synchronized to your managed domain. However, existing SidHistory attributes for users and groups are not synchronized from your on-premises domain to your managed domain.
54
54
***Organization Units (OU) structures:** Organizational Units defined in your on-premises domain do not synchronize to your managed domain. There are two built-in OUs in your managed domain. By default, your managed domain has a flat OU structure. You may however choose to [create a custom OU in your managed domain](active-directory-ds-admin-guide-create-ou.md).
@@ -111,6 +111,15 @@ The following table illustrates how specific attributes for group objects in you
111
111
| onPremiseSecurityIdentifier |sidHistory |
112
112
| securityEnabled |groupType |
113
113
114
+
## Password hash synchronization and security considerations
115
+
When you enable Azure AD Domain Services, your Azure AD directory generates and stores password hashes in NTLM & Kerberos compatible formats.
116
+
117
+
For existing cloud user accounts, since Azure AD never stores their clear-text passwords, these hashes cannot be automatically generated. Therefore, Microsoft requires [cloud-users to reset/change their passwords](active-directory-ds-getting-started-password-sync.md) in order for their password hashes to be generated and stored in Azure AD. For any cloud user account created in Azure AD after enabling Azure AD Domain Services, the password hashes are generated and stored in the NTLM and Kerberos compatible formats.
118
+
119
+
For user accounts synced from on-premises AD using Azure AD Connect Sync, you need to [configure Azure AD Connect to synchronize password hashes in the NTLM and Kerberos compatible formats](active-directory-ds-getting-started-password-sync-synced-tenant.md).
120
+
121
+
The NTLM and Kerberos compatible password hashes are always stored in an encrypted manner in Azure AD. These hashes are encrypted such that only Azure AD Domain Services has access to the decryption keys. No other service or component in Azure AD has access to the decryption keys. The encryption keys are unique per-Azure AD tenant. Azure AD Domain Services synchronizes the password hashes into the domain controllers for your managed domain. These password hashes are stored and secured on these domain controllers similar to how passwords are stored and secured on Windows Server AD domain controllers. The disks for these managed domain controllers are encrypted at rest.
122
+
114
123
## Objects that are not synchronized to your Azure AD tenant from your managed domain
115
124
As described in a preceding section of this article, there is no synchronization from your managed domain back to your Azure AD tenant. You may choose to [create a custom Organizational Unit (OU)](active-directory-ds-admin-guide-create-ou.md) in your managed domain. Further, you can create other OUs, users, groups, or service accounts within these custom OUs. None of the objects created within custom OUs are synchronized back to your Azure AD tenant. These objects are available for use only within your managed domain. Therefore, these objects are not visible using Azure AD PowerShell cmdlets, Azure AD Graph API or using the Azure AD management UI.
Copy file name to clipboardExpand all lines: articles/active-directory/managed-service-identity/how-to-manage-ua-identity-arm.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,8 +49,7 @@ As with the Azure portal and scripting, Azure Resource Manager templates provide
49
49
50
50
To create a user assigned identity, use the following template. Replace the `<USER ASSIGNED IDENTITY NAME>` value with your own values:
51
51
52
-
> [!IMPORTANT]
53
-
> Creating user assigned identities only supports alphanumeric and hyphen (0-9 or a-z or A-Z or -) characters. Additionally, name should be limited to 24 character length for the assignment to VM/VMSS to work properly. Check back for updates. For more information, see [FAQs and known issues](known-issues.md)
Copy file name to clipboardExpand all lines: articles/active-directory/managed-service-identity/how-to-manage-ua-identity-powershell.md
+1-2Lines changed: 1 addition & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,8 +36,7 @@ In this article, you learn how to create, list and delete a user assigned identi
36
36
37
37
To create a user assigned identity, use the [New-AzureRmUserAssignedIdentity](/powershell/module/azurerm.managedserviceidentity/new-azurermuserassignedidentity) command. The `ResourceGroupName` parameter specifies the resource group where to create the user assigned identity, and the `-Name` parameter specifies its name. Replace the `<RESOURCE GROUP>` and `<USER ASSIGNED IDENTITY NAME>` parameter values with your own values:
38
38
39
-
> [!IMPORTANT]
40
-
> Creating user assigned identities only supports alphanumeric and hyphen (0-9 or a-z or A-Z or -) characters. Additionally, name should be limited to 24 character length for the assignment to VM/VMSS to work properly. Check back for updates. For more information, see [FAQs and known issues](known-issues.md)
Copy file name to clipboardExpand all lines: articles/active-directory/managed-service-identity/msi-tutorial-linux-vm-access-arm.md
+20-20Lines changed: 20 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -69,29 +69,29 @@ For this tutorial, you first create a new Linux VM. You can also opt to use an e
69
69
70
70
2. Create a user-assigned identity using [az identity create](/cli/azure/identity#az_identity_create). The `-g` parameter specifies the resource group where the MSI is created, and the `-n` parameter specifies its name. Be sure to replace the `<RESOURCE GROUP>` and `<MSI NAME>` parameter values with your own values:
71
71
72
-
> [!IMPORTANT]
73
-
> Creating user assigned identities only supports alphanumeric and hyphen (0-9 or a-z or A-Z or -) characters. Additionally, name should be limited to 24 character length for the assignment to VM/VMSS to work properly. Check back for updates. For more information see [FAQs and known issues](known-issues.md)
az identity create -g <RESOURCE GROUP> -n <MSI NAME>
77
-
```
78
74
79
-
The response contains details for the user assigned identity created, similar to the following example. Note the `id` value for your user assigned identity, as it will be used in the next step:
75
+
```azurecli-interactive
76
+
az identity create -g <RESOURCE GROUP> -n <MSI NAME>
The response contains details for the user assigned identity created, similar to the following example. Note the `id` value for your user assigned identity, as it will be used in the next step:
0 commit comments