Ever have a gMSA stop working?

[Dave Lum]

We have a gMSA account that’s been in use without issue for a few years.  Last night after some server reboots, the service account now appears to be bused. It runs as a service and now we get this on servers that have been using the account
:
                Failure Reason:                 Unknown user name or bad password.

                Status:                                  0xC000006D

                Sub Status:                         0xC000006A

 

Doing Test-ADServiceAccount -Identity "My.gMSA$" comes back as “true”, so I know the principal is still allowed to use it

 

Trying to add this to a new server, however, I get: “Install-ADServiceAccount : Cannot install service account. Error Message: 'An unspecified error has occurred'.”

A gMSA can’t really get locked out, anyone have ideas on what to try next, short of nuke and pave?

 

Dave Lum (he/him)

Systems Administrator
Work hours: Tues – Fri 5:30a – 4:30p Pacific
P: 503.546.2163
E: lu...@ochin.org

 www.ochin.org

 

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

[James Iversen]

I’ve had them age out before they stopped working. Can you manually edit the account spn and add it to the local administrators group on the new server to kick it a little? If the new server already has an spn assigned someplace else, you might need to track that down. 

Sent from my iPhone

On Jun 24, 2026, at 2:37 PM, 'Dave Lum' via ntsysadmin <ntsys...@googlegroups.com> wrote:



We have a gMSA account that’s been in use without issue for a few years.  Last night after some server reboots, the service account now appears to be bused. It runs as a service and now we get this on servers that have been using the account
:
                Failure Reason:                 Unknown user name or bad password.

                Status:                                  0xC000006D

                Sub Status:                         0xC000006A

 

Doing Test-ADServiceAccount -Identity "My.gMSA$" comes back as “true”, so I know the principal is still allowed to use it

 

Trying to add this to a new server, however, I get: “Install-ADServiceAccount : Cannot install service account. Error Message: 'An unspecified error has occurred'.”

A gMSA can’t really get locked out, anyone have ideas on what to try next, short of nuke and pave?

 

Dave Lum (he/him)

Systems Administrator
Work hours: Tues – Fri 5:30a – 4:30p Pacific
P: 503.546.2163
E: lu...@ochin.org

<image001.png>

<image002.png>

<image003.png>

 www.ochin.org

<image004.jpg>

 

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DM8PR17MB4918ABDCD22509439765DABEDDED2%40DM8PR17MB4918.namprd17.prod.outlook.com.

[Sean Rector]

Quick questions so I don't send you down the wrong path: did the DCs reboot too, or just the member servers running the service? And is this environment virtualized?

The gMSA's KDS root key retrieval or the managed password rotated and the affected servers can't decrypt/retrieve the new password, which points at a Kerberos/secure-channel or KDS issue, not the account itself. 0xC000006A (STATUS_WRONG_PASSWORD) under 0xC000006D means the password the server is presenting is stale.

Sent with Proton Mail secure email.

--

[Michael Kurzdorfer]

I have had an issue with gMSA's that stopped working. The issue was the introduction of Server 2025 into our 2019 DC environment. We have RC4 disabled and AES 128/256 enabled for encryption.

This nasty issue actually affected computer/user/gMSA objects. Users were unable to change their passwords, experienced sign-in issues, and encountered gMSA Password failures.

Flurry of “Microsoft-Windows-Kerberos-Key-Distribution-Center” EventCode=14/16 against users, computers, gMSA accounts. 

 

Message=While processing an AS request for target service krbtgt, the account xxxxxx did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17 3. The accounts available etypes : 23. Changing or resetting the password of xxxxx will generate a proper key.

 

Message=While processing a TGS request for the target server HTTP/xxxxxxx, the account xxx...@xxxxxxx.xxx did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 9). The requested etypes were 18 17 23 3 1. The accounts available etypes were 23. Changing or resetting the password of xxxxxxx$ will generate a proper key.

After opening a ticket with Microsoft and providing some details, they responded with:

This is a known interoperability behavior between Windows Server 2025 and earlier domain controllers.

Specifically, the issue involves Kerberos authentication failures—most notably the ETYPE_NOSUPP error—following password changes that are processed across mixed domain controller environments. This behavior can result in authentication errors for user, computer, service, or gMSA accounts.

The root cause stems from how encryption keys are handled during password changes. If a password change is serviced by a Pre-Windows Server 2025 domain controller and then followed by another change on a 2025 controller, AES keys may be discarded if you attempt to authenticate with a Pre-2025 Domain controller, leaving only RC4 keys available. This can lead to failed authentication attempts, especially in environments enforcing AES encryption like yours.

There are two possible workarounds:

1. Standardize on Windows Server 2025 DCs
   Promote all DCs to Windows Server 2025. This ensures AES keys availability. 
2. Remove Windows Server 2025 DCs temporarily
   Continue running your domain controllers only on Windows Server 2022-2019-2016 until a product fix is available. In this case, you should reset the passwords of affected computers, users, service accounts twice to rebuild the missing encryption keys. For Group Managed Service Accounts (gMSAs), you will need to wait until the automatic password reset occurs (30 days) or create new gMSAs, since you cannot force shorter reset intervals post-creation.

This was in our lab environment (thankfully). We had to hunt down and reset all user/computer passwords (twice). As mentioned above, we could either wait 30 days for the password to cycle (which worked) or recreate it. Unfortunately, there are no methods to influence when the gMSA changes the password early. Only at gMSA creation can you specify 'ManagedPasswordIntervalInDays'  (Default is 30).

This ticket was closed in October, and we have inquired several times with our CSAM/Incident Manager; however, we received no further updates. 

--

[Mayo, Bill]

Several weeks ago, all of our client computers started popping up a window that a certificate needed to be renewed and showed 3 specific certificate templates to choose from. We went down a lot of different paths, but we ultimately figured out that it was tied the group policy setting for automatically renewing certificates that are going to expire. We have had policy settings to create a computer and user certificate for more than a decade, but since they don’t all come due at the same time, I had originally dismissed the notion that this was the case.

 

After some testing with the settings on the templates, I noticed that some things looked off and I deleted one of the certificate templates that we don’t actually use anymore. When I did that, we noticed that this particular certificate dropped off the prompt that clients were getting. This lead to deleting the other 2 as well, and then re-issued them. After doing this, people stopped getting the pop-ups altogether.

 

Seemed like problem solved, but it seems that the newly re-issued Computer certificate is not automatically renewing for computers. I did do a manual test and that seemed to work, but we are not seeing any other renewals and we should be. I have done a gpresult and the correct policies are there. I did note that the built-in Computer template that I cloned is a newer version and I am not completely sure I set all the settings right. I don’t see any failed requests on the CA, so it seems like clients just aren’t requesting the renewal. Any ideas on what I might have missed or a good way to troubleshoot? I am able to find some computers that should be renewing by now, but not really sure what to look for on them.

 

Any help appreciated.

 

Bill Mayo

[Michael B. Smith]

Did you recreate the GPO? If not, even if you named the template the same thing, it’s not connecting to the proper template. GUIDs and all that.

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB12205A445CA175B0C964228409BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Mayo, Bill]

I’m happy to find out that there is something of which I am unaware, but when you go to the setting in GP, it just gives you some generic options (I am choosing Computer).

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/a2d861ebd6a448748e942f874ab2173b%40smithcons.com.

[Michael B. Smith]

You are doing this the old-fashioned way. That way only shows version 1 templates.

 

Configure the policy below, instead. I also suggest you enable the “Certificate Services Client – Certificate Enrollment Policy”.

 

 

Then, for each template you want auto-enrolled, on the request handling tab select “enroll subject without requiring any user input”, set the subject name to populate from AD (usually DNS name), and on the security tab add the group that should auto-enroll (or set permissions properly). This is usually Domain Computers. The required permissions are Read + Enroll + Autoenroll.

 

Of course, publish the template.

 

Then, at next reboot, the certificate should renew.

 

You can force it to happen before a reboot:

 

               gpupdate /force

               certutil -pulse

 

The CertificateServicesClient-AutoEnrollment event log contains details.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB122054573C521DA38440AA3229BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Mayo, Bill]

Thanks, Michael. I do actually have the setting in your screen shot below configured, exactly as depicted there. I do not have “Certificate Services Client -  Certificate Enrollment Policy” enabled. I note that when you enable that, there are other options—just use the defaults?

 

On the template, I do have all the things you indicated set that way, with the exception of permissions. By default, it just had “enroll” enabled. I had debated changing that, as I had the old one having all 3 of those things, but I also looked at some others and it looked like that wasn’t that way, so I left it along. I have now enabled all those. One question that occurred to me when doing this process, is whether you need to un-publish and then re-publish the certificate template after making changes. Is it necessary to do that?

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/95fb15f907f44193a08d91f00a8e5bff%40smithcons.com.

[James Iversen]

Don’t enable Certificate Services Client - Certificate Enrollment Policy if it wasn’t already enabled. Path Validation and Auto-Enrollment is the way to go to use templates. 

Sent from my iPhone

On Jun 25, 2026, at 10:35 AM, Mayo, Bill <Bill...@pittcountync.gov> wrote:



Thanks, Michael. I do actually have the setting in your screen shot below configured, exactly as depicted there. I do not have “Certificate Services Client -  Certificate Enrollment Policy” enabled. I note that when you enable that, there are other options—just use the defaults?

 

On the template, I do have all the things you indicated set that way, with the exception of permissions. By default, it just had “enroll” enabled. I had debated changing that, as I had the old one having all 3 of those things, but I also looked at some others and it looked like that wasn’t that way, so I left it along. I have now enabled all those. One question that occurred to me when doing this process, is whether you need to un-publish and then re-publish the certificate template after making changes. Is it necessary to do that?

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Michael B. Smith
Sent: Thursday, June 25, 2026 10:22 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Internal CA Corrupt Template

 

You are doing this the old-fashioned way. That way only shows version 1 templates.

 

Configure the policy below, instead. I also suggest you enable the “Certificate Services Client – Certificate Enrollment Policy”.

 

<image001.png>

 

Then, for each template you want auto-enrolled, on the request handling tab select “enroll subject without requiring any user input”, set the subject name to populate from AD (usually DNS name), and on the security tab add the group that should auto-enroll (or set permissions properly). This is usually Domain Computers. The required permissions are Read + Enroll + Autoenroll.

 

Of course, publish the template.

 

Then, at next reboot, the certificate should renew.

 

You can force it to happen before a reboot:

 

               gpupdate /force

               certutil -pulse

 

The CertificateServicesClient-AutoEnrollment event log contains details.

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mayo, Bill
Sent: Thursday, June 25, 2026 9:45 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Internal CA Corrupt Template

 

I’m happy to find out that there is something of which I am unaware, but when you go to the setting in GP, it just gives you some generic options (I am choosing Computer).

<image002.png>

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB12205394108EBAD8B5BE9AAF79BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Mayo, Bill]

Quick update. It seems like changing the permissions has resolved the issue. I really should have done that anyway, and I feel dumb for not having done so. That does seem to indicate that making changes to the template doesn’t need re-issuing.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mayo, Bill
Sent: Thursday, June 25, 2026 10:35 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Internal CA Corrupt Template

 

EXTERNAL EMAIL: This email originated from outside of Pitt County Government. Do not click any links or open any attachments unless you trust the sender and know the content is safe.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB12205394108EBAD8B5BE9AAF79BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Michael B. Smith]

Correct.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB12205F8DCA44C306EB608C6889BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Michael B. Smith]

>> I do not have “Certificate Services Client -  Certificate Enrollment Policy” enabled. I note that when you enable that, there are other options—just use the defaults?

 

As Mr. Iverson said – some people say not to do this. And some people say to enable path validation. All I can really say is that neither is relevant to the problem at hand – but you should evaluate the policies for your environment.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB12205394108EBAD8B5BE9AAF79BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Mayo, Bill]

Great. Thanks for your help. I assume it is safe to remove the “old-fashioned” setting under Automatic Certificate Requests with no ill effect?

 

Complaining to the void, but it sure would be nice if there was some indication on these settings that one is legacy and the other is “modern”. I am not seeing anything to indicate that. Reading the description of “Certificate Services Client – Auto-Enrollment”, it sure sounds like its purpose is just to renew already generated certificates and that it would not do a new certificate if one didn’t already exist.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/660c32dde9874d14956a125af8f85316%40smithcons.com.

[James Iversen]

AFAIK, the autoenroll feature will renew or issue if none exists. 

Sent from my iPhone

On Jun 25, 2026, at 11:09 AM, Michael B. Smith <mic...@smithcons.com> wrote:



>> I do not have “Certificate Services Client -  Certificate Enrollment Policy” enabled. I note that when you enable that, there are other options—just use the defaults?

 

As Mr. Iverson said – some people say not to do this. And some people say to enable path validation. All I can really say is that neither is relevant to the problem at hand – but you should evaluate the policies for your environment.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mayo, Bill
Sent: Thursday, June 25, 2026 10:35 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Internal CA Corrupt Template

 

Thanks, Michael. I do actually have the setting in your screen shot below configured, exactly as depicted there. I do not have “Certificate Services Client -  Certificate Enrollment Policy” enabled. I note that when you enable that, there are other options—just use the defaults?

 

On the template, I do have all the things you indicated set that way, with the exception of permissions. By default, it just had “enroll” enabled. I had debated changing that, as I had the old one having all 3 of those things, but I also looked at some others and it looked like that wasn’t that way, so I left it along. I have now enabled all those. One question that occurred to me when doing this process, is whether you need to un-publish and then re-publish the certificate template after making changes. Is it necessary to do that?

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Michael B. Smith
Sent: Thursday, June 25, 2026 10:22 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Internal CA Corrupt Template

 

You are doing this the old-fashioned way. That way only shows version 1 templates.

 

Configure the policy below, instead. I also suggest you enable the “Certificate Services Client – Certificate Enrollment Policy”.

 

<image001.png>

 

Then, for each template you want auto-enrolled, on the request handling tab select “enroll subject without requiring any user input”, set the subject name to populate from AD (usually DNS name), and on the security tab add the group that should auto-enroll (or set permissions properly). This is usually Domain Computers. The required permissions are Read + Enroll + Autoenroll.

 

Of course, publish the template.

 

Then, at next reboot, the certificate should renew.

 

You can force it to happen before a reboot:

 

               gpupdate /force

               certutil -pulse

 

The CertificateServicesClient-AutoEnrollment event log contains details.

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mayo, Bill
Sent: Thursday, June 25, 2026 9:45 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: Internal CA Corrupt Template

 

I’m happy to find out that there is something of which I am unaware, but when you go to the setting in GP, it just gives you some generic options (I am choosing Computer).

<image002.png>

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/660c32dde9874d14956a125af8f85316%40smithcons.com.

[Michael B. Smith]

>> it is safe to remove the “old-fashioned” setting under Automatic Certificate Requests with no ill effect?

 

Correct.

 

As to your other comment – I don’t have a good response. 😊 Microsoft has historically not done a really great job with documenting anything but Administrative Templates in GP – and those they add and whack without any regard for admin needs.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/DS9PR09MB122055F0A9EE568A66F52DA179BEC2%40DS9PR09MB12205.namprd09.prod.outlook.com.

[Sean Rector]

Typical Microshaft.

Sent from Proton Mail for iOS.

-------- Original Message --------

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/00be2b07dc68465dadd3f65c0a26658a%40smithcons.com.

[Denes, Laszlo]

Damn that’s wild.. glad I moved to 2022 DC as option first…

 

Thank you in advance for your time.

 

Laszlo

 

Laszlo Denes

Senior Technical Analyst Servers

Information Systems

t: ext. 214

lde...@torontograce.org

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CA%2BZZigZxS%3DyKoi5QdQA33OmYJxLDed0KYGxt1saeS2ibe1%3DbuQ%40mail.gmail.com.

[Hammer, Erich F]

https://bobdahacker.com/blog/fifa-hack

[Wright, John M]

Lol.  RBAC with a client-side text file.  Types “admin,” owns the box.

 

--

John Wright

IT Support Specialist

1800 Old Bluegrass Avenue, Louisville, KY 40215

502.708.9953

Please submit IT requests to Hazelwoo...@bluegrass.org

24 Hour Helpline 1.800.928.8000

  

CONFIDENTIALITY NOTICE: This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Hammer, Erich F
Sent: Friday, June 26, 2026 12:51 PM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] Yikes!

 

This is the first time you received an email from this sender (er...@albany.edu). Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

Secured by Check Point

 

https://bobdahacker.com/blog/fifa-hack

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/IA3PR04MB91827D9887FA007BB8456B2ECCEB2%40IA3PR04MB9182.namprd04.prod.outlook.com.