ADManagedServiceAccount: Add functionality to install and test MSAs, and manage group delegation on GMSAs.

[cnorling]

xADManagedServiceAccount: Add functionality to install and test MSAs, and manage group delegation on GMSAs.

Description

This is a feature set that warrants discussion over how we want the resource to act.

• MSAs
  • Do we want a parameter that installs the accounts on the node?
  • Do we want to run Test-ADServiceAccount to confirm the account is working?
• GMSAs
  • Do we want to have the resource provision AD groups, or do we want another DSC resource to create the group, then have the GMSA associate with that group?
  • Do we want to modify an AD group's membership with this DSC resource, or do we want another DSC resource to modify membership?
  • Do we want to run Test-ADServiceAccount to confirm the account is working?

[kungfoome]

xADManagedServiceAccount: Add functionality to install and test MSAs, and manage group delegation on GMSAs.

Description

This is a feature set that warrants discussion over how we want the resource to act.

• MSAs

  • Do we want a parameter that installs the accounts on the node? No, should be a new resource that installs the sMSA
  • Do we want to run Test-ADServiceAccount to confirm the account is working? In the new resource possibly, see below for further thoughts

• GMSAs

  • Do we want to have the resource provision AD groups, or do we want another DSC resource to create the group, then have the GMSA associate with that group? xADGroup can create the group, the resource MSA can already associate it with the members parameter
  • Do we want to modify an AD group's membership with this DSC resource, or do we want another DSC resource to modify membership? Same as above, xADGroup can do this
  • Do we want to run Test-ADServiceAccount to confirm the account is working? this could be a new resource combine with testing sMSA. I'll show example below

Further notes on test-adserviceacccount. Basically, this can be a false positive. For instance, a gMSA may have permissions, but you may need to reboot first. I feel like this would be better in a new resource and then you can do things like how WaitCluster kind of does it.

3 Resources total: xADManagedServiceAccounts xADInstallSingleManagedServiceAccount - Will install the service account on the node you run it on. This requires some complex logic because if a service account is already being used or other errors. xADWaitForServiceAccount, combine both sMSA and gMSA tests in there. Most likely, it's going to require a reboot of the machine.

If we think about worst case. Say we stand up brand new servers, new groups, new service accounts. We can easily do this soon.

xADComputer can create a disabled computer soon on creation (Important to note here)

1. Create AD Computer Object disable
2. Create AD Group
3. Add computer object or objects to newly created group
4. Create gMSA account and add the newly created group
5. Setup computer and join to domain

At this point it should have permissions to the service account.

Now what if we already have all that setup and we just want to now add a gMSA for it to use. Same process as before except we may need to restart the machine at this point before it can actually be used. So maybe you are installing something that requires a service account, but you don't want to proceed until you know it has permissions. This is where Waitforserviceaccount can come in.

[cnorling]

Same as above, xADGroup can do this

Sorry, I glazed over that functionality and ended up missing it.

xADWaitForServiceAccount, combine both sMSA and gMSA tests in there. Most likely, it's going to require a reboot of the machine.

I wasn't aware of any requirement for a node reboot for MSAs. Is it to clear the kerberos tickets? It sounds like you're pretty familiar with these optional features. Are you already working on a feature like this?

[cnorling]

On xADInstallSingleManagedServiceAccount I would worry about the MSA being installed on two different nodes. There should probably be some kind of check to make sure there's not already a valid computer DN in the hostcomputers attribute.

[kungfoome]

Same as above, xADGroup can do this

Sorry, I glazed over that functionality and ended up missing it.

xADWaitForServiceAccount, combine both sMSA and gMSA tests in there. Most likely, it's going to require a reboot of the machine.

I wasn't aware of any requirement for a node reboot for MSAs. Is it to clear the kerberos tickets? It sounds like you're pretty familiar with these optional features. Are you already working on a feature like this?

It's not heavily documented, but it does have to do with that i believe. If you set the gMSA and directly specify the node as a principal (member), then i believe it works ok, but if you put it in a group, you need to restart so it knows it's a member of that group. I'm not sure of a way around this, I would think there is a way, but i don't know what it would be. As far as install-adserviceaccount, I figured maybe it would do that for you, but it seems like install-adserviceaccount is a useless command for gMSAs. So if you were to do something like Get-ADPrincipalGroupMembership $node1 and that group is not there, the gMSA won't work.

On xADInstallSingleManagedServiceAccount I would worry about the MSA being installed on two different nodes. There should probably be some kind of check to make sure there's not already a valid computer DN in the hostcomputers attribute.

Correct. This is why i was saying it really should be a new resource because while it's somewhat simple, there is a lot of logic there and it's not exactly straightforward just because i don't think the commands throw an exception. So trying to catch those errors are difficult.

[indented-automation]

but it seems like install-adserviceaccount is a useless command for gMSAs

We had to install gMSAs before they could be used with our SQL deployments.

We also use groups to grant access, and therefore have to reboot to update kerberos tokens. For us these are all separate resources.

1. A resource to create the gMSA (runs against a DC).
2. A resource to wait for group membership and reboot (runs on the gMSA consumer).
3. Finally a resource to install it (using this https://github.com/indented-automation/Indented.SecurityPolicy/blob/master/Indented.SecurityPolicy/class/Dsc/GroupManagedServiceAccount.ps1). Separated because this is not an AD action, and having to install the AD tools to do it was frustrating.

[kungfoome]

@indented-automation

That's interesting. I've only had to restart, but it really doesn't hurt to run the install command for gMSAs. But agree with the way you have it setup with 3 resources.

That other good point you bring up is that you need domain tools installed. It would be nice to install it without having it installed.

[indented-automation]

Doing so needs a win32 function call (P/Invoke), specifically these three functions:

https://github.com/indented-automation/Indented.SecurityPolicy/blob/master/Indented.SecurityPolicy/class/SecurityPolicy/UnsafeNativeMethods.cs#L72-L92

It's not much code really. I just did it in a lot of layers. DSC resource to manage installation of the account relies on functions (Install/Uninstall/Test), that call corresponding C# methods which, finally, call the win32 functions.

[cnorling]

In my workplace, we clear the kerberos tickets with klist purge –li 0x3e7 and the GMSA works without a reboot.

@kungfu71186 to chime off of your process, we usually work with GMSAs like so

1. A group is created for the GMSA
2. The GMSA is created and associated with that group
3. The computer is added to the new GMSA group
4. Kerberos tickets are purged

After that, the GMSA is in a working state and tests positive! I've never had to run Install-ADServiceAccount to get a GMSA to work, but if we want to test GMSAs on target nodes, you'll need to install the RSAT AD tools anyways to get access to Test-ADServiceAccount

[kungfoome]

Makes sense. I was gonna say probably with klist. Bit never tried. Good to know. Something to consider adding in the resource.

Could possibly use klist or there is this https://gallery.technet.microsoft.com/scriptcenter/Keberos-Module-3a6ab12a

[cnorling]

One concern I have with xADWaitForServiceAccount being a separate DSC resource is if xADManagedServiceAccounts passes its tests and xADWaitForServiceAccount does not, you are limited with what xADWaitForServiceAccount can do to remediate the broken service account without stepping on the other resource's toes. If a GMSA fails Test-ADServiceAccount the following things could be wrong:

1. The computer may not be in the GMSA's group
2. The computer may not be in the GMSA's trustedfordelegation list (if 1 is not used)
3. The computer may not have a valid kerberos ticket to use the GMSA
4. The specified GMSA name is incorrect

With a separate resource, I cannot correct 1 or 2 on a failed test without stepping into another DSC resource's scope. This is assuming xADWaitForServiceAccount isn't meant to function like a canary.

[kungfoome]

I believe resources should stay in their lanes and do it well. If msa passes, then the state is correct. It's lane is simply adding a service account to AD, nothing else. If the computer isn't in the group, it's not any of these resources job to fix it, that's xadgroup or do it manually.

Meaning

1. Not a problem these resources should do, but it could possibly check why it's not passing and notify the user to fix it. For example, if the user adds it manually to a group and resets cache, waitfor will now continue.

2. You mean delegate or grab password? If delegate, then yes this is directly linked to gMSA and should be in the MSA resource. It's not full featured yet. If you mean retrieve password. Same as #1, even though it's possible to set those now.

3. This is what a new resource would help achieve. Mind you that you can create the service account on a domain controller or anything that has ad module install. Whereas, checking permissions or ability to use the account would probably happen on the node using it. Also a good reason to split the resource.

4. Really not the job of the resource as well. This is how the user configures their scripts. Probably should at least separate data and code and If you reference the same account using a variable, this wouldn't happen.

I would still say that these be separate resources, but it's a question of what to put in which resource. Like, if you wanted to try and fix the gMSA without rebooting, where would this go? Maybe another resource? Maybe in installMSA? Not sure.

[johlju]

Great discussions here, I label this as help wanted and resource proposal so that someone in the community can grab this a run with it! Looking forward to one or more PR's to start support this.

Wouldn't it be better to actually have the Install-resource both test and install to get the desired state? If the Test-function fail because the account is missing some prerequisites to function properly then the resource should not say the account is in desired state? 🤔 But even so a Wait-resource might be needed.

We should probably also name the install resource ADInstallManagedServiceAccount, if using the cmdlet Install-ADServiceAccount it looks like it caches gMSA. So it could be used for both types of managed service accounts.

[1800Zeta]

Just to add my 2 pennys worth to this. I do believe there are two aspects to this.

Create the GMSA, including Group with computer membership here. This should be contained within this AD module.

Install and use the module I think should be within the ComputerManagementDsc module. I don't think I've had to run the install cmdlet but I have done the reboot for refreshing the Kerberos ticket and group membership.

[CHDAFNI-MSFT]

@johlju - Is the ability to install a gMSA via DSC still outstanding?

[johlju]

Yes it is still outstanding. There has been no resource(s) added to this module for that purpose. The community need to send in a PR that add this.

[cnorling]

I'm sorry, I should have opened a pull request years ago for this content to be added in. I built it as I thought it should be and didn't think the powershell community would want it based on the feedback I got in this ticket. I'll fork the repo and open a pull request for the module to be added. I'll still need to write documentation content that covers how it works.

[goldenajj]

@cnorling - Will the PR happen any time soon? :)