aadconnect

Using a gMSA account with AADConnect

Leave a comment

If you haven’t heard of a gMSA, you haven’t lived. That’s what my Mum tells me anyway.

A gMSA is also known as a Group Managed Service Account, and it really is the future of Service Accounts. It doesn’t allow interactive logons, it recycles it’s credentials automatically and can also be tied down so it can only be used on specific hosts. Most importantly it is recommended if you use Azure AD Connect with a dedicated SQL Server.

It does require Server 2012 or above on your domain controllers (for the schema extensions) and an Azure AD Connect server, but if you aren’t using this OS or newer yet, then I think you have other priorities you need to address 🙂

So the big question is; how do we use this magical feature? The guide below is for a new installation of AADConnect.

Firstly, if you haven’t done so already you need to enable the KDS Root Key 🔐 required for generating the passwords used by the service account. Run this PS Command from an AD Powershell prompt to enable the KDS Root Key 🔐. This can be done from a Domain Controller or from a server running RSAT ADDS tools.

Add-KdsRootKey –EffectiveImmediately

Funnily enough, even though we used -EffectiveImmediately, it is only available instantly on the DC you ran the command from. The other DC’s need to wait for replication to complete for the key to be available.

You then need to create the AAD Connect gMSA service account. Use this PS command to do this:

New-ADServiceAccount -Name AADC-gMSA -Description "AAD Connect Service Account" -DNSHostName aadc.Contoso.com -PrincipalsAllowedToRetrieveManagedPassword MGMT01$,MGMT01$ -Passthru

Replace the sections in red with your own information. MGMT01 and MGMT02 are the names of our primary and staging AAD Connect servers in this instance, and the DNSHostName parameter essentially sets a DNS name of the service we are running.

Once this is done, you need to head over to your AAD Connect server and add the account using:

Install-ADServiceAccount AADC-gMSA

Lastly, during AADConnect installation, we need to select the service account. During initial installation, choose the ‘Customise’ option as shown below:

Screenshot 2019-05-21 at 16.55.44

And then select ‘Use an existing service account’ and enter the service account name using the domain\accountname$ format.

Screenshot 2019-05-21 at 16.57.43

This process will help you automate and secure your service accounts in the future, and is a great choice whenever a service account is required and gMSA is supported.

 

 

AADSync / AADConnect default Domain Controller

Leave a comment

I came across an odd situation recently whereby my AADConnect installation had decided to communicate with a Domain Controller which was in another site, across an Active Directory replication link with a 180 minute replication interval. This was no good for my customer as they made their AD changes on the site local to AADConnect, so I decided to remedy this by forcing AADConnect to communicate with a particular DC. This can be useful for many reasons, and you can actually set a list of ‘preferred Domain Controllers’ to allow for fault tolerance.

To do this, go into the Synchronisation Service, head on over to the Connectors tab and find your Active Directory Domain Services Connector. The below example is synchronising multiple AD Forests. Once you’ve selected your domain, you can see which Domain Controller is currently in use by checking the ‘Connection Status’ area (shown in the central area of the below screenshot).

Synchronisation Service

To change the Domain Controller in use, go to the Properties tab for your domain (on the right hand ‘Actions’ pane). Go into the ‘Configure Directory Partitions’ tab and you will see a handy tick box entitled ‘Only use preferred domain controllers’.

AADConnect - Directory Partitions

Place a checkmark in this box, and a window will appear, allowing you to enter your shortlist of Domain Controllers.

AADConnect - Preferred DCs

Once you’ve entered your preferred DCs, OK your way out of these windows and hey presto, you are done! It’s a nice and easy task to perform, but not one I’ve seen documented online before.

Thanks for reading!

Azure Active Directory Sync – AAD Connect Disaster Recovery and High Availability

Leave a comment

I just wanted to write and tell you all about a fantastic new feature built into the AAD Connect tool. It’s name is ‘Staging Mode’ and it has a dual purpose; a) it allows you to have a server which is essentially on standby, and b) it can be used just as it’s name suggests, in a kind of test mode where you can see what is being imported before it all gets sent off to Azure AD.

In real life it would be utilised thus:

Customer A has a functional installation of AAD Sync / AAD Connect which is synchronising objects and attributes between Azure Active Directory and the On Premise Active Directory. They then build an AAD Connect server in their DR datacentre (or wherever they fancy), and during the initial configuration, enable ‘Staging Mode’. Apart from this setting, they configure it just like their existing, live AAD Sync / AAD Connect server. They even leave the scheduled task enabled and running. All of a sudden, DR strikes, and the live AAD Sync / AAD Connect server goes offline forevermore, cast into the computer graveyard in the sky. Rather than restore the server from backup, they simply log into their second AAD Connect server and disable ‘Staging Mode’. This server then starts synchronising with Azure Active Directory in earnest, without having to miss a beat.

What Staging Mode does is very simple. It acts just like a functional AAD Connect installation, except for the fact that it exports nothing to Azure Active Directory or your on premise Active Directory. It also does not perform any password sync or password write-back functions. The metaverse is fully populated and ready to start exporting data, giving you the easiest possible way to have a server on standby. Unfortunately there is no replication between your two synchronisation servers, so any configuration changes need to be replicated manually, but this is another step to making AAD Connect fully HA, which is becoming much more desirable as Azure Active Directory gains traction.

AADConnect Staging Mode