Membuat lompatan kedua di Remoting PowerShell
"Masalah hop kedua" mengacu pada situasi seperti berikut:
- Anda masuk ke ServerA.
- Dari ServerA, Anda memulai sesi PowerShell jarak jauh untuk menyambungkan ke ServerB.
- Perintah yang Anda jalankan di ServerB melalui sesi Jarak Jauh PowerShell Anda mencoba mengakses sumber daya di ServerC.
- 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 | Catatan |
|---|---|
| CredSSP | Menyeimbangkan kemudahan penggunaan dan keamanan |
| Delegasi yang dibatasi Kerberos berbasis sumber daya | Keamanan yang lebih tinggi dengan konfigurasi yang lebih sederhana |
| Delegasi yang dibatasi Kerberos | Keamanan tinggi tetapi memerlukan Administrator Domain |
| Delegasi Kerberos (tidak dibatasi) | Tidak direkomendasikan |
| Just Enough Administration (JEA) | Dapat memberikan keamanan terbaik tetapi memerlukan konfigurasi yang lebih rinci |
| PSSessionConfiguration menggunakan RunAs | Lebih mudah dikonfigurasi tetapi memerlukan manajemen kredensial |
Meneruskan kredensial di dalam Invoke-Command blok skrip |
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), jadi menggunakannya akan membuka Anda hingga 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: Waspada terhadap 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 jarak jauh PowerShell, lihat Mengaktifkan Fungsionalitas "Second-Hop" PowerShell dengan CredSSP.
Pro
- Ini berfungsi untuk semua server dengan Windows Server 2008 atau yang lebih baru.
Kontra
- Memiliki kerentanan keamanan.
- Memerlukan konfigurasi peran klien dan server.
- tidak berfungsi dengan grup Pengguna Terproteksi. Untuk informasi selengkapnya, lihat Grup Keamanan Pengguna Terproteksi.
Delegasi yang dibatasi 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.
Pro
- Tidak memerlukan pengkodean khusus
- Kredensial tidak disimpan.
Kontra
- Tidak mendukung hop 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.
Catatan
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 Autentikasi Kerberos dan Pengaturan.
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.
Pro
- Kredensial tidak disimpan.
- Dikonfigurasi menggunakan cmdlet PowerShell. Tidak diperlukan pengkodean khusus.
- Tidak memerlukan akses Administrator Domain untuk dikonfigurasi.
- Bekerja di seluruh domain dan forest.
Kontra
- Memerlukan Windows Server 2012 atau yang lebih baru.
- Tidak mendukung hop kedua untuk WinRM.
- Memerlukan hak untuk memperbarui objek dan Nama Perwakilan Layanan (SPN).
Catatan
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 Autentikasi Kerberos dan Pengaturan.
Contoh
Mari kita lihat contoh PowerShell yang mengonfigurasi delegasi yang dibatasi berbasis sumber daya di ServerC untuk mengizinkan 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 RSAT-AD-PowerShell fitur 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 tersedia sekarang 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 Direktori Aktif msDS-AllowedToActOnBehalfOfOtherIdentity, yang berisi daftar kontrol akses (ACL) yang menentukan akun mana yang memiliki izin untuk mendelegasikan kredensial ke akun terkait (dalam contoh kami, itu 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 PowerShell jarak jauh) berjalan sebagai akun komputer secara default. Anda dapat melihat ini dengan melihat properti winrm StartName layanan:
Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName
StartName
---------
NT AUTHORITY\NetworkService
Agar ServerC mengizinkan delegasi dari sesi jarak jauh PowerShell di ServerB, kita harus mengatur parameter PrincipalsAllowedToDelegateToAccount di ServerC ke objek komputer 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
Cache Kerberos Key Distribution Center (KDC) menolak upaya akses (cache negatif) selama 15 menit. Jika ServerB sebelumnya telah 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, $using variabel digunakan untuk membuat $ServerC variabel terlihat oleh ServerB.
Untuk informasi selengkapnya tentang variabel, $using lihat about_Remote_Variables.
Untuk mengizinkan beberapa server mendelegasikan kredensial ke ServerC, atur nilai parameter PrincipalsAllowedToDelegateToAccount di ServerC ke 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) dari pengendali 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 di ServerC ke $null:
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null
Informasi tentang delegasi yang dibatasi Kerberos berbasis sumber daya
- Apa yang Baru dalam Autentikasi Kerberos
- Cara Windows Server 2012 Meringankan Rasa Sakit Delegasi yang Dibatasi Kerberos, Bagian 1
- Cara Windows Server 2012 Meringankan Rasa Sakit Delegasi yang Dibatasi Kerberos, Bagian 2
- Memahami Delegasi yang Dibatasi Kerberos untuk penyebaran proksi aplikasi Microsoft Entra dengan Autentikasi Windows Terintegrasi
- [Atribut Skema Direktori Aktif MS-ADA2 M2.210 Atribut msDS-AllowedToActOnBehalfOfOtherIdentity]MS-ADA2
- [Ekstensi Protokol MS-SFU Kerberos: Layanan untuk Pengguna dan Protokol Delegasi yang Dibatasi 1.3.2 S4U2proxy]MS-SFU
- Administrasi Jarak Jauh Tanpa Delegasi Yang Dibatasi Menggunakan PrincipalsAllowedToDelegateToAccount
Delegasi Kerberos (tidak dibatasi)
Anda juga dapat menggunakan delegasi kerberos yang tidak dibatasi 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 Administrasi Just Enough.
Pro
- Tidak ada pemeliharaan kata sandi saat menggunakan akun virtual.
Kontra
- 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-nya.
Untuk informasi tentang menggunakan PSSessionConfiguration dan RunAs untuk menyelesaikan masalah hop kedua, lihat Solusi lain untuk remoting PowerShell multi-hop.
Pro
- Bekerja dengan server apa pun dengan WMF 3.0 atau yang lebih baru.
Kontra
- Memerlukan konfigurasi PSSessionConfiguration dan RunAs di setiap server menengah (ServerB).
- Memerlukan pemeliharaan kata sandi saat menggunakan akun RunAs domain
Meneruskan kredensial di dalam blok skrip Invoke-Command
Anda dapat meneruskan kredensial di dalam parameter ScriptBlock panggilan ke cmdlet Invoke-Command .
Pro
- Tidak memerlukan konfigurasi server khusus.
- Bekerja pada server apa pun yang menjalankan WMF 2.0 atau yang lebih baru.
Kontra
- 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 meneruskan kredensial 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}
}
