Manajemen Jarak Jauh Windows Atas Domain yang Tidak Dipercaya


12

Saat ini saya mencoba untuk mengaktifkan Windows Remote Management (khususnya, Powershell Remoting) antara 2 domain yang tidak dipercaya, dan tidak berhasil.

Deskripsi singkat tentang pengaturan saya:

  • domain1 - workstation saya ada di domain ini
  • domain2 - server yang saya ingin hubungkan ada di domain ini

Tidak ada kepercayaan di antara domain-domain ini.

Saya mencoba membuat koneksi jarak jauh Powershell menggunakan perintah berikut dari workstation saya (bergabung dengan domain1):

param (
    [Parameter (Wajib = $ Benar)]
    $ server
)

$ username = "domain \ user"
$ password = read-host "Masukkan Kata Sandi untuk $ username" -AsSecureString

$ credential = New-Object System.Management.Automation.PSCredential ($ username, $ password)

$ session = New-PSSession "$ server" -Authentication CredSSP -Credential $ credential -GunakanSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Masukkan sesi-PSSession $

Yang menghasilkan pesan kesalahan berikut:

New-PSSession: [computername.domain2.com] Menyambung ke server jarak jauh computername.domain2.com gagal dengan pesan kesalahan berikut: Klien WinRM
tidak dapat memproses permintaan. Kebijakan komputer tidak mengizinkan pendelegasian kredensial pengguna ke komputer target karena komputer tidak tepercaya. Identitas target
komputer dapat diverifikasi jika Anda mengonfigurasi layanan WSMAN untuk menggunakan sertifikat yang valid menggunakan perintah berikut: winrm atur winrm / config / service '@ {CertificateThumbprint = ""}' Atau
Anda dapat memeriksa Peraga Peristiwa untuk peristiwa yang menentukan bahwa SPN berikut tidak dapat dibuat: WSMAN /. Jika Anda menemukan acara ini, Anda dapat secara manual membuat SPN menggunakan
setspn.exe. Jika SPN ada, tetapi CredSSP tidak dapat menggunakan Kerberos untuk memvalidasi identitas komputer target dan Anda masih ingin mengizinkan pendelegasian kredensial pengguna ke target.
komputer, gunakan gpedit.msc dan lihat kebijakan berikut: Konfigurasi Komputer -> Template Administratif -> Sistem -> Delegasi Kredensial -> Izinkan Kredensial Segar dengan khusus NTLM.
Otentikasi Server. Verifikasi bahwa itu diaktifkan dan dikonfigurasi dengan SPN yang sesuai untuk komputer target. Misalnya, untuk nama komputer target "myserver.domain.com", SPN bisa
salah satu dari yang berikut: WSMAN / myserver.domain.com atau WSMAN / *. domain.com. Coba lagi permintaan setelah perubahan ini. Untuk informasi lebih lanjut, lihat topik help_Remote_Troubleshooting.

Saya sudah mencoba / memverifikasi hal-hal berikut:

  1. Saya memverifikasi bahwa SPN ada untuk WSMAN \ computername & WSMAN \ computername.domain2.com di domain2.
  2. Diverifikasi bahwa Konfigurasi Komputer -> Template Administratif -> Sistem -> Delegasi Kredensial -> Izinkan Kredensial Segar dengan Otentikasi Server khusus-NTLM telah diatur dengan benar.
  3. Winrm yang dikonfigurasi pada komputer target untuk menggunakan ssl.
  4. CredSSP yang dikonfigurasi pada komputer target dan stasiun kerja lokal saya menggunakan perintah berikut:
Enable-WSManCredSSP -Role Server #pada komputer target
Aktifkan-WSManCredSSP -Role Client -DelegateComputer * -Force
  1. Saya telah memverifikasi bahwa tidak ada aturan FW, baik lokal ke komputer atau jaringan memblokir akses saya.

Tidak ada yang memungkinkan saya untuk berhasil terhubung ke komputer target di domain2 dari workstation saya di domain1. Saya berhasil terhubung ke server lain yang bergabung dengan domain1, hanya saja bukan server di domain2. Apakah ada hal lain yang harus saya cari dan / atau coba agar ini berhasil?

UPDATE 06/08/2015 Sebenarnya saya telah dapat memverifikasi bahwa saya dapat terhubung ke server dari workstation saya tanpa menggunakan CredSSP, yang akan baik-baik saja; Namun, saya harus dapat menjalankan skrip terhadap SharePoint, dan melakukannya tanpa CredSSP gagal dengan kesalahan izin.


Sudahkah Anda mencoba lebih spesifik tentang tujuan pendelegasian kredensial Anda? Misalnya Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , poin 3.)
john


Sayangnya, tidak satu pun dari saran itu yang berhasil.
Nick DeMayo


1
Oooo! Saya menemukan jawabannya di artikel yang Anda tautkan juga. Saya telah mencoba dalam pengaturan sebelumnya "AllowFreshCredentialsDomain" untuk memiliki SPN, tetapi itu tidak berhasil. Ternyata, saya bisa mengatur "AllowFreshCredentialsWhenNTLMOnly" dan "AllowFreshCredentialsWhenNTLMOnlyDomain" dan berfungsi! user2320464, jika Anda bisa memposting komentar Anda sebagai jawaban, saya akan menerimanya dan Anda mendapatkan hadiahnya!
Nick DeMayo

Jawaban:


2

Ini MSDN Artikel menunjukkan bagaimana mengkonfigurasi WinRM untuk dukungan multi-hop yang juga alamat membuat koneksi saat Kerberos bukanlah suatu pilihan. Ringkasan singkat di bawah ini.

Manajemen Jarak Jauh Windows (WinRM) mendukung delegasi kredensial pengguna di beberapa komputer jarak jauh. Fungsionalitas dukungan multi-hop sekarang dapat menggunakan Credential Security Service Provider (CredSSP) untuk otentikasi. CredSSP memungkinkan aplikasi untuk mendelegasikan kredensial pengguna dari komputer klien ke server target.

Otentikasi CredSSP dimaksudkan untuk lingkungan di mana delegasi Kerberos tidak dapat digunakan. Dukungan untuk CredSSP ditambahkan untuk memungkinkan pengguna terhubung ke server jarak jauh dan memiliki kemampuan untuk mengakses mesin hop kedua, seperti berbagi file.

Secara khusus, bagian dalam artikel yang berkaitan dengan Entri Pendaftaran / Pengaturan Kebijakan Grup AllowFreshCredentialsWhenNTLMHanya menyelesaikan masalah yang saya alami. Dari artikel:

Jika otentikasi Kerberos atau cap jempol sertifikat tidak tersedia, pengguna dapat mengaktifkan otentikasi NTLM. Jika otentikasi NTLM digunakan, kebijakan Perbolehkan Kredensial Segar dengan Otentikasi Server khusus NTLM (AllowFreshCredentialsKetika NTLMHanya) harus diaktifkan, dan SPN dengan awalan WSMAN harus ditambahkan ke kebijakan. Pengaturan ini kurang aman dibandingkan otentikasi Kerberos dan cap jempol sertifikat, karena kredensial dikirim ke server yang tidak diautentikasi.

Untuk informasi lebih lanjut tentang AllowFreshCredentialsWhenNTLMHanya kebijakan, lihat deskripsi kebijakan yang disediakan oleh editor Kebijakan Grup dan KB 951608. Kebijakan AllowFreshCredentialsWhenNTLMHanya kebijakan terletak di jalur berikut: Konfigurasi Komputer \ Administratif Templat \ Sistem \ Delegasi Kredensial.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.