Microsoft published Azure Active Directory Domain Services as public preview mode and it provides support for applications that cannot leverage modern authentication protocols like OAuth 2.0 or SAML. With AAD Domain Services you can run DC as a service whith support of Kerberos, NTLM, Group Policy and LDAP.
“Azure AD Domain Services provides managed cloud based domain services such as domain join, group policy, LDAP & Kerberos/NTLM authentication in the Azure cloud that are fully compatible with Windows Server Active Directory. With these services, you get the full value of Windows Server AD in the cloud domain, without having to deploy, manage, monitor and patch domain controllers”.
There was workaround to create all networks etc. to US Azure datacenters
Scenario 1 – cloud only – detailed explanation of scenario can be found from link below
Scenario 2 – Hybrid organization – detailed information from link below
- Managed domains provided by Azure AD Domain Services support only a flat OU (Organizational Unit) structure. All domain-joined machines reside in a single flat OU and hierarchical OU structures are not supported.
- Azure AD Domain Services supports simple Group Policy in the form of a built-in GPO each for the users and computers containers. You cannot target GP by OU/department, perform WMI filtering or create custom GPOs.
- Azure AD Domain Services supports the base AD computer object schema. You cannot extend the computer object’s schema.
- Ensure that the application does not need to modify/write to the directory. LDAP write access to managed domains provided by Azure AD Domain Services is not supported.
- Users cannot change their password directly against the managed domain. Users can change their password either using Azure AD’s self-service password change mechanism or against the on-premises directory. These changes will automatically be synchronized and available in the managed domain.
- Ensure that the application does not require LDAPS access. LDAPS is not supported by Azure AD Domain Services.
Enable AAD Domain Services:
- Create ‘AAD DC Administrators’ group
- Group has to be named exactly as above. Users who are added to the group will be domain admins of new domain services
2. Create an Azure vNet
3. Enable AAD Domain Services
- Navigate to “Configure” tab of your tenant and select enable domain services. It will take approximately 20-30min and you would have Domain Services up and running.
- When finished you should have two ip-addresses at bottom. I got only one when creating DS at first time:) I send email to Microsoft team (aaddsfb [AT] microsoft [DOT] com) and they did their magic, thanks! After that I disabled/enabled domain services again and two DC’s were created as you can see from picture below
4. Update DNS settings for Azure vNet
- Updated ip-addresses of new DC’s to your vNet
5. Enable password sync from on-premises if you are using hybrid configuration. If you are using cloud only scenario you need to reset user passwords which can be achieved for example from Microsoft online password reset service.
HKLM\Software\Microsoft\MSOLCoExistence\PasswordSync\EnableWindowsLegacyCredentialsSync – value 1
- Link to “Force password sync” script
- I needed to reinstall AAD Connect tool before was able to trigger full password sync from on-premises to AAD. Reason for this was that I was unable to change configuration of sign-in scenario at AAD Connect (I don’t know the root cause reason)
- Latest version of AAD Connect is needed – Download AAD Connect
$adConnector = "<CASE SENSITIVE AD CONNECTOR NAME>" $azureadConnector = "<CASE SENSITIVE AZURE AD CONNECTOR NAME>" Import-Module adsync $c = Get-ADSyncConnector -Name $adConnector $p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null $p.Value = 1 $c.GlobalParameters.Remove($p.Name) $c.GlobalParameters.Add($p) $c = Add-ADSyncConnector -Connector $c Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $false Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $azureadConnector -Enable $true ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7. Join server to domain
When legacy credentials have been synced to AAD it was time join new server to Domain Services. I had already installed one W2012 R2 server to newly created Azure vNet and logged to it as local administrator
My “Domain Services” tenant name is fetanet.onmicrosoft.com and I joined the server to DS as admin who belongs to “AAD DC Administrators” group which was created at step 1 “Create ‘AAD DC Administrators’ group”
8. After server was joined to domain and rebooted I installed familiar AD DS management tools to see what I can find underneath the domain services
9. Group Policy Management console
- Default GPO’s are in place and GPO management is possible
- OU-structure is flat and it’s impossible to create new OUs. All user objects which have been synced to AAD can be found under “AADDC Users”
Domain Services is extension of AAD and it is not a replacement of Windows Server Active Directory running at on-premises. It provides support for legacy applications which can be moved to Microsoft cloud more easily. For workstations and specially for Windows there there is AAD Join and idea is not to join machines to DS even it would be possible from technical point of view. Definetely more testing is needed before implementing Domain Services to production environments but it seems very cool new feature.