Deploying and Configuring Azure Active Directory Domain Services (AADDS) to Provide Legacy Authentication Protocols in Azure

Azure AD Domain Services (AADDS) is a way to provide legacy authentication protocols to your Azure Virtual Networks, without having to build AD Domain Controllers or provide any kind of reach back to your existing AD infrastructure. AADDS is a Microsoft-managed deployment of Active Directory, where the customer/tenant is not responsible for management of the underlying compute, storage and networking surrounding the service.

Azure AD Domain Services provides a one-way synchronization from Azure Active Directory to the managed domain. In addition, only certain attributes are synchronized down to the managed domain, along with groups, group memberships, and passwords. The integration is to the AAD tenant which is already present when AADDS is created from an Azure subscription.

As this is a managed service, it is expensive and tenants/customers do forfeit a number of control factors which might make using AADDS in a production context a challenge. Many organisations do end up ruling out using AADDS due to its short comings around management. That said, many are using AADDS in production to offer authentication for services such as AVD, which still requires the Session Hosts to be joined to a traditional Active Directory. As all of the objects are pulled from the AAD tenant into AADDS, it is possible to have cloud-only objects synced to AADDS, in which none of the objects which are synced from traditional AD into AAD are then further synced from AAD to AADDS. This is configurable when the AADDS instance is being created, this is highlighted below.

Information: You can only create a single managed domain serviced by Azure AD Domain Services for a single Azure AD directory. This means that each AAD tenant can only have one AADDS domain regardless of how many customers, subscriptions etc are served from that tenant. This is a potential limitation but is impossible to overcome due to the nature of the sync relationship between AAD to AADDS.

Common use cases and patterns to consider AADDS for:

• Legacy authentication is required in a cloud-only environment, when no traditional AD DS exists.
• No cross site connectivity between on premise and Azure is available, this makes extending the existing AD DS to Azure difficult.
• Domain Services are required in an air gapped manner for services such as Remote Desktop Services (RDS) or Azure Virtual Desktop (AVD).

Information: Although AADDS might read as an extension of your existing directory services, please note that this is an entirely new AD DS domain. Therefore any application authentication integrations would have to be reconfigured to trust the new domain during a migration to Azure. Please do not forget that as this is a new domain, any AD controls such as groups, service accounts used to control in-application functionality or permissions would have to be recreated. It is possible to leverage Group Policy Objects (GPOs) in AADDS.

Azure Portal and search for Azure AD Domain Services (AADDS) and click Create.

On the Basic tab, we must select a Subscription for the AADDS instance. A DNS Primary Name is already required, this is the internal DNS namespace which is used to built and create the new AD DS. The infrastructure to support the AADDS must be hosted within an Azure region, I have selected UK South below. We have also selected the Enterprise SKU.

The Networking tab for AADDS is important as the AADDS service must be joined to a virtual network to ensure applications and services can use the legacy domain. In this example we create a new virtual network and subnet, please note the AADDS service will be created into a new subnet. Nothing else should be deployed into this subnet as it must be exclusively for AADDS. The AADDS will have private addresses within this subnet which are used in the DNS Server configuration to ensure servers and clients can discover the AADDS service/domain.

The Administration tab outlines what existing users and groups within the AAD are granted privileged access to the AADDS managed domain. Please note you are not granted Domain Administrator or Enterprise Administrator rights in the managed domain. You also cannot extend the schema of the Active Directory, therefore limiting the usage of custom attributes for complex application scenarios. Management of the AADDS domain is done with the users who are populated within the AAD DC Administrators group. This group starts out life in the AAD as an assigned group. You then add members to this AAD group which are then granted management permissions within the new AADDS domain.

You will notice below the check box for "All Global Administrators of the Azure AD Directory" is selected. This ensures that all Global Admins within the tenant are also given management permissions within the domain, over and above the AAD DC Administrators. 

We now configure what objects we would like to sync into the new directory. By default you can configure full sync. This is where objects which originated from on premise AD but have been synced to AAD would then be pushed into the AADDS. The architecture looks something like this, where the on prem AD syncs to AAD via AD Connect, then AADDS syncs from AAD into the managed domain. There would never be a direct link between AADDS and on prem AD.

You can of course select, Cloud-only where only objects which have originated in the AAD tenant are then synced to the AADDS instance, leaving behind anything in AAD which originated from on prem AD.

It is possible to fine tune the security settings for parameters such as TLS, NTLM, Kerberos etc. It is probably only advisable to do this if you have a compelling reason to. 

The creation of an AADDS domain takes around 45 minutes so be patient and once the service has completed deploying you will be able to integrate the infrastructure behind the service. You will notice no Virtual Machines are available as part of AADDS, these are entirely abstracted from the customer.

To ensure your new managed domain is reachable you must find which IP addresses have been assigned to the AADDS Domain Controllers underneath the platform. Go to Properties from the AADDS resource object and you will find the addresses there. These are private addresses and we will configure our virtual network to use these addresses as the DNS to ensure the domain can be resolved. 

To do this, open up a virtual network and go to DNS Servers, then click on Custom. From here enter the addresses of the AADDS service and commit the change. This will ensure all infrastructure provisioned on this network will automatically be given these DNS addresses which will ensure the new AADDS domain can be resolved. If this is in place you should be able to join a new machine to your new domain. 

To manage the domain you should use something like the RSAT tools from a management workstation with the correct credentials. From here you will be able to open the domain tree, Group Policy etc.

Customise the AD Connect sync scheduler time window

By default AD Connect automatically syncs to Azure AD every 30 minutes. Although this works fine in most companies, it could be considered too long a period if there is a high rate of change within an organisation. 

To alter the default sync period use Powershell

Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:05:00 

The above command sets the sync period to 5 mins. It's important that you do not set the sync period too low, so that sync jobs don't begin to clash. A delta sync should not take a full 5 minutes unless the AD of a large enterprise scale.

Update all user "targetAddress" and "proxyAddress" attributes in AD using Powershell for Exchange Hybrid

AD attributes are important when you have a hybrid setup from your on premise Exchange to Office 365, the following script will help retrospectively publish the required objects to your domain users so that hybrid mail flow works correctly.

Review this article for details on AD attributes in Exchange with hybrid connectivity.

http://blog.ryanbetts.co.uk/2018/09/understanding-ad-attributes-in-exchange.html

The following command can be used to export a list of users to a CSV file, you should change the OU path to suit your own environment. Once you have a list of users copy and paste them into a blank text document.

Get-ADUser -SearchBase "OU=Standard Users,OU=User Accounts,OU=Grand Cayman,OU=Company X,DC=domain,DC=com" -prop * -Filter * | Select samaccountname | Export-CSV C:\Users\Administrator\Desktop\Users.csv

The following command will set the "targetAddress" attribute for every user listed in the text file.

The "targetAddress" is used when on premise mailboxes try to send mail to Office 365 mailboxes.

Remember to capatilise SMTP as this will ensure it's the primary email adress. 

Get-Content C:\Users\da.ryan.betts\Desktop\O365Users.txt | % { Set-AdUser $_ -add @{targetAddress="SMTP:$_@companyx.mail.onmicrosoft.com"}}

The following command will append the FQDN, your public domain should be set as the primary so ensure caps are used with SMTP.

Get-Content C:\Users\Administrator\Desktop\O365Users.txt | % { Set-AdUser $_ -add @{proxyAddresses="SMTP:$_@companyx.com"}}

A second pass of the same command will add the additional proxy address which should be tenantname.mail.onmicrosoft.com

Get-Content C:\Users\Administrator\Desktop\O365Users.txt | % { Set-AdUser $_ -add @{proxyAddresses="smtp:$_@companyx.mail.onmicrosoft.com"}}

When you sync the AD to AAD using AD Connect the x500 entry will also appear under proxyAddresses. 

Solarwinds Active Directory Import Tools

Solarwinds offer a completely free tool to create batches of AD user accounts.

https://www.solarwinds.com/free-tools/active-directory-admin-tools-bundle

It works using CSV files to import users and match attributes. The following spreadsheet is a template for this which has been used by Solarwinds.

https://www.dropbox.com/s/o2zlgtjwlw4ws08/Blank-CSV.csv?dl=0

Enabling Azure AD Self Service Password Reset/Writeback, and what happens when users exist in Office 365 before Active Directory is synced using AD Connect

I had to test a few scenario's as I was taking over a project centred around Office 365, the only twist was that user accounts had been provisioned in Office 365 before the production Active Directory was in place (and AD Connect).

I had to test what would happen when the following

• User A existed in Office 365 but was then created in AD (with the same email address) and synced.

The outcome of this test is that User A is still retained in Office 365 with all the existing permissions and testing however their original Office 365 password is overwritten with the new password which is set on their user account in Active Directory. In short the on premise Active Directory becomes the point of authority for passwords which in turn overwrite any existing passwords in Office 365.

The next part I had to test was Azure AD Password Write back, this feature is useful for me on this project as users who were already using Office 365 would have to be provisioned with AD accounts. The plan was to create new user accounts (matches Office 365 email) for everyone with a generic password, when AD Connect was in place, they would then be asked to login to Office 365 using their new generic password. When they had authenticated to Office 365 they would be instructed to reset the generic password to be their own password. After the new password was accepted by Azure AD, it would in turn then we written back to AD, thus becoming the primary and only password for AD and Azure AD.

It should be noted that Azure AD Premium is need to support Azure AD Password Write back.

If you are doing this for the first time it's not obvious that you have to change the Default Domain Policy on the Active Directory to set the Minimum Password Age to 0, or you will get the following error.

The Default Domain Policy usually holds the global account policies for the Active Directory.

You must enable Self Service Password Reset from the Azure AD portal. 

You must also ensure password write-back is enabled from the same portal. 

The workflow for when users login after write-back has been enabled.

a.) User is issued new password (for Active Directory)

b.) Administrator forces AD Connect do a sync to Azure AD

c.) User is asked to login to Office 365

d.) User is asked to register self-service password reset questions

e.) User is logged in with Active Directory password

f.) User attempt's to reset Active Directory password from Office 365 portal

g.) Office 365 accepts the users new password and writes it back to Active Directory

h.) This password becomes the only password for Active Directory and Azure AD

i.) Event 31007 is logged in the Azure AD Connect server to confirm the write back operation.

In this example my domain was running on Windows Server 2008 R2, no permission changes had to be made to get password write-back working. I did however do exactly the same thing on a production environment all running Windows Server 2016 Domain Controllers, and it never worked, you can find the solution here.

Force removal of synced Azure AD accounts when synced domain is no longer available

If you have Azure AD Connect syncing users from on premise Active Directory you will be unable to delete user accounts from the Office portal. This is the expected behaviour as the point of authority is Active Directory, when AD Connect is in place. 

You will be faced with the following error if you try "Couldn't delete this user because the account is synchronised with your on-premises servers. You can delete the user from your on-premises server." this is fine to resolve if your domain is up and operational, you simply delete the account from AD and force a sync with AD Connect. 

In this scenario this was my lab and the Active Directory that was destroyed ages ago when an SSD failed in my lab server. 

It is possible to break the relationship to Active Directory if AD Connect is offline and the domain is unrecoverable. It starts by connecting to Office 365 using Powershell.

You can download the Azure AD Powershell module using the following command

 Install-Module -Name AzureRM -AllowClobber 

You can then connect to Office 365 using the following command

 Connect-MsolService  

When you are connected to your tenant issue the following command to disable directory sync

Set-MsolDirSyncEnabled -EnableDirSync $false 

Once this command has run, it takes a while to propagate through Azure AD.

Once it was done you should be able to manually delete objects from the Office portal.

You need to enable directory sync again if you plan to provision a new domain and install AD Connect.

Set-MsolDirSyncEnabled -EnableDirSync $true 

I managed to delete all the orphaned user accounts with the exception of one, the AD sync account. It failed with "We couldn't delete this account: Sync_rbVM. This is your directory synchronisation account and you'll have synchronisation failures if it's deleted."

After leaving the portal for a bit and trying again I managed to remove this account. 

Configuring Extranet Lock Protection in ADFS 2016

Extranet Lock Protection is used to protect your Internet facing ADFS from password brute force attacks. Extranet Lock Protection works much like an Account Lockout Policy in Active Directory, you set a password attempt threshold in conjunction with a period of time before the user in question can be authenticated. With ELP enabled, even if the user attempts to login to the Sign In page using valid credentials after the threshold has been met and before the lock time has expired, they will not be granted access.

ADFS ELP works separately from Active Directory account lock outs, if you enable ELP it will not disable on premise user accounts if a brute force attack has been attempted at the ADFS Sign In page.

Some comparisons should be made between the AD Account Lockout Policy and ELP.

·      Lockout threshold on ELP should be less than the threshold in AD.

·      Lockout time window on ELP should be greater than the threshold in AD.

Extranet Lock Protection is not enabled by default on Server 2012 R2 or Server 2016.

View the default using Get-AdfsProperties

Enable Extranet Lockout Protection with a threshold of 3 wrong authentication attempts and a lockout observation window of 15 minutes.

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 3 -ExtranetObservationWindow (new-timespan -Minutes 15)

Run the command Get-AdfsProperties again to ensure the change has been applied.

It’s worth noting that it takes some time for the warning to disappear from the Azure AD Connect page inside the Azure Portal. It does not seem to be instant and nothing I did seemed to force a re-evaluation.

Further reading https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-lockout-protection