Uploaded image for project: 'Modules'
  1. Modules
  2. MODULES-10986

puppetlabs-scheduled_task : gMSAs unusable due to "Run only when user is logged on"

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: scheduled_task
    • Labels:
      None
    • Template:
      MODULES Bug Template
    • QA Risk Assessment:
      Needs Assessment

      Description

      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

      Desired Behavior:
      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.

      Actual Behavior:
      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.

          scheduled_task {'Example task':
            ensure        => present,
            command       => 'c:\\\\windows\\\\system32\\\\notepad.exe',
            arguments     => "foo bar baz",
            working_dir   => 'c:\\\\windows',
            user          => 'EXAMPLE\\svc-account$',
            trigger       => {
              schedule   => daily,
              start_time => '12:00',
            },
          }
      

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              sigv Valters Jansons
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Zendesk Support