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/administration-concepts.md
+1-3Lines changed: 1 addition & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ ms.service: active-directory
9
9
ms.subservice: domain-services
10
10
ms.workload: identity
11
11
ms.topic: conceptual
12
-
ms.date: 01/29/2023
12
+
ms.date: 03/23/2023
13
13
ms.author: justinha
14
14
15
15
---
@@ -69,8 +69,6 @@ By default, a managed domain is created as a *user* forest. This type of forest
69
69
70
70
In an Azure AD DS *resource* forest, users authenticate over a one-way forest *trust* from their on-premises AD DS. With this approach, the user objects and password hashes aren't synchronized to Azure AD DS. The user objects and credentials only exist in the on-premises AD DS. This approach lets enterprises host resources and application platforms in Azure that depend on classic authentication such LDAPS, Kerberos, or NTLM, but any authentication issues or concerns are removed.
71
71
72
-
For more information about forest types in Azure AD DS, see [What are resource forests?][concepts-forest] and [How do forest trusts work in Azure AD DS?][concepts-trust]
73
-
74
72
## Azure AD DS SKUs
75
73
76
74
In Azure AD DS, the available performance and features are based on the SKU. You select a SKU when you create the managed domain, and you can switch SKUs as your business requirements change after the managed domain has been deployed. The following table outlines the available SKUs and the differences between them:
Copy file name to clipboardExpand all lines: articles/active-directory-domain-services/change-sku.md
+3-6Lines changed: 3 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ ms.service: active-directory
9
9
ms.subservice: domain-services
10
10
ms.workload: identity
11
11
ms.topic: how-to
12
-
ms.date: 01/29/2023
12
+
ms.date: 03/23/2023
13
13
ms.author: justinha
14
14
15
15
#Customer intent: As an identity administrator, I want to change the SKU for my Azure AD Domain Services managed domain to use different features as my business requirements change.
@@ -36,12 +36,9 @@ To complete this article, you need the following resources and privileges:
36
36
37
37
## SKU change limitations
38
38
39
-
You can change SKUs up or down after the managed domain has been deployed. However, if you use a resource forest and have created one-way outbound forest trusts from Azure AD DS to an on-premises AD DS environment, there are some limitations for the SKU change operation. The*Premium* and *Enterprise* SKUs define a limit on the number of trusts you can create. You can't change to a SKU with a lower maximum limit than you currently have configured.
39
+
You can change SKUs up or down after the managed domain has been deployed. However, the *Premium* and *Enterprise* SKUs define a limit on the number of trusts you can create. You can't change to a SKU with a lower maximum limit than you currently have configured.
40
40
41
-
For example:
42
-
43
-
* You can't change down to the *Standard* SKU. Azure AD DS resource forest doesn't support the *Standard* SKU.
44
-
* Or, if you have created seven trusts on the *Premium* SKU, you can't change down to the *Enterprise* SKU. The *Enterprise* SKU supports a maximum of five trusts.
41
+
For example, if you have created seven trusts on the *Premium* SKU, you can't change down to the *Enterprise* SKU. The *Enterprise* SKU supports a maximum of five trusts.
45
42
46
43
For more information on these limits, see [Azure AD DS SKU features and limits][concepts-sku].
Copy file name to clipboardExpand all lines: articles/active-directory-domain-services/compare-identity-solutions.md
+3-4Lines changed: 3 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ ms.service: active-directory
9
9
ms.subservice: domain-services
10
10
ms.workload: identity
11
11
ms.topic: overview
12
-
ms.date: 01/29/2023
12
+
ms.date: 04/03/2023
13
13
ms.author: justinha
14
14
15
15
#Customer intent: As an IT administrator or decision maker, I want to understand the differences between Active Directory Domain Services (AD DS), Azure AD, and Azure AD DS so I can choose the most appropriate identity solution for my organization.
@@ -27,7 +27,7 @@ Although the three Active Directory-based identity solutions share a common name
27
27
***Azure Active Directory (Azure AD)** - Cloud-based identity and mobile device management that provides user account and authentication services for resources such as Microsoft 365, the Azure portal, or SaaS applications.
28
28
* Azure AD can be synchronized with an on-premises AD DS environment to provide a single identity to users that works natively in the cloud.
29
29
* For more information about Azure AD, see [What is Azure Active Directory?][whatis-azuread]
30
-
***Azure Active Directory Domain Services (Azure AD DS)** - Provides managed domain services with a subset of fully-compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.
30
+
***Azure Active Directory Domain Services (Azure AD DS)** - Provides managed domain services with a subset of fullycompatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.
31
31
* Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS environment. This ability extends central identity use cases to traditional web applications that run in Azure as part of a lift-and-shift strategy.
32
32
* To learn more about synchronization with Azure AD and on-premises, see [How objects and credentials are synchronized in a managed domain][synchronization].
33
33
@@ -54,7 +54,6 @@ When you deploy and run a self-managed AD DS environment, you have to maintain a
54
54
Common deployment models for a self-managed AD DS environment that provides identity to applications and services in the cloud include the following:
55
55
56
56
***Standalone cloud-only AD DS** - Azure VMs are configured as domain controllers and a separate, cloud-only AD DS environment is created. This AD DS environment doesn't integrate with an on-premises AD DS environment. A different set of credentials is used to sign in and administer VMs in the cloud.
57
-
***Resource forest deployment** - Azure VMs are configured as domain controllers and an AD DS domain that's part of an existing forest is created. A trust relationship is then configured to an on-premises AD DS environment. Other Azure VMs can domain-join to this resource forest in the cloud. User authentication runs over a VPN / ExpressRoute connection to the on-premises AD DS environment.
58
57
***Extend on-premises domain to Azure** - An Azure virtual network connects to an on-premises network using a VPN / ExpressRoute connection. Azure VMs connect to this Azure virtual network, which lets them domain-join to the on-premises AD DS environment.
59
58
* An alternative is to create Azure VMs and promote them as replica domain controllers from the on-premises AD DS domain. These domain controllers replicate over a VPN / ExpressRoute connection to the on-premises AD DS environment. The on-premises AD DS domain is effectively extended into Azure.
60
59
@@ -114,7 +113,7 @@ With Azure AD DS-joined devices, applications can use the Kerberos and NTLM prot
114
113
| Great for... | End-user mobile or desktop devices | Server VMs deployed in Azure |
115
114
116
115
117
-
If on-prem AD DS and Azure AD are configured for federated authentication using ADFS then there is no (current/valid) password hash available in Azure DS. Azure AD user accounts created before fed auth was implemented might have an old password hash but this likely doesn't match a hash of their on-prem password. Hence Azure AD DS won't be able to validate the users credentials
116
+
If on-premises AD DS and Azure AD are configured for federated authentication using AD FS, then there's no (current/valid) password hash available in Azure DS. Azure AD user accounts created before fed auth was implemented might have an old password hash but this likely doesn't match a hash of their on-premises password. Hence Azure AD DS won't be able to validate the users credentials
0 commit comments