Runas any user even when shell is limited like winrm

[dwoz]

What does this PR do?

• Fix runas when running under winrm.
• Support for LOCAL SERVICE and NETWORK SERVICE system accounts.
• Runas can now use system accounts from salt-call.
  (SYSTEM, LOCAL SERVICE and NETWORK SERVICE)
• Runas can launch processes on behalf of users without a password.

What issues does this PR fix or reference?

• Some tests fail when run over winrm because of restrictions.

Tests written?

No

Commits signed with GPG?

Yes

[damon-atkins]

Seems like a good idea. Please use a class for constants like in modules/reg.py

[dwoz]

This should fix

#47621

[twangboy]

And here

[twangboy]

same here

[twangboy]

and here

[twangboy]

And these

[twangboy]

Shouldn't this be salt.winutil now?

[twangboy]

And here

[twangboy]

You get the idea...

[twangboy]

and here

[twangboy]

Can we remove these comments?
And the salt.winutil thing

[twangboy]

adapted

[damon-atkins]

Some random thoughts.
Not sure module salt.win is the correct place. Maybe salt.utils.platform.win.somthing (if you break the file up). Maybe along the lines of how powershell is broken up e.g. salt.utils.platform.win.credentials class. Or even salt.platform.win.*
Get-<Name Of Python Class> e.g. Get-Credentials
Get-Module -ListAvailable | Format-Table Name, Description

There are also a few win_*.py in salt.utils

For example we have salt.utils.pkg.win

What I would like to see is a

salt.platform.file.posix
salt.platform.file.posix.linux
salt.platform.file.posix.solaris
salt.platform.cred.win
salt.platform.cred.posix
salt.platform.cred.posix.linux
salt.platform.cred.posix.solaris
salt.platform.cred.win
salt.platform.cred.aws

With a platform independent set of high level class methods where possible, with specific platform overrides.

[dwoz]

@damon-atkins, thanks so much for reviewing this. :)

salt.win came from discussions with @twangboy. The main driver for salt.win is to have a place for Windows specific stuff. For now salt.win only contains things related to logon. The plan is to expand on this module to make salt.win.logon, salt.win.service, salt.win.registry ect. I did not put the module under salt.utils to avoid having the loader try to import platform specifics automatically. I think anything under salt.utils gets touched by the loader automatically (I could be wrong on this). I'm down with salt.utils.platform provided the loader plays nicely. If not, maybe salt.platform works as a namespace for these things. Maybe @s0undt3ch or @cachedout have some opinions?

[s0undt3ch]

Why warning?
Also, switch to log.warning, log.warn is deprecated in Py3.

[dwoz]

I agree warning is overkill. Should these 'logon user' log statements go away completely?

[s0undt3ch]

If you think these will make sense when trying to debug an issue, leave then, but perhaps, at debug log level? Info?

[dwoz]

Windows creates an event log for the logons so I've just removed these log statements.

[s0undt3ch]

If this is a utilities module it should be moved to salt.utils.

I've read this and it looks good so far as I can tell, but I simply don't know enough about the Windows ecosystem to be able to review this in any real depth.

[twangboy]

I'm getting the following error on Py3 when I do a cmd.run running as a normal (non-admin) user. I haven't tried with an admin user. Here's the command I ran and the result on both Py2 and Py3.

root@master:/srv/salt/test# salt -t 300 dev* cmd.run whoami runas=testuser01 password=PassWord1!
dev(py2):
    win-8fgt3e045se\testuser01
dev3(py3):
    The minion function caused an exception: Traceback (most recent call last):
      File "c:\dev\salt\salt\minion.py", line 1619, in _thread_return
        return_data = minion_instance.executors[fname](opts, data, func, args, kwargs)
      File "c:\dev\salt\salt\executors\direct_call.py", line 12, in execute
        return func(*args, **kwargs)
      File "c:\dev\salt\salt\modules\cmdmod.py", line 1161, in run
        **kwargs)
      File "c:\dev\salt\salt\modules\cmdmod.py", line 411, in _run
        return win_runas(cmd, runas, password, cwd)
      File "c:\dev\salt\salt\utils\win_runas.py", line 62, in runas
        privs=['SeTcbPrivilege'],
      File "c:\dev\salt\salt\platform\win.py", line 1125, in impersonate_sid
        raise WindowsError("Impersonation failure")  # pylint: disable=undefined-variable
    OSError: Impersonation failure
root@shanelee-master:/srv/salt/test#

[cachedout]

As I recall, password is only needed if it's under a non-admin account AND it's requesting priv escalation, right? If so, I think that should be called out specifically.

[dwoz]

@cachedout If the minion happens to be running under a non admin. They will need to use a password anytime the use the runas argument to cmd.run. Maybe this is better?

 A password is no longer required with ``runas`` under normal circumstances.
The password option is only needed if the minion process is run under a
restricted (non-administrator) account. In the aforementioned case, a password
is only required when using the ``runas`` argument to run command as a different 
user.

[cachedout]

Is the intention here just to pass groups? I'm wary of passing all kwargs unless that's truly needed.

[dwoz]

@cachedout Yes, this is to pass groups. I'll change it to be more specific.

[dwoz]

Actually, looking at this again. We are making the kwargs dictionary for the sole purpose of passing it to user.add. It is being used to pass timeout, groups, and password.

[rallytime]

@dwoz This has a merge conflict with the release notes. Can you fix that up?

[dwoz]

@rallytime fixed.