Confused about getting started using Group Managed Service Accounts,

426 views
Skip to first unread message

Mike Leone

unread,
Apr 12, 2024, 10:36:33 AM4/12/24
to NTSysAdmin
OK. So I have a number of scheduled tasks that execute as a normal domain user account, and I'd like to see if I can transition them to using a gMSA, per MS recommendations. I'm looking at MS's Step-by-Step (https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-how-to-work-with-group-managed-service-accounts/ba-p/329864), and it says the first thing to do is:

In order to start the configuration process, we need to create KDS root key. This need to run from domain controller with domain admin or enterprise admin privileges.

 

Add-KdsRootKey –EffectiveImmediately


OK, fine. But in my AD, I already see one account in the "Managed Service Accounts" container. I don't recall making one, so possibly a co-worker did. So I decided to check ..


PS O:\software\PHA Scripts> get-kdsrootkey


AttributeOfWrongFormat :
KeyValue               : {values...}
EffectiveTime          : 1/28/2016 2:31:32 PM
CreationTime           : 1/28/2016 2:31:32 PM

IsFormatValid          : True
DomainController       : CN=<non-existent-DC>\0ADEL:e8837bc6-8066-4264-8748-c0ed4e18fee4,CN=Deleted Objects,DC=...
ServerConfiguration    : Microsoft.KeyDistributionService.Cmdlets.KdsServerConfiguration
KeyId                  : <keyID>
VersionNumber          : 1


Uhmmmm ... apparently we had a KdsRootKey created way back when, but the DC listed above doesn't exist anymore, it was decommissioned years ago. Is that going to be a problem? Do I need to do anything, and if so, what? Or is that just a "historical" value of some sort??


I'm leery of issuing a "Test-KdsRootKey", in case it fails, and I don't know how to fix it ...


For right now, I'm going to fall back on just using a regular domain account (a different one than the one I am move away from),  until I get a better understanding of GMSAs and my particular situation ...


I did do this:


PS O:\software\PHA Scripts> Get-KdsConfiguration


AttributeOfWrongFormat          :
KdfParameters                   : {values}
SecretAgreementParameters       : {values}
IsValidFormat                   : True
SecretAgreementAlgorithm        : DH
KdfAlgorithm                    : SP800_108_CTR_HMAC
SecretAgreementPublicKeyLength  : 2048
VersionNumber                   : 1


So I *guess* it's not too foobarred, if I have a valid format??



--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

Brian Illner

unread,
Apr 12, 2024, 10:50:32 AM4/12/24
to ntsys...@googlegroups.com

Running the ‘Test’ command wouldn’t do anything destructive. In fact, you’re going to be using a similar one, Test-ADServiceAccount, quite a bit as you move to gMSA accounts

 

I would say that as long as your domain sees the existing rootkey as valid, you are good to go.

 

One thing I will stress: Use new AD Security Groups for the ‘PrincipalsAllowedToRetrieveManagedPassword’ property when creating the gMSAs. That property is actually an array which causes all kinds of administrative headaches if the server names are directly added.

 

BRIAN ILLNER

 

Senior Systems Administrator

864.250.9227 Office

864.679.2537 Fax

Canal Insurance Company

101 N. Main Street, Suite 400

Greenville, SC 29601

WARNING:  As the information in this transmittal (including attachments, if any) may contain confidential, proprietary, or business trade secret information, it should only be reviewed by those who are the intended recipients.  Unless you are an intended recipient, any review, use, disclosure, distribution or copying of this transmittal (or any attachments) is strictly prohibited.   If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal.  While Canal believes this transmittal to be free of virus or other defect, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Canal (or its subsidiaries and affiliates) for any loss or damage arising therefrom.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Friday, April 12, 2024 10:36 AM
To: NTSysAdmin <ntsys...@googlegroups.com>
Subject: [ntsysadmin] Confused about getting started using Group Managed Service Accounts,

 

CAUTION: This message was sent from outside of Canal Insurance. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "inf...@canal-ins.com" as an attachment.


--
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 on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BhwM9dRcLw0xqjJ_5FOGMWDJWyuHABUmjdEn0m4ZkKkuw%40mail.gmail.com.

Mike Leone

unread,
Apr 12, 2024, 11:00:10 AM4/12/24
to ntsys...@googlegroups.com
On Fri, Apr 12, 2024 at 10:50 AM Brian Illner <Brian....@canal-ins.com> wrote:

Running the ‘Test’ command wouldn’t do anything destructive. In fact, you’re going to be using a similar one, Test-ADServiceAccount, quite a bit as you move to gMSA accounts

 

I would say that as long as your domain sees the existing rootkey as valid, you are good to go.


OK! I thought so, but wasn't sure, being brand new to all this ...

I'll try running the test later today ...
 

One thing I will stress: Use new AD Security Groups for the ‘PrincipalsAllowedToRetrieveManagedPassword’ property when creating the gMSAs. That property is actually an array which causes all kinds of administrative headaches if the server names are directly added.


OK, good point, I will keep it in mind. Further to that ... so I need an AD group of all hosts that a specific Service Account would touch, right? 
So if I wanted to run a task that executes a PowerShell script on a bunch of hosts, I would need to add all those hosts to said group? 
What if I wanted it to run on say all my servers? (to query Windows Update history, as a specific and real life example) 
Do I need to add all my hosts to that group, and remember to add any new hosts I create to it, and remove any hosts I get rid of? 

I'm guessing that using "Domain Computers" as the AD group in that  PrincipalsAllowedToRetrieveManagedPassword’ would not be a wise choice?

Thanks for any insights.

Mike Leone

unread,
Apr 12, 2024, 11:10:06 AM4/12/24
to ntsys...@googlegroups.com
On Fri, Apr 12, 2024 at 10:50 AM Brian Illner <Brian....@canal-ins.com> wrote:

Running the ‘Test’ command wouldn’t do anything destructive. In fact, you’re going to be using a similar one, Test-ADServiceAccount, quite a bit as you move to gMSA accounts

 

I would say that as long as your domain sees the existing rootkey as valid, you are good to go.


AH HA!


KDS root keys are stored in Active Directory in container CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=<forest name>;. They have an attribute msKds-DomainID that links to the computer account of the Domain Controller that created the object. When this domain controller is demoted and removed from the domain, the value will refer to the tombstone of the computer account. You can ignore the broken value as it is only used to help the administrator track the object when it's freshly created. You may also change the attribute value and point it to the computer object of another domain controller in your forest.

 So that's good to know ...

Aakash Shah

unread,
Apr 13, 2024, 5:30:57 PM4/13/24
to ntsys...@googlegroups.com

 

“What if I wanted it to run on say all my servers? (to query Windows Update history, as a specific and real life example)”

Just a thought:

Does a task like this need to run under a domain user/gMSA account? Is it perhaps writing its output to a share or something along those lines where a local account wouldn’t work? A suggestion would be to consider using the System account to run the scheduled task and this could potentially eliminate the need for a gMSA for this scenario. And if you need to write the output to a share for instance, you could set up the share with permissions such that Creator Owner is granted access to the resulting file only (so no other computer can view/edit it), and all Domain Computers are allowed to create/write files in it (or consider limiting the computer security group if needed).

 

With this approach, each computer’s System account would have a unique password vs a gMSA added to all of the computers would share the same password. gMSAs are definitely helpful, but it may be worth considering whether it is needed in this scenario. I had a similar situation years ago on all of the computers and I ended up transitioning from a domain user account to using the System account. To clarify a gMSA is still an excellent option when an account is needed.

 

-Aakash Shah

Reply all
Reply to author
Forward
0 new messages