Erreur PowerShell Remoting donnant "Accès refusé"
J'essaie d'utiliser PowerShell Remoting pour vérifier certaines tailles de disque à partir d'un serveur dans un domaine distant, mais les commandes que j'exécute ne fonctionnent pas.
La situation est la suivante:
- Le serveur source est dans le domaine A
- Le serveur de destination est dans le domaine B
- Il n'y a aucune confiance en place entre ces domaines
Le serveur du domaine B exécute Exchange 2010 et je peux exécuter des commandes spécifiques à Exchange 2010 à partir du serveur A à l'aide de cette commande:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri $ConnectionURI -Credential $Credentials -Authentication Basic
Import-PSSession $Session
Le problème est que je ne peux pas exécuter de commandes non Exchange sur ce serveur à l'aide de cette session, si j'essaye, il indique qu'il ne peut pas comprendre les commandes. J'ai vérifié et exécuté Get-Command avec Invoke-Command et la variable -Session définie sur ma session établie ne renvoie que des commandes Exchange.
J'ai donc pensé que j'essaierais d'utiliser Invoke-Command et le nom d'ordinateur, le type d'authentification et les informations d'identification appropriés, mais cela échoue:
Invoke-Command -ScriptBlock {Get-Service} -ComputerName "Servername.destination.com" -Credential $Credentials -Authentication "Basic"
Voici l'erreur:
[servername.destination.com] Connecting to remote server failed with the following error message : The WinRM client can
not process the request. The authentication mechanism requested by the client is not supported by the server or unencry
pted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configurat
ion or specify one of the authentication mechanisms supported by the server. To use Kerberos, specify the computer nam
e as the remote destination. Also verify that the client computer and the destination computer are joined to a domain.
To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name a
nd password. Possible authentication mechanisms reported by server: Negotiate Kerberos For more information, see th
e about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
Je vais donc dans la configuration WSMAN sur le serveur cible et définir les paramètres pertinents pour autoriser l'authentification de base et une connexion non cryptée:
cd WSMan:\localhost\Service
Set-Item AllowUnencrypted $True
cd .\Auth
Set-Item Basic $True
J'ai également ajouté le serveur de destination dans les hôtes approuvés du serveur de domaine source:
cd WSMan:\localhost\Client
Set-Item TrustedHosts servername.destination.com
Après cela, l'erreur change, mais ce n'est pas très utile:
PS WSMan:\localhost\Client> Invoke-Command -ScriptBlock {Get-Service} -ComputerName "servername.destination.com" -Creden
tial $Credentials -Authentication "Basic"
[servername.destination.com] Connecting to remote server failed with the following error message : Access is denied. Fo
r more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
J'ai également essayé d'utiliser les informations d'identification d'administrateur de domaine, via -Credential (Get-Credential), mais cela échoue avec le même problème.
L'utilisateur que j'essaie d'utiliser est un membre des administrateurs locaux sur le serveur en question, donc les autorisations doivent déjà être définies sur les conteneurs PSSessionConfiguration.
J'adorerais tout autre pointeur avec ça! Je voudrais simplement utiliser WMI, mais il n'est pas activé pour le moment via les pare-feu.
Eu des problèmes similaires récemment. Je vous suggère de vérifier soigneusement si l'utilisateur avec lequel vous vous connectez dispose des autorisations appropriées sur la machine distante.
Vous pouvez consulter les autorisations à l'aide de la commande suivante.
Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell
Trouvé cette astuce ici:
Il l'a corrigé pour moi.
L'exécution de la commande Prompt ou Powershell ISE en tant qu'administrateur a résolu ce problème pour moi.