xScheduledTask - missing option to configure tasks with gMSA accounts.

[bielawb]

At the moment there is no option to specify gMSA account as ExecuteAsCredential. Attempt to do that (by passing credential w/o password) will result in error:

The password supplied to the Desired State Configuration resource MSFT_xScheduledTask is not valid. The password cannot be null or empty.

Following instructions here it should be possible with the command used inside this resource:
https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/

The main difference I see is that this instructions suggest to use New-ScheduledTaskPrincipal and pass object created by it to -Principal parameter on Register-ScheduleTask command.

As this looks like a different code path from existing one I think it would be best to support it in separate parameter (mutually exclusive with ExecuteAsCredential), but would like to first verify this is not already planned to be addressed in a different manner.

As a result we can't use the resource to configure large portion of scheduled tasks that require gMSA account to run correctly.

[PlagueHO]

Hi @bielawb - I'm actually working on a change that might enable this as part of Issue 107. However, I've only managed to get my new integration tests (that cover these use cases) to pass using New-ScheduledTaskPrincipal on Windows Server 2016. There seems to be a behavior difference in Windows Server 2012 R2 that I need to resolve.

In short, once I complete the work to move code to use New-ScheduledTaskPrincipal then it should make this change fairly easy. I'll try and work on it over the weekend (unless someone wants to take a look before then (here is my inprogress code complete branch: https://github.com/PlagueHO/xComputerManagement/tree/Issue-107 - tests are failing on Window Server 2012R2 only).

[danielboth]

Hi @PlagueHO, is there any progress on this part? Looking at this, this should be rather easy to implement. A gMSA uses the LogonType Password, what we could do is check if the account provided in the ExecuteAsCredential is a gMSA account (ends with dollar sign). Next we can change the code here to not set the password for gMSA accounts:

https://github.com/PowerShell/ComputerManagementDsc/blob/550074c4b1515e822038c54710ee44c275f64adb/Modules/ComputerManagementDsc/DSCResources/MSFT_ScheduledTask/MSFT_ScheduledTask.psm1#L1207

The user of the ScheduledTask DSC resource can then leave the password empty in the ExecuteAsCredential (or set it to anything, since we will ignore it anyway).

Integration tests will be a bit more challenging for this I'm afraid. any ideas?

[PlagueHO]

Hi @danielboth - this does look like it'll work. But you're right, I don't think there is a way to integration test this because of a gMSA only working on a domain joined machine. I've never found a solution to this, so it is acceptable. If you're up for submitting a PR that would be awesome - I'm a bit snowed under at the moment and trying to get through my backlog of DSC Resource kit work 😁