Since version 1.1.443.0, you can use Azure AD Connect with a group Managed Service Account (gMSA) as its service account. I thought it was time to show you how to configure Azure AD Connect with a gMSA.

The problem with service accounts

We all use service accounts in our environments. These accounts allow us to run a service with the right amount of privileges. It also allows us to change the passwords for normal accounts, like built-in Administrator accounts since these are not abused to run services.

However, there is also a downside to service accounts, when you repurpose an Active Directory user object as a service account. Problems with this type of service accounts include:

• Service account password changes are a nightmare and they tend to break stuff. Nonetheless, it is a best practice to change these passwords regularly.
• Passwords for service accounts are stored in plain text in registry. Sure, the passwords are protected, but still accessible if you know how to work the DPAPI.
• The Scope of service accounts is not easily set or monitored. Service accounts can often be used outside the intended scope, for instance to set up VPN connections or send mail through the (authenticated) SMTP gateway.
• You can configure service accounts to not allow interactive logons and implement other information security measures, but in true Plan-Do-Check-Act fashion, you’ll also need to create reports of these settings still applying throughout the environment.

It’s a pain.

The problem with vSAs

Version 1.1.484.0, and above, of Azure AD Connect use a virtual Service Account (vSA), by default, instead of a service account, based on a user object in Active Directory Domain Services (AD DS), unless you install Azure AD Connect on a Domain Controller. While documentation is sparse on this feature, its aim is to automate regular password changes.

To this purpose, a virtual Service Account (vSA) is a local account to the Windows (Server) installation. It does not live in Active Directory Domain Services, but can best be seen as a subordinate to the Network Service on Windows 7 installations (and up) and Windows Server 2008 R2 installations (and up).

Problems with this type of service account include:

• The scope of the virtual Service Account is limited to one Windows (Server) installation.
• The name of the virtual Service Account needs to be identical to the name of the service. If your organization utilizes a strict naming convention, the virtual Service Account will not comply.
• The virtual Service Account is part of the Windows (Server) installation and does not live in Active Directory Domain Services. When your organization requires you to centrally manage service accounts in Active Directory, the virtual Service Account will not comply.
• The virtual Service Account inherits the same security context as the Network Service.

The benefit of using a virtual Service Account (vSA) instead of a  service account based on a user object then, typically, is limited to automatic password changes without breaking services. In a worst case scenario, a sniffed or intercepted (and decoded) password(hash) can only be used for a limited amount of time when you use a vSA.

The benefits of gMSAs

In Windows Server 2008 R2, Microsoft introduced the concept of a Managed Service Account (MSA), and improved on the concept by introducing the group Managed Service Account (gMSA) in Windows Server 2012.

When used in an Active Directory environment that runs the Windows Server 2008 R2 Domain Functional Level (DFL), or up, and using the Active Directory Domain Services Remote Server Administration Tools (AD DS RSAT) on at least Windows Server 2012 or Windows 8, gMSAs offer these benefits:

• The gMSA object type (msDS-ManagedServiceAccount) is derived from the computer account object and lives in the Managed Service Accounts container under the domain root. Therefore;
• It cannot be used to logon interactively
• It cannot be (easily) delegated permissions to, or on
• Additionally, because it acts like a computer object, it’ll automatically try to change its password every 30 days. In a worst case scenario, a sniffed or intercepted (and decoded) password(hash) can only be used for a limited amount of time.
• By default, gMSAs don’t apply to any hosts. You’ll have to explicitly grant a gMSA access to a (group of) host(s), before you can configure it as a service account for a service on the host.
• gMSAs use Kerberos Constrained Delegation (KCD). This means that when you rename the host on which you installed the gMSA, the service configured with the gMSA will remain operable without problems.

gMSAs with Azure AD Connect

Azure AD Connect’s Service Accounts

Azure AD Connect uses three service accounts:

1. A local account on the Windows Server installation running Azure AD Connect, used to run the he Microsoft Azure AD Sync service
2. An account in the Azure Active Directory tenant
3. One account per Active Directory Domain Services environment in scope for Azure AD Connect.

You can use a group Managed Service Account (gMSA) for the first account to run the service on the Windows Server(s) where you’ve installed and configured Azure AD Connect to synchronize objects and attributes between your on-premises Active Directory Domain Services (AD DS) environment(s) and your Azure Active Directory tenant.

This service account is not used to authenticate or communicate to Azure AD (2), and it is also not used to authenticate and communicate to the Active Directory Domain Services environment (3). Therefore, using Azure AD Connect with a gMSA is not the solution to the recent vulnerability that as fixed in Azure AD Connect version 1.1.654.0, and up.

Staging Mode

Azure AD Connect offers Staging Mode functionality, so its high-availability weaknesses are addressed somewhat. While the High Availability aspect of any Azure AD Connect implementation should be considered, Staging Mode is best suited for lifecycle management of Azure AD Connect to cope with other downsides in the way Microsoft releases and supports Azure AD Connect.

When you’re implementing an additional Azure AD Connect installation in Staging Mode, you could reuse the group Managed Service Account (gMSA) you created for the active Azure AD Connect installation, but be sure to create an additional service account, too. Following the recommended practice in this blogpost, this would mean an additional gMSA per additional Azure AD Connect installation.

(Optional) Migration steps

You can’t reconfigure an existing Azure AD Connect installation to use a gMSA. So, if you’re using Azure AD Connect currently with a repurposed user object as its service account, the proper way to change this is by:

1. Implementing an additional Azure AD Connect installation in Staging Mode with the group Managed Service Account (gMSA) as its service account.
2. Recreate any changes you’ve made to the rules and other configuration items. If you haven’t documented these, I recommend to use the Azure AD Connect Configuration Documenter Free to search for differences in the configuration between the two installations.
3. Test to make sure that both Azure AD Connect installations perform the same operations in the metaverse when you make changes to objects in scope.
4. Configure the active Azure AD Connect installation as an additional Staging Mode server and then configure the Staging Mode Azure AD Connect installation as the active Azure AD Connect server .

Optionally, you can check the Relying Party Trust (RPT) between your Active Directory Domain Services environment(s) and your Azure Active Directory tenant, using the Reset Azure AD and AD FS Trust option, and then the Verify AD FS Login option in the Azure AD Connect wizard. I recommend this step when there is a three month gap (or more) between the two Azure AD Connect installations used in the migration.

Implementation steps

To configure Azure AD Connect with a group Managed Service Account (gMSA) as its service account, perform these steps, right before you install and configure Azure AD Connect:

Note:
For this step, the Windows Server installation on which you want to install and configure Azure AD Connect needs to be setup and joined to the domain.

In Active Directory Domain Services

Using the Active Directory Domain Services Remote Server Administration Tools (AD DS RSAT) on at least Windows Server 2012 or Windows 8, create the service account for the Windows Server that will run Azure AD Connect, using the following PowerShell one-liners:

Import-module ActiveDirectory

Add-KdsRootKey -EffectiveImmediately

New-ADServiceAccount -Name gMSA1 -Description "Service account for Azure AD Connect installation 2" –DNSHostName gmsa1.domain.tld -PrincipalsAllowedToRetrieveManagedPassword AADC2$ -Passthru

The above lines of code are an example. Substitute gMSA1, domain.tld and AADC2 and the description with values that are appropriate to your environment and comply with any naming conventions for objects your organization might have.

On the Azure AD Connect server

On the Azure AD Connect Server, run the following PowerShell one-liner in an elevated PowerShell window:

Install-ADServiceAccount -Identity gMSA1

Then, start the installation of Azure AD Connect, by double-clicking the Azure AD Connect installer.

In the Welcome to Azure AD Connect screen, select the I agree to the license terms and privacy notice option and, then, click Continue.

In the Express Settings screen, click Customize.

In the Install required components screen, select the Use an existing service account option. Then, select the Managed Service Account option.

For the SERVICE ACCOUNT NAME enter DOMAIN\gMSA1$ where you’d replace DOMAIN with the NetBIOS name of the Active Directory domain and replace gMSA1 with any other name you might have given your gMSA using the above PowerShell one-liners). You don’t have to enter a password, because this is a gMSA.

Now, configure the Azure AD Connect installation as you would normally. If you don’t want to configure a custom installation location, use an existing SQL Server or want to specify custom sync groups, press Install in the Install required components screen.

Concluding

Since version 1.1.443.0, you can use Azure AD Connect with a group Managed Service Account (gMSA) as its service account. With the recent vulnerability in the way Azure AD Connect creates its service account, it’s the best thing to do. We’ve been designing and implementing Azure AD Connect with gMSAs since version 1.1.443.0 to meet requirements to change the passwords for service accounts regularly.

gMSAs are the way forward for service accounts. Implement yours today.

Further reading

New features in AD DS in Windows Server 2012, Part 8: Group MSAs (gMSAs) Applicability of Managed Service Accounts (MSAs) and group Managed Service Accounts (gMSAs)
Azure AD Connect v1.1.443.0 is here
Azure AD Connect version 1.1.654.0 addresses a critical security vulnerability