[Bug]: win_task / task.present: gMSA account is registered with InteractiveToken instead of Password

Start with salt/modules/win_task.py, focusing on edit_task and the equivalent account logon selection in create_task_from_xml; read how each chooses the principal logon type when no password is supplied. Check the task module’s tests for coverage of task registration. Done when both paths register a gMSA task with TASK_LOGON_PASSWORD without requiring a dummy password, while preserving behavior for other accounts.

What happened?

win_task / task.present: gMSA account is registered with InteractiveToken instead of Password

Description

task.create_task (and the task.present state built on top of it) cannot create a scheduled task that runs under a group Managed Service Account (gMSA) the same way Task Scheduler does when the task is created by hand or imported from XML.

A gMSA has no password that can be passed in (its password is managed by Active Directory). When user_name is a gMSA (e.g. DOMAIN\msa-test$) and password is not set, edit_task and create_task_from_xml choose TASK_LOGON_INTERACTIVE_TOKEN. The resulting task is "Run only when user is logged on", so it does not run when nobody is logged on to the server.

The same logic forces Principal.RunLevel = TASK_RUNLEVEL_HIGHEST for every non-SYSTEM account, so "Run with highest privileges" is always enabled and cannot be turned off. This is reported separately below.

Setup

State:

PRN_DeleteOldPrintJobs:
  task.present:
    - name: 'PRN_DeleteOldPrintJobs'
    - user_name: 'DOMAIN\msa-test$'     # gMSA
    - force: True
    - action_type: 'Execute'
    - cmd: 'powershell.exe'
    - arguments: '"C:\scripts\PRN_DeleteOldPrintJobs.ps1"'
    - trigger_type: 'Daily'
    - start_date: '2016-11-10'
    - start_time: '22:00:00'
    - days_interval: 1
    - execution_time_limit: '1 hour'
    - multiple_instances: 'No New Instance'

Steps to Reproduce

1. Create a gMSA and allow the minion host to retrieve its password.
2. Apply the state above (or call task.create_task with user_name='DOMAIN\msa-test$' and no password).
3. Open the task in Task Scheduler, tab General.

Expected behavior

The task is registered with LogonType=Password (same as a task created in the UI/XML for a gMSA): "Run whether user is logged on or not".

Actual behavior

• LogonType=InteractiveToken: "Run only when user is logged on".
• "Run with highest privileges" is checked.

Relevant code, salt/modules/win_task.py, edit_task:

            else:
                task_definition.Principal.Id = user_name
                if password:
                    logon_type = TASK_LOGON_PASSWORD
                else:
                    logon_type = TASK_LOGON_INTERACTIVE_TOKEN

            task_definition.Principal.UserID = user_name
            task_definition.Principal.DisplayName = user_name
            task_definition.Principal.LogonType = logon_type
            task_definition.Principal.RunLevel = TASK_RUNLEVEL_HIGHEST

and the equivalent block in create_task_from_xml.

Workaround

Passing a dummy password (password: ' ') makes if password: true and selects TASK_LOGON_PASSWORD, but this is a hack and still leaves RunLevel at HIGHEST.

Proposed fix

Treat account names ending with $ (gMSA / computer accounts) as password-managed accounts: use TASK_LOGON_PASSWORD and pass no password.

             else:
                 task_definition.Principal.Id = user_name
-                if password:
+                if user_name.endswith("$"):
+                    # gMSA: password is managed by AD
+                    logon_type = TASK_LOGON_PASSWORD
+                    password = None
+                elif password:
                     logon_type = TASK_LOGON_PASSWORD
                 else:
                     logon_type = TASK_LOGON_INTERACTIVE_TOKEN

Same change in create_task_from_xml. Possible alternative if a name-based check is not acceptable: expose explicit logon_type and run_level arguments in edit_task / task.present.

Related issues in the same module

• RunLevel is hard-coded to TASK_RUNLEVEL_HIGHEST for all non-SYSTEM users; there is no argument to use TASK_RUNLEVEL_LUA.
• create_task_from_xml: with xml_path, the code does xml_text = xml_path, so the path string is passed to RegisterTask instead of the file contents ("Need to figure out how to load contents of xml" comment).
• create_task ignores the return value of _save_task_definition; registration errors are only visible in the debug log and the function returns False.

Versions Report

salt 3007.14

Minion OS: Windows Server

Type of salt install

Official msi

Major version

3007.x

What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)

windows-2022

salt --versions-report output

Salt Version:
          Salt: 3007.14

Python Version:
        Python: 3.10.19 (heads/main:cdd8334, Feb 17 2026, 23:40:07) [MSC v.1944 64 bit (AMD64)]

Dependency Versions:
          cffi: 2.0.0
      cherrypy: unknown
  cryptography: 46.0.5
      dateutil: 2.8.2
     docker-py: Not Installed
         gitdb: 4.0.10
     gitpython: Not Installed
        Jinja2: 3.1.6
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.7
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 24.0
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.19.1
        pygit2: Not Installed
  python-gnupg: 0.5.2
        PyYAML: 6.0.1
         PyZMQ: 25.1.2
        relenv: 0.22.4
         smmap: 5.0.1
       timelib: 0.3.0
       Tornado: 6.5.5
           ZMQ: 4.3.4

Salt Package Information:
  Package Type: onedir

System Versions:
          dist:
        locale: utf-8
       machine: AMD64
       release: 2022Server
        system: Windows
       version: 2022Server 10.0.20348 SP0 Multiprocessor Free