Obecnie próbuję włączyć zdalne zarządzanie systemem Windows (w szczególności Powershell Remoting) między 2 niezaufanymi domenami i bez powodzenia.
Krótki opis mojej konfiguracji:
- domena1 - moja stacja robocza jest w tej domenie
- domena2 - serwer, z którym chcę się połączyć, znajduje się w tej domenie
Między tymi domenami nie ma zaufania.
Próbuję utworzyć zdalne połączenie Powershell przy użyciu następujących poleceń z mojej stacji roboczej (dołączonej do domeny1):
param (
[Parametr (obowiązkowe = $ prawda)]
$ serwer
)
$ nazwa użytkownika = „domena \ użytkownik”
$ password = read-host "Wprowadź hasło dla $ username" -AsSecureString
$ credential = New-Object System.Management.Automation.PSCredential ($ nazwa użytkownika, $ hasło)
$ session = New-PSSession "$ server" -Authentication CredSSP -Credential $ credential -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Sesja Enter-PSSession $
Co powoduje następujący komunikat o błędzie:
New-PSSession: [nazwa_komputera.domena2.com] Nawiązywanie połączenia ze zdalnym serwerem nazwa_komputera.domena2.com nie powiodło się z następującym komunikatem o błędzie: Klient WinRM
nie można przetworzyć żądania. Zasady komputera nie zezwalają na delegowanie poświadczeń użytkownika na komputer docelowy, ponieważ komputer nie jest zaufany. Tożsamość celu
komputer można zweryfikować, jeśli skonfigurujesz usługę WSMAN do używania ważnego certyfikatu za pomocą następującej komendy: winrm set winrm / config / service '@ {CertificateThumbprint = ""}' Lub
możesz sprawdzić Podgląd zdarzeń dla zdarzenia, które określa, że nie można utworzyć następującej nazwy SPN: WSMAN /. Jeśli znajdziesz to zdarzenie, możesz ręcznie utworzyć nazwę SPN za pomocą
setspn.exe. Jeśli nazwa SPN istnieje, ale CredSSP nie może używać protokołu Kerberos do sprawdzania tożsamości komputera docelowego, a nadal chcesz zezwolić na delegowanie poświadczeń użytkownika do obiektu docelowego
komputer, użyj gpedit.msc i spójrz na następujące zasady: Konfiguracja komputera -> Szablony administracyjne -> System -> Delegowanie poświadczeń -> Zezwól na nowe poświadczenia tylko z NTLM
Uwierzytelnianie serwera. Sprawdź, czy jest włączony i skonfigurowany z nazwą SPN odpowiednią dla komputera docelowego. Na przykład dla nazwy komputera docelowego „myserver.domain.com” może to być nazwa SPN
jeden z następujących: WSMAN / myserver.domain.com lub WSMAN / *. domain.com. Spróbuj ponownie po zgłoszeniu tych zmian. Więcej informacji można znaleźć w temacie pomocy about_Remote_Trou Rozwiązywanie problemów.
Próbowałem / zweryfikowałem następujące rzeczy:
- Sprawdziłem, czy istnieje nazwa SPN dla WSMAN \ nazwa_komputera i WSMAN \ nazwa_komputera.domena2.com w domenie2.
- Zweryfikowano, czy Konfiguracja komputera -> Szablony administracyjne -> System -> Delegowanie poświadczeń -> Zezwól na nowe poświadczenia za pomocą uwierzytelniania serwera tylko NTLM została poprawnie ustawiona.
- Skonfigurowano program winrm na komputerze docelowym do korzystania z protokołu ssl.
- Skonfigurowałem CredSSP na komputerze docelowym i mojej lokalnej stacji roboczej za pomocą następujących poleceń:
Enable-WSManCredSSP -Role Server # na komputerze docelowym Włącz-WSManCredSSP -Role Client -DelegateComputer * -Force
- Zweryfikowałem, że żadne reguły FW, lokalne dla komputerów w sieci lub w sieci, nie blokują mojego dostępu.
Żadne z nich nie pozwoliło mi pomyślnie połączyć się z komputerem docelowym w domenie2 z mojej stacji roboczej w domenie1. Mogę z powodzeniem łączyć się z innymi serwerami przyłączonymi do domeny 1, ale nie z serwerami w domenie 2. Czy jest jeszcze coś, czego powinienem szukać i / lub spróbować, aby to zadziałało?
AKTUALIZACJA 06/08/2015 W rzeczywistości byłem w stanie zweryfikować, czy mogę połączyć się z serwerem z mojej stacji roboczej bez użycia CredSSP, co byłoby w porządku; muszę jednak być w stanie uruchamiać skrypty przeciwko SharePoint, a robienie tego bez CredSSP kończy się niepowodzeniem z błędem uprawnień.
źródło
Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , punkt 3.)Odpowiedzi:
W tym artykule MSDN pokazano, jak skonfigurować WinRM do obsługi wielu przeskoków, który dotyczy również nawiązywania połączeń, gdy Kerberos nie jest opcją. Krótkie streszczenie poniżej.
W szczególności sekcja tego artykułu dotycząca wpisu rejestru / ustawienia zasad grupy AllowFreshCredentialsWhenNTLMOnly rozwiązała mój problem. Z artykułu:
źródło