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??
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.
|
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/LV8PR13MB6621FD82B68DA1FE369A63A2C5042%40LV8PR13MB6621.namprd13.prod.outlook.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.
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.
“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
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2Big%3Dxbuzj8on%2BxQ97-d28E0TVPoLFsNcumNHZ4Tc_JeEA%40mail.gmail.com.