Invoquer Remoting IPC Canal de Powershell Remoting session de

Question

je la configuration de l'environnement suivant:

1. machine "cible" avec mon service Windows fonctionnant sous "NT AUTHORITY \ SYSTEM". Ce service Windows dispose d'un port IPC sécurisé .NET Remoting ouvrir comme ceci:

   Dictionary<string, object> properties = new Dictionary<string, object>(); 
       properties["authorizedGroup"] = GetUsersGroupName(); // "S-1-5-32-545" SID, setting to "S-1-1-0" gives the same result 
       properties["name"] = configuration.ServiceShortName + ".Server"; 
       properties["portName"] = configuration.ServiceGuid; 
       BinaryServerFormatterSinkProvider sinkProvider = new BinaryServerFormatterSinkProvider(); 
       sinkProvider.TypeFilterLevel = TypeFilterLevel.Full; 
       Channel = new IpcServerChannel(properties, sinkProvider); 
       Channel.IsSecured = true; 
       ChannelServices.RegisterChannel(Channel, true); 
   

2. "appelant" la machine, qui à partir d'un compte de domaine authentifié (DOMAIN \ appelant) invoque à distance une locale (locale " cible "d'application) (laissez le nom de ce TargetApp) sur "Target" machine par Powershell Remoting (WS-management):

   $session = new-pssession -computerName "$targetHost" 
   Invoke-Command -Session $session -Args $application,$arguments -OutVariable output -scriptblock $scriptBlockRemote 
   Remove-PSSession $session 
   

3. le TargetApp qui est appelée localement sur la "machine cible"(en raison de la powershell Remoting appeler de « l'appelant ») doit faire un appel client IPC à serveur IPC sur la même machine « cible » (que serveur IPC fonctionne sous service Windows sur la même machine cible)

4. Toute tentative d'appeler le serveur IPC dans cette configuration finissent avec:

Impossible de se connecter à un port IPC: l'accès est refusé.

Observations:

1. Modification des propriétés [ "authorizedGroup"] pour "Tout le monde" ("S-1-1-0") lors de l'initialisation du canal serveur ne dit pas et je reçois la même erreur . La désactivation complète de la sécurité sur le canal du serveur donne le même résultat.

2. Lorsque "l'appelant" invoque une TargetApp sur la machine "Target" Je peux voir clairement que:

   • "C: \ Windows \ system32 \ wsmprovhost.exe -Embedding" processus est lancé sur la machine "cible" sous la rubrique « appelant » informations d'identification utilisateur (« DOMAIN \ appelant »)
   • wsmprovhost.exe sur « Target » invoque alors la TargetApp sous les informations d'identification de l'utilisateur « appelant » (« DOMAIN \ appelant »)
   • Lorsque l'application atteint le point d'appeler le serveur IPC, il ne

3. Essentiellement, je peux clairement voir que Powershell n'invoque la TargetApp locale sur la machine « cible » sous les informations d'identification attendues, mais pour une raison quelconque l'appel IPC échoue (bien que deux processus - l'TargetApp qui fait l'appel client IPC et le service de fenêtres maisons le serveur IPC - sont sur la même machine, l'appel IPC échoue)

4. Magiquement! Si je vais à « Target » machine directement, exécutez « cmd » sous DOMAIN \ les informations d'identification de compte appelant et invoquer la TargetApp de cette façon - l'appel IPC réussit!

J'ai essayé de trouver la solution, et il semble que plusieurs personnes ont été heurtaient dans le passé, mais aucune raison claire/cause/solution a été établie.

P.S. Après un peu de recherche, je soupçonne que cela est lié l'authentification, depuis Powershell Remoting utilise Kerberos par défaut, alors que le canal IPC fonctionne uniquement avec NTLM: https://msdn.microsoft.com/en-us/library/azure/ms172351(v=vs.85).aspx

Le canal IPC utilise toujours l'authentification NTLM. Kerberos n'est pas pris en charge car IPC est limité aux appels sur une seule machine.

Answer 1

Ainsi, le résultat de mon enquête est la suivante:

1. canal Remoting IPC .NET ne utilise NTLM, et rien d'autre
2. Dans le scénario décrit ci-dessus l'authentification est effectuée à l'aide Kerberos

La solution potentielle au scénario décrit serait d'utiliser Windows Task Scheduler pour planifier une exécution de tâche à distance.