This is third part of blog series of Azure AD Domain Services. If you would like to read other parts from this series those can be found from:
I have worked with on-premises Active Directory since 2003 so these AAD DS “legacy” management consoles are quite familiar for me. I have turned ADDS upside down and have been involved in quite many tricky situations, including disaster recovery cases. Because of that seeing these AD management consoles reminds me something, maybe for good old days:) Anyway, this blog post is all about managing the AAD DS.
When managing users in AAD DS you have following options from technical point of view:
- Cloud only
- Ds only
Many people has been asking is it possible to sync guest users to Azure AD Domain Services and use them when logging to servers which are joined to AAD DS. Short answer is no, it’s not possible. Microsoft explanation:
Actually, Guest users invited to Azure AD using Azure AD B2B invite process are synchronized into Azure AD Domain Services managed domain. However, passwords for these users are not stored in inviting Azure AD directory. Therefore, Azure AD Domain Services has no way to sync NTLM and Kerberos hashes for these users into Domain Services.
As seen below I can create an organization unit and account with aduc to local domain services database.
Added necessary permissions to this user (dsuser) to my member server which is joined to fetads.feta.fi directory. Both groups are for management purposes
- ds-server-2-management – this group is cloud only based
- ds-server-2-management (onprem) – this group is synced from on-premises
Logging to ds-server-2 with my dsuser account
Logged in and confirming groups memberships
When creating AAD Domain Service (Active Directory as a service) the deployment process creates two domain controllers to your environment.
I can see replication information via repadmin (below information from up-to-dateness vector table)
Replication overall status from domain controllers
Listing domain controllers. Look at the operating system version of the domain controllers. From AAD DS uservoice forum you can find several request (including use cases) for upgrading domain controllers to Windows 2016 version..
Because I have limited permissions to domain (via AAD DC Administrators group) I cannot manage replication between domain controllers for obvious reasons.
Schema report shows schema level which is 69 (W2012R2).
When digging into domain level permissions I was curios to see what permissions AAD DC Administrator group has, here is what I found:
- DnsAdmins & Group Policy Creator Owners
- Full control to computers in AAD DC Computers OU
- Read and Write all properties in AADDC Users OU
- If you are not familiar with ADACL Scanner I highly encourage to spend a short period of time with it, check more from here and here
GPO management is available which makes creating and managing GPO’s is possible.
For me digging deep into AAD DS was reminder from AD admin days and interesting learning path how to integrate applications which needs services like domain join, group policy, LDAP, Kerberos/NTLM authentication in Azure. When applications in our project has been integrated to AAD DS I will write last part of this series, lessons learned.