Module Version: puppetlabs-scheduled_task from v2.2.0 to v3.0.0
Puppet Version: March 2021 releases: Puppet Agent 7.5.0, puppetserver 7.1.0
OS Name/Version: Client Windows Server 2019 Datacenter (version 1809, OS build 17763.1817), server Ubuntu 20.04.2 LTS
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".
This was the behavior prior to module's version 2.2.0, where if a username is provided, the task is set to LogonType:Password.
Since the enhancement intended to help sysadmins, pulled in as puppetlabs/puppetlabs-scheduled_task#150: When not setting a password, this is interpreted as "Run only when user is logged on". The Managed Service Account is never "logged on" so the task does not run on expected schedule.
PuppetX::PuppetLabs::ScheduledTask::Task should check if user string ends with a dollar sign character ($), in which case TASK_LOGON_TYPE::TASK_LOGON_PASSWORD should always be used regardless of whether the @task_password is set.
Not sure if a proper test case can be added on Should create a scheduled task without an AD domain configuration and a proper gMSA in place. Maybe a test case can be added where the task will be allowed to be created for a non-existent gMSA username, and will only fail to run later down the line.
If this is not a preferred direction, then the alternative is to implement a customizable logontype override parameter for which sysadmins with gMSAs can provide password. This does feel less intuitive/user-friendly however.