web-dev-qa-db-fra.com

Erreur "Accès refusé" lors de la tentative de connexion à distance au serveur Exchange sur l'hôte local

J'essaie d'établir une session PowerShell pour exécuter plusieurs commandes Exchange sur un serveur Exchange sur l'hôte local. Je reçois toujours l'erreur suivante:

New-PSSession : [<HOSTNAME>] Connecting to remote server <HOSTNAME> failed with the following error message
: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:12
+ $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'h ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionOpenFailed

Mon code est un copier-coller de Microsoft article Technet . Cela fonctionne contre la machine distante, mais chaque fois que je cible la machine sur laquelle je cours, j'obtiens l'erreur ci-dessus.

Ce que j'ai essayé jusqu'à présent:

  1. Vérifié le about_remote_troubleshooting rubrique d'aide. Rien dans ce document concernant les erreurs d'accès refusé n'a fonctionné.
  2. Les ordinateurs distants ciblés utilisant les mêmes informations d'identification que celles qui ont reçu l'erreur Accès refusé. (Connecté sans problème)
  3. Vérifié que ma session PowerShell s'exécute en tant qu'administrateur. (Il est)
  4. Vérifié que Exchange Management Shell est capable de se lancer avec succès. (Il est)
  5. Essayé sans pouvoirs pour voir si cela fonctionnerait. (Ce n'est pas le cas)
  6. Vérifié Net Use et net session pour m'assurer que je n'avais pas de connexions multiples étranges avec le même problème d'informations d'identification. (Je n'ai rien vu pour indiquer cela)
  7. Je l'ai essayé à la fois à partir du script qui cause des problèmes et en tapant les commandes dans une console PowerShell à la main. (obtenu les mêmes résultats dans les deux sens. Oui pour la cohérence)
  8. J'ai essayé cela sur plusieurs systèmes. (Même résultat partout)

Quelques notes rapides:

  • Il s'agit d'Exchange 2013 exécuté sur Windows Server 2012. C'est une installation de base, juste un environnement de test qui a très peu de données et une configuration minimale au-delà de l'installation et de l'activation de l'accès à distance.
  • Les informations d'identification utilisées étaient pour l'administrateur du domaine, qui dispose également des autorisations Exchange nécessaires pour faire tout ce que je dois faire. C'est-à-dire que tant que je cible une machine qui n'est pas celle sur laquelle je cours, je n'ai aucun problème, avec rien d'autre qui change dans la façon dont je me connecte. De plus, il s'agit d'un domaine de test où l'accès de l'administrateur du domaine n'a pas été restreint ou modifié de quelque manière que ce soit, il devrait donc avoir un accès total et complet à tout.

Les commandes spécifiques que j'entre sont:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://<HOSTNAME>/Powershell' -Credential $cred

La connexion à l'hôte local comme celle-ci est-elle quelque chose que je devrais pouvoir faire? Ou n'est-il simplement pas pris en charge?

Je suis complètement perdu à ce stade. Toute aide, même pour me diriger dans la bonne direction, serait grandement appréciée.

EDIT: Je devrais ajouter, j'ai essayé de me connecter à cet hôte local à partir d'une autre machine, en utilisant les mêmes commandes que ci-dessus, et cela a fonctionné sans problème. Donc, je ne pense pas qu'il s'agit d'un problème de configuration local.

powershellwindows-server-2012access-deniedpowershell-remotingexchange-server-2013
8
Jgraum

Donc, je suis tombé sur la solution à la fin de la semaine dernière. Cela semble avoir quelque chose à voir avec l'authentification utilisée. J'avais laissé le paramètre "-Authentication" vide, dans l'intention de laisser la commande New-PSSession trier la méthode qui serait la meilleure.

Apparemment, cela revient par défaut à la méthode d'authentification "Négocier", qui sélectionnera Kerberos sur une machine distante, mais sélectionnera NTLM dans le cas contraire (ou du moins, c'était mon comportement observé/supposé). Voir cette description Microsoft des méthodes d'authentification.

La spécification d'une méthode d'authentification spécifique ("Kerberos" et "Basic" ont fonctionné, "Negotiate" n'a pas fonctionné, je n'ai pas trop bricolé) résout le problème et m'a permis de me connecter à l'instance d'échange locale.

Donc, plutôt que cela:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://<HOSTNAME>/Powershell' -Credential $cred

Faites ceci:

$session = New-PSSession -Authentication Kerberos -ConfigurationName Microsoft.Exchange -ConnectionUri 'http://<HOSTNAME>/Powershell'  -Credential $cred

Pourquoi cela a-t-il fonctionné? Je n'ai aucune idée. Je laisse le soin aux personnes qui en savent plus que moi de l'expliquer.

1
Jgraum

Si vous essayez simplement de créer une session sur le même ordinateur que votre session actuelle, omettez l'URI.

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Credential $cred

Cela créera une nouvelle session sur l'hôte local à laquelle vous pourrez vous connecter et utiliser selon vos besoins.

0
TheMadTechnician