Membuat lompatan kedua di Remoting PowerShell

  • Artikel

"Masalah hop kedua" mengacu pada situasi seperti berikut:

  1. Anda masuk 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 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

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}
}

Lihat juga

Pertimbangan Keamanan Jarak Jauh PowerShell