Managed Service Accounts: Easy & Secure Credential Management in Active Directory

“Task Scheduler failed to run: Login failure as user account password expired.”

The scheduled job had stopped not because of code or network failure, but because the automation account password had expired. The admin soon realized this was a common issue linked to relying on regular user accounts to run critical services.

It’s easy to think that using a normal account and setting its password to never expire is a safe workaround. But the trade-offs are serious: no password rotation and a permanent credential stored in the system, making it a perfect target for attackers. This is where Managed Service Accounts (MSAs), a built-in Active Directory feature, become relevant.

On exploring more about Managed Service Accounts (MSAs), he discovered that they could automate credential management for services. The idea caught his attention immediately: “An account that updates its own password?” Intrigued, he dug deeper and learned that these are special Active Directory accounts for running services, and scheduled tasks without manual password management. Active Directory automatically generates a strong 240-byte password for each MSA and rotates it every 30 days by default, removing the need for human intervention.

With automatic password handling, Kerberos support, and enhanced security controls, MSAs make managing critical services far simpler and more secure. Managed Service Accounts come in two types: Standalone Managed Service Accounts (sMSA) and Group Managed Service Accounts (gMSA). Both are designed to replace traditional user accounts, simplify service authentication, and automate password management, differing mainly in where and how they’re used.

Standalone Managed Service Accounts (sMSA)

• An sMSA, introduced in Windows Server 2008 R2, is designed for a single computer. It automatically handles password management and simplifies service configuration on that specific machine.
• However, it can’t be shared across multiple servers, which limits its use in environments like web farms or clustered applications. To address this limitation, Microsoft later introduced Group Managed Service Accounts (gMSA).

Group Managed Service Accounts (gMSA)

• A gMSA, introduced in Windows Server 2012, extends the concept of sMSA by allowing multiple computers to use the same service account. It securely distributes and manages credentials across authorized servers and workstations, making it ideal for load-balanced or clustered services.
• With gMSAs, you get the same benefits of automation and security, but with the flexibility needed in modern multi-server setups.

Before creating Managed Service Accounts (MSAs), ensure your environment meets these basic requirements:

• Computers must be domain-joined, as MSAs don’t work on standalone or workgroup systems.
• The domain functional level must be at least Windows Server 2008 R2 for sMSA and Windows Server 2012 for gMSA.
• Target computers must run Windows Server 2008 R2 or later for sMSA, and Windows Server 2012 or later for gMSA.
• The Active Directory PowerShell module must be installed on all the target computers through RSAT.
• Domain Admin or Enterprise Admin privileges are required to create and assign Managed Service Accounts in Active Directory.

Let’s look at how to create the two types of Managed Service Accounts in Active Directory. MSA creation cannot be done through the Active Directory UI; It must be done using PowerShell. The overall process is similar, but Group Managed Service Accounts (gMSAs) require a few additional steps.

• Configure Standalone Managed Service Account (sMSA)
• Configure Group Managed Service Account (gMSA)
• Run Scheduled Task with Managed Service Account

Let’s start by creating our standalone MSA on a domain controller that already meets all the prerequisites.

1. Open PowerShell with administrative privileges on a domain controller computer and run the cmdlet below, replacing <sMSAName> with the desired account name.

2. Run the following cmdlet, replacing <TargetComputerName> with the desired computer name to link it to the sMSA.

3. Finally, run the following cmdlet to verify that the sMSA has been successfully created.

If this returns account details, the sMSA is created successfully. It can then be viewed in Active Directory Users and Computers (ADUC) under the Managed Service Accounts container.

1. Log in to the target computer, the same system specified during sMSA creation. You cannot install it from a domain controller or another computer.

2. Run the following command to install the sMSA.

This installs the sMSA locally and allows the system to retrieve its managed password.

3. To verify that the installation on the target computer was successful, run the command below.

This should return True, confirming that the account is properly installed, and the computer can retrieve its password.

Creating a gMSA requires additional steps, starting with a Key Distribution Service (KDS) Root Key. Domain Controllers use this key to securely generate and distribute gMSA passwords across the domain.

1. Check if a KDS Root Key already exists in the domain:

2. If no key is found, create a new KDS Root Key by running one of the following commands, based on your need.

• To create a KDS root key with default activation

By default, the key becomes effective 10 hours after creation (replication delay).

• To create a KDS root key immediately

This forces the root key to be available immediately on the current domain controller, though replication to other DCs can take up to 10 hours.

• Create KDS root key and bypass replication delay for testing

This sets the KDS root key 10 hours in the past, letting gMSAs be created immediately across DCs for testing.

3. Then, use the following cmdlet to test the KDS root key. It must return the value of True.

1. Create a Security Group to define which computers can retrieve the gMSA password.

2. Add the desired workstations or servers to the group so they can use the gMSA.

3. Create the gMSA by specifying the name, domain, and the security group allowed to retrieve the managed password.

4. Verify that the newly created gMSA exists in Active Directory by running the below in the target machine.

Just like the sMSA, the gMSA is also stored in the Managed Service Accounts container in Active Directory by default.

1. Unlike sMSA, gMSAs do not require manual installation. Once a computer is added to the security group allowed to retrieve the password, the system handles it automatically via the Key Distribution Service (KDS).

2. Before assigning the gMSA to a service, verify that the target computer can access it by running the below in the target machine.

If the test returns True, the gMSA is properly configured and ready to be used by services (like IIS App Pools, SQL Server, or Scheduled Tasks).

Note: If the test doesn’t return True, the computer may not yet recognize the group membership. You can reboot the machine or run the following command to update Active Directory group membership without logging off.

After creating and installing the Managed Service Account (sMSA or gMSA), the next step is to test it by running an automated task. Managed Service Accounts are commonly used for Task Scheduler scripts, Windows Services, and IIS App Pools.

Here’s an example of using a Group Managed Service Account (gMSA) to run a scheduled task.

Grant Logon as Batch Job Rights for MSA on Target Computers

1. To allow the Managed Service Account to run scheduled tasks, it must have the “Log on as a batch job” right.
   • a. If the task runs on a few computers, open Local Security Policy (secpol.msc) in the desired computer → Local Policies → User Rights Assignment → Log on as a batch job → Add User or Group → Add the MSA.
   • b. If the task runs across many computers, use Group Policy Management (gpmc.msc) in the DC → <DesiredDomain> → Default Domain Policy → Edit → Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Log on as a batch job → Add user or group → Add the MSA.

Prepare the PowerShell Script for MSA Scheduled Task

2. Save the PowerShell script (e.g., a script to export all inactive users in Active Directory at regular intervals) in the desired folder.
3. Note the full path of the script; it will be required when creating the scheduled task.

Create the Scheduled Task Using MSA

4. When creating a scheduled task via the GUI, the MSA may not appear in the default search for users. To select the account, open Task Scheduler → Actions → Create Task → Select the “Change User or Group” option.
5. In the dialog, click on Locations and choose Entire Directory.
6. Click Object Types and uncheck Users and Built-in security principals, leaving only Service Accounts checked.
7. Search and select the MSA account successfully.

Configure the Scheduled Task with MSA

8. Check ‘Run whether user is logged on or not’.
9.Choose ‘Run with highest privileges’ if required
10. Set the ‘Trigger’ (e.g., daily at 12:05 PM).
11. Set the Action to run your desired script with proper parameters.

Test the Scheduled Task with MSA

12. Save the task and run it manually to ensure it is executed correctly.
13. Verify the script output and ensure it automatically executes at regular intervals (If outputs are missing, a reboot may help).
14. Check Task Scheduler history for any errors.

Finally, confirm that the scheduled task can run reliably under the Managed Service Account without requiring manual intervention. Just like this, an MSA can be used effectively in numerous other important automation and service scenarios across Active Directory.

Things to Note:

• In addition to sMSAs and gMSAs, Delegated Managed Service Accounts (dMSAs) were introduced in Windows Server 2025.
• dMSAs are designed to counter Kerberoasting and credential theft by ensuring credentials never leave the domain controller.
• They provide stronger authentication through device-bound trust and eliminate local password storage. · If the service you’re running uses Kerberos authentication, register a Service Principal Name (SPN) for the Managed Service Account.
• This allows Kerberos to correctly identify and authenticate the service.
• A gMSA test may fail if the target computer doesn’t support all Kerberos encryption types required by that gMSA.
• Ensure that AES encryption types are enabled and consistent across domain controllers and servers.
• You can’t use RunAs with MSAs because they don’t have user-accessible passwords. Instead, use PsExec to verify that the MSA functions as expected.

Wrapping Up

Our frustrated admin, once battling expired passwords and failed tasks, found relief with Managed Service Accounts (MSAs). Tasks ran reliably, scripts were executed on time, and security improved, all without manual password updates. MSAs are now a must-have feature in their environment for a secure Active Directory setup.

Stay tuned for more cybersecurity blog series on Active Directory and Microsoft 365 to elevate your IT security knowledge.