When Did That Service Account Last Rotate? (Part 5 of 6)

Enabling businesses to self-secure providing enterprise-grade security practices, regardless of size. Businesses shouldn’t REQUIRE massive IT security teams to keep their business safe.

Part 5 of 6 · Moving Past LDAP Simple Bind

Starting here is honestly fine – this is the part people quietly need most. Quick orientation if you skipped the earlier ones: the series treats securing LDAP as three separate jobs – the connection, the login, and the account – and this part is the account. It’s the one the other fixes leave untouched.

This series splits “securing LDAP” into three jobs – transit (A), authentication (B), and the account itself (C). Part 3 handled the tunnel; Part 4 handled the login. This article is Concern C, the one the other controls leave on the table – and it is where simple bind does its quietest damage.

𝗧𝗵𝗲 𝗮𝗰𝗰𝗼𝘂𝗻𝘁 𝗲𝘃𝗲𝗿𝘆𝗼𝗻𝗲 𝗵𝗮𝘀 𝗮𝗻𝗱 𝗻𝗼𝗯𝗼𝗱𝘆 𝘁𝗮𝗹𝗸𝘀 𝗮𝗯𝗼𝘂𝘁

A shared, static, over-privileged service account whose password has not changed in years. Sound familiar? Most environments have at least one. It is unique or shared – usually shared. Least-privilege or over-powered – usually over-powered. Its password rotates – almost never. And you can tell who used it – almost never that either.

A perfectly encrypted tunnel and a flawless Kerberos bind do nothing about this. A gMSA bound over cleartext still leaks; an over-privileged account is dangerous no matter how it authenticates. Account hygiene is not a substitute for transit or authentication controls – it sits alongside them. The fix is to stop hand-managing these accounts.

a shared, static account whose password never changed

𝗴𝗠𝗦𝗔 – 𝘁𝗵𝗲 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗮𝗻𝗮𝗴𝗲𝘀 𝗶𝘁𝘀 𝗼𝘄𝗻 𝗸𝗲𝘆𝘀

A group Managed Service Account (gMSA) is a domain account whose password Active Directory creates and rotates automatically (every 30 days by default – set at creation and fixed for the life of the account), handing it only to the specific computers you authorize through a security group. No stored password, automatic SPN management, and a clear record of use.

If a service account is a set of building keys, many teams today cut one master key, hand copies to everyone, and never re-cut them. A gMSA is the building managing its own keys: re-cut automatically on a schedule, handed only to the staff who need them, with a log of every use. You never hold the master key, so you cannot lose it.

AD rotates the key for you, automatically

𝗱𝗠𝗦𝗔 – 𝗯𝘂𝗶𝗹𝘁 𝘁𝗼 𝗿𝗲𝗽𝗹𝗮𝗰𝗲 𝘁𝗵𝗲 𝗼𝗹𝗱 𝗮𝗰𝗰𝗼𝘂𝗻𝘁 𝗼𝘂𝘁𝗿𝗶𝗴𝗵𝘁

On Windows Server 2025, a delegated Managed Service Account (dMSA) goes further. A dMSA is designed to replace an existing standard service account, migrating it into a managed account whose authentication is bound to approved machine identities – so credentials harvested from the old account stop working. It aims squarely at the credential-harvesting attacks that plague traditional service accounts.

Powerful, but read the caution before you roll it out broadly.

𝗛𝗼𝘄 𝘁𝗼 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁, 𝗯𝗿𝗶𝗲𝗳𝗹𝘆:

• Ensure the KDS root key exists in the domain (Add-KdsRootKey), then create the account with New-ADServiceAccount.

• Authorize only the specific hosts that may retrieve the password, via a security group on the account.

• Install it on each host (Install-ADServiceAccount) and point the service at it – no password to store.

• Scope its directory rights to least privilege: grant only what the service truly needs, and review it.

• On 2025, evaluate dMSA for new services. Note the current Credential Guard machine-account rotation caveat before broad rollout, and confirm Kerberos encryption types, DNS, and SPNs are in order.

𝗧𝘄𝗼 𝗰𝗮𝘂𝘁𝗶𝗼𝗻𝘀 𝘄𝗼𝗿𝘁𝗵 𝘆𝗼𝘂𝗿 𝗮𝘁𝘁𝗲𝗻𝘁𝗶𝗼𝗻. First, the Credential Guard rotation caveat above – test it before you depend on it. Second, “BadSuccessor” – a dMSA privilege-escalation technique (Microsoft-rated moderate, no patch as of this writing) that the mere presence of a 2025 DC exposes, whether or not you use dMSA. The exposure comes from who can create dMSA objects, so audit and restrict create/write permissions on your OUs accordingly.

reinforces the “BadSuccessor” dMSA escalation caution

𝗧𝗵𝗲 𝘀𝗲𝗻𝘁𝗲𝗻𝗰𝗲 𝘁𝗵𝗮𝘁 𝘁𝗶𝗲𝘀 𝗮𝗹𝗹 𝘁𝗵𝗿𝗲𝗲 𝗰𝗼𝗻𝗰𝗲𝗿𝗻𝘀 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿

Here is the detail that proves the whole framing of this series in a single fact: Windows will not return a gMSA’s password (the msDS-ManagedPassword attribute) over LDAP unless the connection provides confidentiality – LDAPS, or a Kerberos sign-and-sealed connection.

That is the three concerns in one sentence. The account control (C) depends on a protected channel (A), and neither replaces the authentication mechanism (B). You cannot cleanly do C without having done A. They are genuinely interlocking, which is exactly why “we turned on LDAPS” was never a finish line.

the account control depends on a protected channel

𝗤𝘂𝗶𝗰𝗸 𝗮𝗻𝘀𝘄𝗲𝗿𝘀 𝗽𝗲𝗼𝗽𝗹𝗲 𝗮𝗹𝘄𝗮𝘆𝘀 𝗮𝘀𝗸

• 𝗗𝗼𝗲𝘀 𝗮 𝗴𝗠𝗦𝗔 𝗼𝗿 𝗱𝗠𝗦𝗔 𝗲𝗻𝗰𝗿𝘆𝗽𝘁 𝗮𝗻𝘆𝘁𝗵𝗶𝗻𝗴 𝗼𝗻 𝘁𝗵𝗲 𝘄𝗶𝗿𝗲? No. Managed accounts address the account itself – rotation, no stored password, scoping. They do nothing for transit or the bind on their own.

• 𝗗𝗼𝗲𝘀 𝗮 𝗺𝗮𝗻𝗮𝗴𝗲𝗱 𝗮𝗰𝗰𝗼𝘂𝗻𝘁 𝗿𝗲𝗺𝗼𝘃𝗲 𝘁𝗵𝗲 𝗻𝗲𝗲𝗱 𝗳𝗼𝗿 𝗟𝗗𝗔𝗣𝗦? No – the opposite. Windows won’t return a gMSA password over LDAP unless the connection provides confidentiality. The account control depends on a protected channel.

• 𝗗𝗼𝗲𝘀 𝗶𝘁 𝗿𝗲𝗽𝗹𝗮𝗰𝗲 𝗞𝗲𝗿𝗯𝗲𝗿𝗼𝘀? No. A gMSA/dMSA is what the service authenticates as; Kerberos is how it authenticates. Use them together.

𝗧𝗵𝗶𝘀 𝗶𝘀 𝗣𝗮𝗿𝘁 𝟱 𝗼𝗳 𝗮 𝟲-𝗽𝗮𝗿𝘁 𝘀𝗲𝗿𝗶𝗲𝘀.

Previously – Part 4: Why Send a Password You Can’t Take Back?

Next – Part 6: Are You Hoping Your LDAP Is Secure – or Do You Know? Three concerns, one migration. We sequence the whole effort end to end, cover publishing secure LDAP behind an F5, and document the controlled, time-boxed exception for that one legacy system that just won’t move yet.

Full series:

• Part 1 – Did You Really Secure LDAP – or Just One-Third of It?

• Part 2 – Is Your Domain Controller Leaking Passwords?

• Part 3 – Is Your “Encrypted” LDAP Actually Protected?

• Part 4 – Why Send a Password You Can’t Take Back?

• Part 5 – When Did That Service Account Last Rotate? (this article)

• Part 6 – Are You Hoping Your LDAP Is Secure – or Do You Know?

What’s the oldest service account in your directory, and when did its password last change? No judgment – we’ve all inherited one.

We’ve all inherited the account whose password hasn’t changed in years. If this article named yours, repost it – and go find out who can create dMSA objects in your domain before someone else does. Follow for Part 6, where the whole series comes together.

No judgment, but: how old is the oldest service account in your directory? Drop it below. And repost this for the teammate who owns the one you’re both quietly avoiding.

𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀:

• Group Managed Service Accounts overview

• Delegated Managed Service Accounts overview (Windows Server 2025)

• Setting up delegated Managed Service Accounts

𝗚𝗹𝗼𝘀𝘀𝗮𝗿𝘆

• Service account: a non-human account an application or service logs in as; often shared, static, and over-privileged, which makes it the weak point this part fixes.

• gMSA: Group Managed Service Account; a domain account whose strong password Active Directory generates and rotates automatically, scoped to authorized hosts.

• dMSA: Delegated Managed Service Account; a Windows Server 2025 account type that replaces a standard service account, binding authentication to approved machine identities.

• Least privilege: granting an account only the access it actually needs, and nothing more.

• KDS root key: the domain-wide key material that makes gMSA/dMSA password generation possible (created with Add-KdsRootKey).

• SPN: Service Principal Name; the unique name Kerberos uses to identify a service; managed automatically for a gMSA.

• Credential Guard: a Windows security feature that isolates and protects stored credentials; note its machine-account rotation caveat before broad dMSA rollout.

• BadSuccessor: a dMSA privilege-escalation technique exposed by the presence of a 2025 DC; mitigated by restricting who can create dMSA objects.

• OU: Organizational Unit; a container in Active Directory used to group objects so permissions and policy can be targeted at them.

• msDS-ManagedPassword: the directory attribute holding a gMSA’s password, which AD only returns over a confidential connection (LDAPS or Kerberos sign-and-seal).

• LDAPS: LDAP over TLS (port 636); the protected channel a gMSA password retrieval depends on.

• Kerberos: the ticket-based authentication a managed account uses; what the service authenticates with, while the gMSA/dMSA is what it authenticates as.

#ActiveDirectory #gMSA #ServiceAccounts #WindowsServer2025 #IdentitySecurity