Windows-Remoteverwaltung über nicht vertrauenswürdige Domänen

12

Ich versuche derzeit, die Windows-Remoteverwaltung (insbesondere Powershell Remoting) zwischen zwei nicht vertrauenswürdigen Domänen zu aktivieren, und habe kein Glück.

Eine kurze Beschreibung meines Setups:

  • domain1 - meine Workstation befindet sich in dieser Domäne
  • domain2 - Der Server, zu dem ich eine Verbindung herstellen möchte, befindet sich in dieser Domäne

Es besteht kein Vertrauen zwischen diesen Domänen.

Ich versuche, die Powershell-Remoteverbindung mithilfe der folgenden Befehle von meiner Arbeitsstation (der Domäne1 beigetreten) zu erstellen:

param (
    [Parameter (Obligatorisch = $ True)]
    $ server
)

$ username = "Domäne \ Benutzer"
$ password = read-host "Passwort für $ username eingeben" -AsSecureString

$ credential = New-Object System.Management.Automation.PSCredential ($ Benutzername, $ Passwort)

$ session = New-PSSession "$ server" -Authentication CredSSP -Credential $ credential -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $ session

Was zu folgender Fehlermeldung führt:

New-PSSession: [computername.domain2.com] Die Verbindung zum Remoteserver computername.domain2.com ist mit der folgenden Fehlermeldung fehlgeschlagen: Der WinRM-Client
kann die Anfrage nicht bearbeiten. Eine Computerrichtlinie erlaubt keine Delegierung der Benutzeranmeldeinformationen an den Zielcomputer, da der Computer nicht vertrauenswürdig ist. Die Identität des Ziels
Der Computer kann überprüft werden, wenn Sie den WSMAN-Dienst mit dem folgenden Befehl für die Verwendung eines gültigen Zertifikats konfigurieren: winrm set winrm / config / service '@ {CertificateThumbprint = ""}'
Sie können die Ereignisanzeige auf ein Ereignis überprüfen, das angibt, dass der folgende SPN nicht erstellt werden konnte: WSMAN /. Wenn Sie dieses Ereignis finden, können Sie den SPN manuell mit erstellen
setspn.exe. Wenn der SPN vorhanden ist, CredSSP Kerberos jedoch nicht zum Überprüfen der Identität des Zielcomputers verwenden kann, möchten Sie dennoch die Delegierung der Benutzeranmeldeinformationen an das Ziel zulassen
Verwenden Sie gpedit.msc auf Ihrem Computer und lesen Sie die folgenden Richtlinien: Computerkonfiguration -> Administrative Vorlagen -> System -> Delegierung von Anmeldeinformationen -> Zulassen neuer Anmeldeinformationen nur mit NTLM
Serverauthentifizierung. Stellen Sie sicher, dass es mit einem für den Zielcomputer geeigneten SPN aktiviert und konfiguriert ist. Beispielsweise kann der SPN für einen Zielcomputernamen "myserver.domain.com" sein
Eine der folgenden Optionen: WSMAN / myserver.domain.com oder WSMAN / *. domain.com. Versuchen Sie die Anfrage nach diesen Änderungen erneut. Weitere Informationen finden Sie im Hilfethema about_Remote_Troubleshooter.

Ich habe folgende Dinge ausprobiert / verifiziert:

  1. Ich habe überprüft, ob ein SPN für WSMAN \ Computername und WSMAN \ Computername.domain2.com in Domäne2 vorhanden ist.
  2. Es wurde überprüft, ob Computerkonfiguration -> Administrative Vorlagen -> System -> Delegierung von Anmeldeinformationen -> Erlaube neue Anmeldeinformationen mit nur NTLM-Serverauthentifizierung richtig eingestellt wurde.
  3. WinRM auf dem Zielcomputer für die Verwendung von SSL konfiguriert.
  4. Konfiguriertes CredSSP auf dem Zielcomputer und meiner lokalen Workstation mit den folgenden Befehlen:
Enable-WSManCredSSP -Role Server # auf dem Zielcomputer
Enable-WSManCredSSP -Role Client -DelegateComputer * -Force
  1. Ich habe überprüft, dass keine FW-Regeln, weder lokal auf den Computern noch im Netzwerk, meinen Zugriff blockieren.

Keiner davon hat es mir ermöglicht, von meiner Arbeitsstation in Domäne1 aus eine erfolgreiche Verbindung zum Zielcomputer in Domäne2 herzustellen. Ich kann erfolgreich eine Verbindung zu anderen Servern herstellen, die zu Domäne1 gehören, nur nicht zu Servern in Domäne2. Gibt es noch etwas, wonach ich suchen und / oder versuchen sollte, dies zum Laufen zu bringen?

UPDATE 06/08/2015 Ich konnte tatsächlich überprüfen, ob ich von meiner Workstation aus eine Verbindung zum Server herstellen kann, ohne CredSSP zu verwenden, was in Ordnung wäre. Ich muss jedoch in der Lage sein, Skripts für SharePoint auszuführen, ohne dass CredSSP mit einem Berechtigungsfehler fehlschlägt.

Nick DeMayo
quelle
Haben Sie versucht, genauer zu bestimmen, an was Sie Ihre Anmeldeinformationen delegieren? Zum Beispiel Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , Punkt 3.)
John
Es gibt auch diese: serverfault.com/questions/277573/…
John
Leider hat keiner dieser Vorschläge funktioniert.
Nick DeMayo
1
Haben Sie dies überprüft msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx
user2320464
1
Oooo! Ich habe die Antwort in dem Artikel gefunden, den Sie auch verlinkt haben. Ich habe in der Vergangenheit versucht, "AllowFreshCredentialsDomain" als SPN festzulegen, aber das hat nicht funktioniert. Es stellte sich heraus, dass ich "AllowFreshCredentialsWhenNTLMOnly" und "AllowFreshCredentialsWhenNTLMOnlyDomain" setzen konnte und es funktioniert! user2320464, wenn du bitte deinen Kommentar als Antwort posten könntest, werde ich ihn annehmen und du bekommst das Kopfgeld!
Nick DeMayo

Antworten:

2

Dieser MSDN- Artikel beschreibt, wie Sie WinRM für die Multi-Hop-Unterstützung konfigurieren, die auch das Herstellen von Verbindungen behandelt, wenn Kerberos keine Option ist. Kurze Zusammenfassung unten.

Die Windows-Remoteverwaltung (WinRM) unterstützt die Delegierung von Benutzeranmeldeinformationen auf mehreren Remotecomputern. Die Multi-Hop-Support-Funktionalität kann jetzt Credential Security Service Provider (CredSSP) zur Authentifizierung verwenden. Mit CredSSP kann eine Anwendung die Anmeldeinformationen des Benutzers vom Client-Computer an den Zielserver delegieren.

Die CredSSP-Authentifizierung ist für Umgebungen vorgesehen, in denen die Kerberos-Delegierung nicht verwendet werden kann. Die Unterstützung für CredSSP wurde hinzugefügt, damit ein Benutzer eine Verbindung zu einem Remote-Server herstellen und auf einen Second-Hop-Computer wie eine Dateifreigabe zugreifen kann.

Insbesondere der Abschnitt im Artikel zum Registrierungseintrag / zur Gruppenrichtlinieneinstellung AllowFreshCredentialsWhenNTLMO löste das Problem, das ich hatte. Aus dem Artikel:

Wenn weder Kerberos-Authentifizierung noch Zertifikatfingerabdrücke verfügbar sind, kann der Benutzer die NTLM-Authentifizierung aktivieren. Wenn die NTLM-Authentifizierung verwendet wird, muss die Richtlinie "Frische Anmeldeinformationen nur mit NTLM-Serverauthentifizierung zulassen" (AllowFreshCredentialsWhenNTLMOnly) aktiviert und ein SPN mit dem WSMAN-Präfix zur Richtlinie hinzugefügt werden. Diese Einstellung ist weniger sicher als die Kerberos-Authentifizierung und die Fingerabdrücke von Zertifikaten, da Anmeldeinformationen an einen nicht authentifizierten Server gesendet werden.

Weitere Informationen zur AllowFreshCredentialsWhenNTLMOnly-Richtlinie finden Sie in der vom Gruppenrichtlinien-Editor und KB 951608 bereitgestellten Richtlinienbeschreibung. Die AllowFreshCredentialsWhenNTLMOnly-Richtlinie befindet sich im folgenden Pfad: Computerkonfiguration \ Administrative Vorlagen \ System \ Berechtigungsnachweisdelegierung.

user2320464
quelle