Using Azure AD Connect is something many of us do and will continue to do for some time. Microsoft is updating Azure AD Connect on a regular basis and it is important to stay current.
The retirement of TLS 1.1, TLS 1.0 and 3DES cipher suite is an upcoming change that is important to keep track of and I recommend to take action as soon as possible.
This means that we should enable TLS 1.2 as soon as possible which comes with some pre-requisites.
You might have noticed this notification in the Azure Portal
Enable support for TLS 1.2 in your environment for upcoming Azure AD TLS 1.0/1.1 deprecation – Active Directory | Microsoft Docs
About Group Managed Service Accounts
So, changing the password for a service account is rarely an easy task as it might break stuff and require manual updates in each system using the service account.
This is where Group Managed Service Accounts come in handy as the password management is handled by the domain controllers directly on a regular basis, without the need of manual work. After a password change, servers on an allow-list are allowed to get the new password and no manual work or system down time is needed.
It all works automagically! ⭐
Azure AD Connect: Accounts and permissions | Microsoft Docs
I strongly recommend that Server 2016 or above is used as the Azure AD Connect server. Also, I advise not to install Azure AD Connect on a domain controller as we want to keep those as clean as possible.
Make sure your environment is ready for TLS 1.2: https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/enable-support-tls-environment
Good to know
I thought it might be a good idea to look at where the KDS Root Keys and Group Managed Service Accounts are stored in AD and look at what the ADDS Connector Account and ADSync Service Account do.
KDS Root Key is stored in Active Directory Sites and Services
Logon to a domain controller or a device with RSAT AD Tools
- Open for DSSITE.msc
- Click View
- Make sure Show Services Node is checked
- Expand Group Key Distribution Service
- Click Master Root Keys
- Any existing root keys are stored in this container. After successfully running the script, this is where the root key will end up
- Good to know: this is where we would manually delete an existing root key, should we want to
Group Managed Service Accounts are stored in Active Directory Users and Computers
- Logon to a domain controller or device with RSAT AD Tools
- Expand the root domain
- Click Managed Service Accounts
- Any existing Managed Service Accounts are stored in this container. After successfully running the script, this is where the gMSA will end up
* The ADDS Connector Account is used to read and write to on-prem Active Directory
* In our case we will set up a Group Managed Service Account as the ADSync Service Account
Azure AD Connect Lab Environment
I am going to demo the script in my lab environment with below setup:
- Some print screens include sensitive info, this is for demo purpose only and all info will be wiped ⭐⭐⭐
- A single domain controller
- Azure AD Connect will be installed on Windows Server 2019 (not the domain controller)
- Database will be located on local server
Let’s have a look at what we can expect from running the script. The main idea of this script is to make the preparation and installation of Azure AD Connect a breeze.
To manually delegate permissions to the ADDS Connector Account is a pain and could end up with too much privileges being added.
We will make sure all pre-requisites are fulfilled, accounts created, permissions delegated and then install AAD Connect.
We will future proof our AAD Connect installation by enabling TLS 1.2 and use a Group Managed Service Account instead of a default Service Account.
No actual configuration to AAD Connect will be handled by the script.
❗ Note that an existing Azure AD Connect installation must be uninstalled before running the script as adding a Group Managed Service Account (gMSA) requires that.
In more detail the script will:
- Enable TLS 1.2
- Enable RSAT AD Tools
- Create an ADDS Connector Account with a strong password
- Install Azure AD Connect
- Delegate permissions to the ADDS Connector account (least privileges)
- Create a KDS Root Key
- Create and install a Group Managed Service Account (gMSA)
- Download the script “Install-AAD-Connect.ps1” from my GitHub NicklasAhlberg/Azure-AD (github.com)
- Download Azure AD Connect Download Microsoft Azure Active Directory Connect from Official Microsoft Download Center
Now that we have downloaded the script, checked the pre-reqs and know the expectations, we are ready to run the script.
The following will take us through the steps on how to run the script, show us what to expect and the experience from running it.
Let’s rock enroll!
- Sign-in as a local admin to the Azure AD Connect server.
- If Azure AD Connect is already installed, export current config and uninstall Azure AD Connect
- Run PowerShell (as an administrator)
- Run the script by dot sourcing the path
- If not already so, TLS 1.2 will be enabled and we are asked to restart the server.
- Press Y to restart the server now
- With the server back up, run the script again (see step 3) 😉
- The script will not continue if Azure AD Connect is currently installed. Export current config and uninstall Azure AD Connect
- RSAT will be enabled
- Now it is time to create the ADDS Connector Account. We are asked to either create a new account or use an existing
- Press Y to use an existing account or N to create a new. In this demo we will create a new account
- When the ADDS Connector Account has been successfully created it is time to install Azure AD Connect
- We are asked to download Azure AD Connect and press Enter (see the downloads section above if you have not already downloaded AAD Connect)
- Press Enter and select the Azure AD Connect installation MSI
- Azure AD Connect will now be installed. Note that this is just the installation and not the actual configuration.
Feel free to close the Azure AD Connect window that will appear in the background
- Now it is time to delegate permissions to the ADDS Connector Account. We will be asked to approve or reject each specific permission, this gives us full control of what permissions (see list below) are actually being delegated.
Note that no permissions will be delegated on the AdminSDHolder container
- Press Enter to start the delegation
- Press Y to approve or N to reject each permission
- The script will now check the AD for existing KDS Root Keys. A new key will be created if none exist.
- We are now asked if our domain is running on multiple or on a single domain controller.
*** Multiple = Create the KDS Root Key with an effective time 10h in the future. The reason for having the effective time set to a future time is to make sure the key has time to replicate between all domain controllers.
*** Single = Create the KDS Root Key with an effective date 10h in the past. Use this only in lab/test or single DC environment! This will make the key accessible to us right away.
We could automate this step but there might be cases where you would like to choose single even though you are running on multiple DC’s (for example to get the KDS Root Key out there ASAP in a lab environment).
Optional reading: Create the Key Distribution Services KDS Root Key | Microsoft Docs
- Press Y if your domain run on multiple domain controller’s and N if it run on a single.
In this demo we will choose N
- The KDS Root Key is created and the script will wait for 30 seconds before continuing
- It is now time to create the Group Managed Service Account (gMSA). This is the account running the Azure AD Connect service and the one connecting to the database
- Provide a name
- The gMSA will be created and installed on the Azure AD Connect server
Yaay, good job. We have now successfully installed the latest version of Azure AD Connect, future proofed it by enabling TLS 1.2 and during configuration we need to make sure to run the Azure AD Connect service in a modern and more secure way by utilizing gMSA! 😍
Now all you need to do is configure Azure AD Connect, remember to use the ADDS Connector account and the gMSA we just created.
I am getting this error when creating the GMSA
Key does not exist.Exception.Message
I have mutiple domain controllers and have waited the required 10H before proceeding with the script. See Below.
Confirm that you waited 10h (if running multiple domain controllers) [Y/N]: Y
An existing KDS Root Key was found. We are ready to create the Group Managed Service Account
The Group Managed Service Account is used to run the Azure AD Connect service and connect to an external database
Any thoughts as to what the issue may be?
Hi Jared, thanks for reaching out.
You could check for the GMSA manually by running this in PowerShell: Get-KdsRootKey
Do you get a hit by running above command?