Bagikan melalui

Melakukan langkah kedua dalam Remoting PowerShell

"Masalah hop kedua" mengacu pada situasi seperti berikut:

  1. Anda sudah terhubung ke ServerA.
  2. Dari ServerA, Anda memulai sesi PowerShell jarak jauh untuk menyambungkan ke ServerB.
  3. Perintah yang Anda jalankan di ServerB melalui sesi Jarak Jauh PowerShell Anda mencoba mengakses sumber daya di ServerC.
  4. Akses ke sumber daya di ServerC ditolak, karena kredensial yang Anda gunakan untuk membuat sesi Jarak Jauh PowerShell tidak diteruskan dari ServerB ke ServerC.

Ada beberapa cara untuk mengatasi masalah ini. Tabel berikut mencantumkan metode dalam urutan preferensi.

Konfigurasi Nota
CredSSP Menyeimbangkan kemudahan penggunaan dan keamanan
Delegasi yang dibatasi Kerberos berbasis sumber daya Keamanan yang lebih tinggi dengan konfigurasi yang lebih sederhana
Delegasi Terbatas Kerberos Keamanan tinggi tetapi memerlukan Administrator Domain
Delegasi Kerberos (tidak dibatasi) Tidak disarankan
Just Enough Administration (JEA) Dapat memberikan keamanan terbaik tetapi memerlukan konfigurasi yang lebih rinci
PSSessionConfiguration menggunakan RunAs Lebih mudah dikonfigurasi tetapi memerlukan manajemen kredensial
Teruskan data kredensial di dalam blok skrip Invoke-Command Paling mudah digunakan tetapi Anda harus memberikan kredensial

CredSSP

Anda dapat menggunakan Penyedia Dukungan Keamanan Kredensial (CredSSP) untuk autentikasi. CredSSP menyimpan kredensial di server jarak jauh (ServerB), sehingga menggunakannya membuat Anda rentan terhadap serangan pencurian kredensial. Jika komputer jarak jauh disusupi, penyerang memiliki akses ke info masuk pengguna. CredSSP dinonaktifkan secara default pada komputer klien dan server. Anda harus mengaktifkan CredSSP hanya di lingkungan yang paling tepercaya. Misalnya, administrator domain yang tersambung ke pengendali domain karena pengontrol domain sangat tepercaya.

Untuk informasi selengkapnya tentang masalah keamanan saat menggunakan CredSSP untuk PowerShell Remoting, lihat Sabotase Tidak Disengaja: Waspadai CredSSP.

Untuk informasi selengkapnya tentang serangan pencurian kredensial, lihat Mitigasi Serangan Pass-the-Hash (PtH) dan Pencurian Kredensial Lainnya.

Untuk contoh cara mengaktifkan dan menggunakan CredSSP untuk PowerShell remoting, lihat Mengaktifkan Fungsionalitas "Second-Hop" PowerShell dengan CredSSP.

Kelebihan

  • Ini berfungsi untuk semua server dengan Windows Server 2008 atau yang lebih baru.

Kekurangan

  • Memiliki kerentanan keamanan.
  • Memerlukan konfigurasi peran klien dan server.
  • tidak berfungsi dengan grup Pengguna Terproteksi. Untuk informasi selengkapnya, lihat Grup Keamanan Pengguna Terlindungi.

Delegasi Terbatas Kerberos

Anda dapat menggunakan delegasi warisan yang dibatasi (bukan berbasis sumber daya) untuk membuat hop kedua. Konfigurasikan delegasi yang dibatasi Kerberos dengan opsi "Gunakan protokol autentikasi apa pun" untuk memungkinkan transisi protokol.

Kelebihan

  • Tidak memerlukan pengkodean khusus
  • Kredensial tidak disimpan.

Kekurangan

  • Tidak mendukung loncatan kedua untuk WinRM.
  • Memerlukan akses Administrator Domain untuk dikonfigurasi.
  • Harus dikonfigurasi pada objek Direktori Aktif server jarak jauh (ServerB).
  • Terbatas pada satu domain. Tidak dapat melintasi domain atau forest.
  • Memerlukan hak untuk memperbarui objek dan Nama Perwakilan Layanan (SPN).
  • ServerB dapat memperoleh tiket Kerberos ke ServerC atas nama pengguna tanpa intervensi pengguna.

Nota

Akun Direktori Aktif yang memiliki Akun sensitif dan tidak dapat didelegasikan kumpulan properti tidak dapat didelegasikan. Untuk informasi selengkapnya, lihat Fokus Keamanan: Menganalisis 'Akun sensitif dan tidak dapat didelegasikan' untuk Akun Istimewa dan Alat dan Pengaturan Autentikasi Kerberos.

Delegasi yang dibatasi Kerberos berbasis sumber daya

Menggunakan delegasi yang dibatasi Kerberos berbasis sumber daya (diperkenalkan di Windows Server 2012), Anda mengonfigurasi delegasi kredensial pada objek server tempat sumber daya berada. Dalam skenario hop kedua yang dijelaskan di atas, Anda mengonfigurasi ServerC untuk menentukan dari mana ia menerima kredensial yang didelegasikan.

Kelebihan

  • Kredensial tidak disimpan.
  • Dikonfigurasi menggunakan cmdlet PowerShell. Tidak diperlukan pengkodean khusus.
  • Tidak memerlukan akses Administrator Domain untuk dikonfigurasi.
  • Bekerja di seluruh domain dan forest (hutan).

Kekurangan

  • Memerlukan Windows Server 2012 atau yang lebih baru.
  • Tidak mendukung loncatan kedua untuk WinRM.
  • Memerlukan hak untuk memperbarui objek dan Nama Perwakilan Layanan (SPN).

Nota

Akun Direktori Aktif yang memiliki Akun sensitif dan tidak dapat didelegasikan kumpulan properti tidak dapat didelegasikan. Untuk informasi selengkapnya, lihat Fokus Keamanan: Menganalisis 'Akun sensitif dan tidak dapat didelegasikan' untuk Akun Istimewa dan Alat dan Pengaturan Autentikasi Kerberos.

Contoh

Mari kita lihat contoh PowerShell yang mengonfigurasi delegasi berbasis sumber daya yang dibatasi pada ServerC untuk menerima kredensial yang didelegasikan dari ServerB. Contoh ini mengasumsikan bahwa semua server menjalankan versi Windows Server yang didukung, dan setidaknya ada satu pengontrol domain Windows untuk setiap domain tepercaya.

Sebelum dapat mengonfigurasi delegasi yang dibatasi, Anda harus menambahkan fitur RSAT-AD-PowerShell untuk menginstal modul PowerShell Direktori Aktif, lalu mengimpor modul tersebut ke sesi Anda:

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory
Get-Command -ParameterName PrincipalsAllowedToDelegateToAccount

Beberapa cmdlet yang sekarang tersedia memiliki parameter PrincipalsAllowedToDelegateToAccount:

CommandType Name                 ModuleName
----------- ----                 ----------
Cmdlet      New-ADComputer       ActiveDirectory
Cmdlet      New-ADServiceAccount ActiveDirectory
Cmdlet      New-ADUser           ActiveDirectory
Cmdlet      Set-ADComputer       ActiveDirectory
Cmdlet      Set-ADServiceAccount ActiveDirectory
Cmdlet      Set-ADUser           ActiveDirectory

Parameter PrincipalsAllowedToDelegateToAccount mengatur atribut objek Active Directory msDS-AllowedToActOnBehalfOfOtherIdentity, yang berisi daftar kontrol akses (ACL) yang menentukan akun-akun mana saja yang memiliki izin untuk mendelegasikan kredensial ke akun terkait (dalam contoh kami, ini akan menjadi akun komputer untuk ServerA).

Sekarang mari kita siapkan variabel yang akan kita gunakan untuk mewakili server:

# Set up variables for reuse
$ServerA = $Env:COMPUTERNAME
$ServerB = Get-ADComputer -Identity ServerB
$ServerC = Get-ADComputer -Identity ServerC

WinRM (dan oleh karena itu pengelolaan jarak jauh PowerShell) berjalan menggunakan akun komputer secara default. Anda dapat melihat ini dengan melihat properti StartName layanan winrm:

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName

StartName
---------
NT AUTHORITY\NetworkService

Untuk memungkinkan ServerC melaksanakan delegasi dari sesi remoting PowerShell di ServerB, kita harus mengatur parameter PrincipalsAllowedToDelegateToAccount pada ServerC ke objek komputer dari ServerB.

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

# Check the value of the attribute directly
$x = Get-ADComputer -Identity $ServerC -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
$x.'msDS-AllowedToActOnBehalfOfOtherIdentity'.Access

# Check the value of the attribute indirectly
Get-ADComputer -Identity $ServerC -Properties PrincipalsAllowedToDelegateToAccount

Kerberos Key Distribution Center (KDC) menyimpan cache upaya akses yang ditolak (cache negatif) selama 15 menit. Jika ServerB sebelumnya mencoba mengakses ServerC, Anda perlu menghapus cache di ServerB dengan memanggil perintah berikut:

Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    klist purge -li 0x3e7
}

Anda juga dapat menghidupkan ulang komputer, atau menunggu setidaknya 15 menit untuk menghapus cache.

Setelah menghapus cache, Anda dapat berhasil menjalankan kode dari ServerA melalui ServerB ke ServerC:

# Capture a credential
$cred = Get-Credential Contoso\Alice

# Test kerberos double hop
Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    Test-Path \\$($Using:ServerC.Name)\C$
    Get-Process lsass -ComputerName $($Using:ServerC.Name)
    Get-EventLog -LogName System -Newest 3 -ComputerName $($Using:ServerC.Name)
}

Dalam contoh ini, pengubah cakupan Using: digunakan untuk membuat variabel $ServerC terlihat oleh ServerB. Untuk selengkapnya mengenai pengubah cakupan Using:, lihat about_Remote_Variables.

Untuk mengizinkan beberapa server mendelegasikan kredensial ke ServerC, atur nilai parameter PrincipalsAllowedToDelegateToAccount pada ServerC menjadi sebuah array:

# Set up variables for each server
$ServerB1 = Get-ADComputer -Identity ServerB1
$ServerB2 = Get-ADComputer -Identity ServerB2
$ServerB3 = Get-ADComputer -Identity ServerB3
$ServerC  = Get-ADComputer -Identity ServerC

$servers = @(
    $ServerB1,
    $ServerB2,
    $ServerB3
)

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $servers

Jika Anda ingin membuat lompatan kedua di seluruh domain, gunakan parameter Server untuk menentukan nama domain yang sepenuhnya memenuhi syarat (FQDN) pengendali domain domain tempat ServerB berada:

# For ServerC in Contoso domain and ServerB in other domain
$ServerB = Get-ADComputer -Identity ServerB -Server dc1.alpineskihouse.com
$ServerC = Get-ADComputer -Identity ServerC
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

Untuk menghapus kemampuan untuk mendelegasikan kredensial ke ServerC, atur nilai parameter PrincipalsAllowedToDelegateToAccount pada ServerC ke $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Informasi tentang delegasi Kerberos terbatas berbasis sumber daya

Delegasi Kerberos (tidak dibatasi)

Anda juga dapat menggunakan delegasi Kerberos tanpa batasan untuk membuat lompatan kedua. Seperti semua skenario Kerberos, kredensial tidak disimpan. Metode ini tidak mendukung hop kedua untuk WinRM.

Peringatan

Metode ini tidak memberikan kontrol di mana kredensial yang didelegasikan digunakan. Ini kurang aman daripada CredSSP. Metode ini hanya boleh digunakan untuk skenario pengujian.

Just Enough Administration (JEA)

JEA memungkinkan Anda membatasi perintah apa yang dapat dijalankan administrator selama sesi PowerShell. Ini dapat digunakan untuk menyelesaikan masalah hop kedua.

Untuk informasi tentang JEA, lihat Just Enough Administration.

Kelebihan

  • Tidak ada pemeliharaan kata sandi saat menggunakan akun virtual.

Kekurangan

  • Memerlukan WMF 5.0 atau yang lebih baru.
  • Memerlukan konfigurasi pada setiap server perantara (ServerB).

PSSessionConfiguration menggunakan RunAs

Anda dapat membuat konfigurasi sesi di ServerB dan mengatur parameter RunAsCredential.

Untuk informasi tentang menggunakan PSSessionConfiguration dan RunAs untuk memecahkan masalah hop kedua, lihat solusi lain untuk jarak jauh PowerShell multi-hop.

Kelebihan

  • Bekerja dengan server apa pun dengan WMF 3.0 atau yang lebih baru.

Kekurangan

  • Memerlukan konfigurasi PSSessionConfiguration dan RunAs di setiap server perantara (ServerB).
  • Memerlukan pemeliharaan kata sandi ketika menggunakan akun RunAs pada domain

Mengirim kredensial di dalam blok skrip Invoke-Command

Anda dapat meneruskan kredensial di dalam parameter ScriptBlock dari panggilan ke cmdlet Invoke-Command.

Kelebihan

  • Tidak memerlukan konfigurasi server khusus.
  • Bekerja pada server apa pun yang menjalankan WMF 2.0 atau yang lebih baru.

Kekurangan

  • Membutuhkan teknik kode canggung.
  • Jika menjalankan WMF 2.0, memerlukan sintaks yang berbeda untuk meneruskan argumen ke sesi jarak jauh.

Contoh

Contoh berikut menunjukkan cara mengirimkan kredensial di dalam blok skrip.

# This works without delegation, passing fresh creds
# Note $Using:Cred in nested request
$cred = Get-Credential Contoso\Administrator
Invoke-Command -ComputerName ServerB -Credential $cred -ScriptBlock {
    hostname
    Invoke-Command -ComputerName ServerC -Credential $Using:cred -ScriptBlock {hostname}
}

Lihat juga

Pertimbangan Keamanan Pengendalian Jarak Jauh PowerShell

  • Last updated on