(MODULES-10986) Fix gMSA username support

[sigv]

Since the enhancement intended to help sysadmins, pulled in as #150: When not setting a password, this is interpreted as "Run only when user is logged on".

When configuring a scheduled task to use a Group Managed Service Account (gMSA) principal, there is no password to provide. The scheduler will get the password automatically when properly configured, and should be able to run the task even though the service account is not "logged on". Otherwise, the Managed Service Account is never "logged on" so the task does not run on expected schedule.

It does not seem viable to add a proper test case for this particular situation without an AD domain configuration and a proper gMSA in place. Without a correct gMSA, an error message stating "No mapping between account names and security IDs was done" appears to be returned.

[puppet-community-rangefinder]

scheduled_task is a type

Breaking changes to this file MAY impact these 10 modules (near match):

• jpi-updatereporting_win
• mikemurray86-vss
• reidmv-puppet_run_scheduler
• tedivm-hieratic
• tkishel-unlock_puppet
• tkishel-puppet_device
• puppetlabs-device_manager
• pltraining-win_essentials
• albatrossflavour-os_patching
• choria-mcollective

This module is declared in 0 of 576 indexed public Puppetfiles.

---

These results were generated with Rangefinder, a tool that helps predict the downstream impact of breaking changes to elements used in Puppet modules. You can run this on the command line to get a full report.

Exact matches are those that we can positively identify via namespace and the declaring modules' metadata. Non-namespaced items, such as Puppet 3.x functions, will always be reported as near matches only.

[daianamezdrea]

Hi @sigv, thank you for submitting this PR, I'm trying now to test it

[sigv]

For testing this, you would be expected to have a domain, as mentioned.
Add-KdsRootKey would be required for a forest that has not had Key Distribution Service (KDS) set up.

# Something like this will get the job done:
Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))

---

Then for setting up the Service Accounts you can use New-ADServiceAccount and Set-ADServiceAccount:

New-ADServiceAccount -Name svc_account -Enable $True -DNSHostName svc_account.example.com
Set-ADServiceAccount -Identity svc_account  -PrincipalsAllowedToRetrieveManagedPassword 'Some Server Group'

---

New-ADServiceAccount could be used with the -RestrictToSingleComputer flag to target the Service Account for a particular domain computer instead, followed by Add-ADComputerServiceAccount (instead of the Set-ADServiceAccount seen above).

---

For the resource itself, you can then use something along the lines of:

  scheduled_task { 'Test scheduler':
    command       => 'C:\\Windows\\System32\\test.exe',
    working_dir   => 'C:\\Windows\\System32',
    user          => 'EXAMPLE\\svc_account$',
    compatibility => 3,
    enabled       => 'true',
    trigger       => [{
      schedule   => 'daily',
      start_time => '05:00'
    }],
  }

[daianamezdrea]

Hi @sigv, thank you for providing me all the information, I was able to set up my environment and the AD domain, let me try and add Add-KdsRootKey and set up the Service Accounts, thank you for all your help!

[sigv]

@daianamezdrea, any luck? 🤞🏻

[JohnEricson]

I can confirm that this pull request solved the problem for me on version 3.0.0 of the module.

First of all the modules documentation wasn't clear that you needed to not use the password attribute when using a group managed service account (gMSA), I figured this out from seeing @sigv example. Before this I added a blank password just like you do to the built-in Windows command schtasks.exe /Change /TN "Test scheduler" /RU EXAMPLE\svc_account$ /RP. My suggestion would be to improve the module documentation about this.

Before applying this pull request the module sets the scheduled task to "Run only when user is logged on":

And this doesn't work on a gMSA's as shown in the History of the scheduled task:

But by applying @sigv fix it solved my problem by setting the task correctly to "Run whether user is logged on or not". So I would like to see this pull request implemented in a new release of the module as well.

[DavidS]

@sigv @JohnEricson thank you both for your time and work. The fix will be released on the next community day (Monday).