Autorisations système du proxy MSSQL requises pour exécuter les étapes PowerShell

J'ai commencé à poser cette question sur DBA StackExchange, mais j'ai décidé qu'il s'agirait probablement d'une question de type sécurité Windows Server.

SQL Server 2016 SP1 + CU sur Server 2012 R2.

J'essaie d'exécuter une étape PowerShell dans un travail d'agent SQL en utilisant un utilisateur proxy et je rencontre un problème avec SQL qui tente de faire le ménage avant d'exécuter du code.

Ainsi, l'utilisateur proxy est inclus dans le sous-système PowerShell de l'agent SQL. Je peux créer un exemple de travail en une seule étape, pour exécuter "Get-Date". Les erreurs de travail sur:

Executed as user: Domain\ProxyUser. A job step received an error at line 1 in a PowerShell script. The corresponding line is 'set-executionpolicy RemoteSigned -scope process -Force'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'Access denied   '.  Process Exit Code -1.  The step failed.

MachinePolicy, UserPolicy et LocalMachine sont tous définis sur RemoteSigned. Il ne s'agit donc pas d'un problème de portée et cela produirait de toute façon une erreur différente.

Si je mets l'utilisateur proxy dans les administrateurs locaux sur la machine, le problème disparaît et le script s'exécute normalement. Je vois cet accès dans les journaux de sécurité Windows sur le système:

Object:
    Object Server:  Security
    Object Type:    File
    Object Name:    \Device\ConDrv
    Object Handle:  0x4

Process Information:
    Process ID: 0x6350
    Process Name:   C:\Windows\System32\conhost.exe

Requested Operation:
    Desired Access: DELETE
            READ_CONTROL
            WRITE_DAC
            WRITE_OWNER
            SYNCHRONIZE
            ReadData (or ListDirectory)
            WriteData (or AddFile)
            AppendData (or AddSubdirectory or CreatePipeInstance)
            ReadEA
            WriteEA
            Execute/Traverse
            DeleteChild
            ReadAttributes
            WriteAttributes

Privileges:     SeTakeOwnershipPrivilege

Il semble que ce soit fondamentalement le même problème que celui de @MaddHatter il y a quatre ans:

Echec du travail Powershell de l'agent SQL avec un proxy non-administrateur

Est-ce que le seul choix est de mettre cet utilisateur dans les administrateurs locaux? Cela ressemble à une approche assez complexe du problème. Comment puis-je adapter au mieux les autorisations pour ces utilisateurs proxy afin que le travail puisse être exécuté?

windows-server-2012-r2 powershell sql-server-2016

— Drew Lanclos
source

Vous pouvez essayer de voir ce qui se passe avec le processus SQLAgent (ou peut-être powershell) à l'aide du Sysinternals Process Monitor:
https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
Avec cet outil, vous pourrez: voyez d'où vient l'accès refusé.

Une autre option consisterait à utiliser une étape "Système d'exploitation (CmdExec)" à la place de powershell et à appeler le script powershell de la manière suivante:

powershell.exe -File "C:\Path\To\File.ps"

— Taborda
source

Oui, l'option CmdExec existe, mais nous essayons vraiment de moderniser et d'améliorer nos systèmes de script existants. Auparavant, ces éléments étaient basés sur des tâches planifiées et sur un nombre impressionnant de fichiers de traitement par lots. Je vais voir ce que je peux glaner avec Process Monitor, merci pour le tuyau.

— Drew Lanclos

Mais si vous exécutez le script powershell à l'aide de CmdExec, cela fonctionne-t-il?

— taborda

Oui. Ce n'est pas un problème avec le script, mais un problème avec la façon dont SQL crée la session PowerShell. Si je retire cette partie de l'équation et demande simplement à SQL de me déposer un shell de commande que j'utilise ensuite pour amorcer PowerShell, le problème est en réalité évité.

— Drew Lanclos le