Aracılığıyla paylaş

PowerShell Uzaktan İletişim’de ikinci atlamayı yapma

"İkinci atlama sorunu" aşağıdaki gibi bir durumu ifade eder:

  1. ServerA'de oturum açtınız.
  2. ServerA'dan, SunucuB'ye bağlanmak için uzak bir PowerShell oturumu başlatırsınız.
  3. PowerShell uzaktan iletişim oturumunuz aracılığıyla ServerB'de çalıştırdığınız bir komut, ServerC'de bir kaynağa erişmeye çalışır.
  4. powershell uzaktan iletişim oturumunu oluşturmak için kullandığınız kimlik bilgileri ServerB'den ServerC'a geçirilmediğinden, ServerC üzerindeki kaynağa erişim reddedildi.

Bu sorunu çözmenin birkaç yolu vardır. Aşağıdaki tabloda yöntemleri tercih sırasına göre listelemektedir.

Konfigürasyon Uyarı
CredSSP Kullanım kolaylığı ve güvenliği dengeler
Kaynak tabanlı Kerberos kısıtlanmış temsili Daha basit yapılandırma ile daha yüksek güvenlik
Kerberos kısıtlı yetki devri Yüksek güvenlik, ancak Etki Alanı Yöneticisi gerektirir
Kerberos temsilcisi (kısıtlanmamış) Önerilmez
Yeterli Yönetim (JEA) En iyi güvenliği sağlayabilir ancak daha ayrıntılı yapılandırma gerektirir
RunAs kullanarak PSSessionConfiguration Yapılandırılması daha kolay ama kimlik bilgisi yönetimi gerekiyor
Kimlik bilgilerini bir Invoke-Command betik bloğu içine geçirin Kullanımı en basit ama kimlik bilgilerini sağlamanız gerekir

CredSSP

Kimlik doğrulaması için Kimlik Bilgisi Güvenlik Destek Sağlayıcısı (CredSSP) kullanabilirsiniz. CredSSP, kimlik bilgilerini uzak sunucuda (ServerB) önbelleğe alır, bu nedenle bunu kullanmak kimlik bilgisi hırsızlığı saldırılarına kadar sizi açar. Uzak bilgisayarın güvenliği aşılırsa, saldırganın kullanıcının kimlik bilgilerine erişimi olur. CredSSP hem istemci hem de sunucu bilgisayarlarında varsayılan olarak devre dışıdır. CredSSP'yi yalnızca en güvenilir ortamlarda etkinleştirmeniz gerekir. Örneğin, bir etki alanı yöneticisi, son derece güvenilir olduğu için etki alanı denetleyicisine bağlanır.

PowerShell Uzaktan İletişimi için CredSSP kullanırken güvenlikle ilgili endişeler hakkında daha fazla bilgi için bkz. Yanlışlıkla Sabotaj: CredSSPdikkat edin.

Kimlik bilgisi hırsızlığı saldırıları hakkında daha fazla bilgi için bkz. Karma Geçiş (PtH) Saldırılarını Azaltma ve Diğer Kimlik Bilgisi Hırsızlığı.

PowerShell uzaktan iletişim için CredSSP'yi etkinleştirme ve kullanma örneği için bkz. CredSSP ile PowerShell "İkinci Atlama" İşlevini Etkinleştirme.

Avantajlar

  • Windows Server 2008 veya sonraki sürümleri olan tüm sunucularda çalışır.

Dezavantajlar

  • Güvenlik açıkları vardır.
  • hem istemci hem de sunucu rollerinin yapılandırılması gerekir.
  • Korumalı Kullanıcılar grubuyla çalışmaz. Daha fazla bilgi için bkz. Korumalı Kullanıcılar Güvenlik Grubu.

Kerberos kısıtlı yetki devri

İkinci adım için kaynak tabanlı olmayan geçmişten gelen kısıtlanmış yetkilendirmeyi kullanabilirsiniz. Protokol geçişine izin vermek için Kerberos kısıtlanmış temsilini "Herhangi bir kimlik doğrulama protokolü kullan" seçeneğiyle yapılandırın.

Avantajlar

  • Özel kodlama gerektirmez
  • Kimlik bilgileri depolanmaz.

Dezavantajlar

  • WinRM için ikinci atlama desteklenmez.
  • Yapılandırmak için Etki Alanı Yöneticisi erişimi gerektirir.
  • Uzak sunucunun Active Directory nesnesinde yapılandırılmalıdır (ServerB).
  • Tek bir etki alanıyla sınırlıdır. Etki alanları veya ormanlar çapraz olamaz.
  • Nesneleri ve Hizmet Asıl Adlarını (SPN) güncelleştirme hakları gerektirir.
  • ServerB, kullanıcı yerine kullanıcı müdahalesi olmadan ServerC için bir Kerberos bileti alabilir.

Uyarı

Hesabı olan Active Directory hesapları hassastır ve temsilci seçilemiyor özellik kümesi temsilci seçilemiyor. Daha fazla bilgi için bkz. Güvenlik Odağı: Özel Ayrıcalıklı Hesaplar için ‘Hesap hassastır ve yetki devri yapılamaz’ durumunun analizi ve Kerberos Kimlik Doğrulama Araçları ve Ayarları.

Kaynak tabanlı Kerberos kısıtlanmış temsili

Kaynak tabanlı Kerberos kısıtlanmış temsilini (Windows Server 2012'de kullanıma sunulmuştur) kullanarak, kaynakların bulunduğu sunucu nesnesinde kimlik bilgisi temsilcisini yapılandırabilirsiniz. Yukarıda açıklanan ikinci atlama senaryosunda, ServerC temsilci kimlik bilgilerini kabul ettiği yeri belirtecek şekilde yapılandıracaksınız.

Avantajlar

  • Kimlik bilgileri depolanmaz.
  • PowerShell cmdlet'leri kullanılarak yapılandırılır. Özel kodlama gerekmez.
  • Yapılandırmak için Etki Alanı Yöneticisi erişimi gerekmez.
  • Etki alanları ve ormanlar arasında çalışır.

Dezavantajlar

  • Windows Server 2012 veya üzerini gerektirir.
  • WinRM için ikinci atlama desteklenmez.
  • Nesneleri ve Hizmet Asıl Adlarını (SPN) güncelleştirme hakları gerektirir.

Uyarı

Hesabı olan Active Directory hesapları hassastır ve temsilci seçilemiyor özellik kümesi temsilci seçilemiyor. Daha fazla bilgi için bkz. Güvenlik Odağı: Özel Ayrıcalıklı Hesaplar için ‘Hesap hassastır ve yetki devri yapılamaz’ durumunun analizi ve Kerberos Kimlik Doğrulama Araçları ve Ayarları.

Örnek

ServerBüzerinden temsilci kimlik bilgilerine izin vermek için ServerC kaynak tabanlı kısıtlanmış temsili yapılandıran bir PowerShell örneğine bakalım. Bu örnekte, tüm sunucuların Windows Server'ın desteklenen sürümlerini çalıştırdığını ve her güvenilen etki alanı için en az bir Windows etki alanı denetleyicisi olduğunu varsayar.

Kısıtlanmış temsili yapılandırabilmeniz için önce Active Directory PowerShell modülünü yüklemek için RSAT-AD-PowerShell özelliğini eklemeniz ve ardından bu modülü oturumunuza aktarmanız gerekir:

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

Mevcut bazı cmdlet'ler artık PrincipalsAllowedToDelegateToAccount parametresini içermektedir.

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

PrincipalsAllowedToDelegateToAccount parametresi, Active Directory nesne özniteliği msDS-AllowedToActOnBehalfOfOtherIdentity'yi ayarlar. Bu öznitelik, hangi hesapların ilişkili hesaba kimlik bilgilerini devretme iznine sahip olduğunu (örneğimizde, ServerAiçin makine hesabı olacaktır) belirten bir erişim denetimi listesi (ACL) içerir.

Şimdi sunucuları temsil etmek için kullanacağımız değişkenleri ayarlayalım:

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

WinRM (ve dolayısıyla PowerShell uzaktan yönetimi) varsayılan olarak bilgisayar hesabı üzerinden çalışır. Bunu, hizmetinin winrm özelliğine bakarak görebilirsiniz:

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

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

ServerC, ServerBüzerinde bir PowerShell uzaktan iletişim oturumundan temsilci seçmeye izin vermek için, ServerC üzerinde PrincipalsAllowedToDelegateToAccount parametresini ServerBbilgisayar nesnesine ayarlamalıyız:

# 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 Anahtar Dağıtım Merkezi (KDC) 15 dakika boyunca reddedilen erişim denemelerini (negatif önbellek) önbelleğe alır. ServerB daha önce ServerCerişmeye çalıştıysa, aşağıdaki komutu çağırarak ServerB önbelleği temizlemeniz gerekir:

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

Ayrıca bilgisayarı yeniden başlatabilir veya önbelleği temizlemek için en az 15 dakika bekleyebilirsiniz.

Önbelleği temizledikten sonra, ServerAServerB ile ServerCarasında başarıyla kod çalıştırabilirsiniz:

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

Bu örnekte, Using: değişkenini $ServerCiçin görünür hale getirmek için kapsam değiştiricisi kullanılır. Using: kapsam değiştirici hakkında daha fazla bilgi için bkz. about_Remote_Variables.

Birden çok sunucunun ServerCkimlik bilgilerini devretmesine izin vermek için, ServerC'da PrincipalsAllowedToDelegateToAccount parametresinin değerini bir diziye ayarlayın:

# 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

etki alanları arasında ikinci atlama yapmak istiyorsanız, ServerB ait olduğu etki alanı denetleyicisinin tam etki alanı adını (FQDN) belirtmek için Server parametresini kullanın:

# 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

ServerC'ye kimlik bilgileri atama özelliğini kaldırmak için, ServerC üzerindeki PrincipalsAllowedToDelegateToAccount parametresinin değerini $nullolarak ayarlayın:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Kaynak tabanlı Kerberos kısıtlanmış yetkilendirmesi hakkında bilgi

Kerberos temsilcisi (kısıtlanmamış)

İkinci atlama yapmak için kısıtlanmamış Kerberos yetkilendirmesini de kullanabilirsiniz. Tüm Kerberos senaryolarında olduğu gibi kimlik bilgileri de depolanmaz. Bu yöntem WinRM için ikinci atlamayı desteklemez.

Uyarı

Bu yöntem, temsilci kimlik bilgilerinin nerede kullanıldığına dair bir denetim sağlamaz. CredSSP'den daha az güvenlidir. Bu yöntem yalnızca test senaryoları için kullanılmalıdır.

Yeterli Yönetim (JEA)

JEA, bir yöneticinin PowerShell oturumu sırasında çalıştırabileceği komutları kısıtlamanıza olanak tanır. İkinci atlama sorununu çözmek için kullanılabilir.

JEA hakkında bilgi için bkz. Yeterli Yönetim (Just Enough Administration).

Avantajlar

  • Sanal hesap kullanılırken parola bakımı yapılmaz.

Dezavantajlar

  • WMF 5.0 veya üzerini gerektirir.
  • Her ara sunucuda (ServerB) yapılandırma gerektirir.

RunAs kullanarak PSSessionConfiguration

ServerB üzerinde bir oturum yapılandırması oluşturabilir ve RunAsCredential parametresini ayarlayabilirsiniz.

İkinci atlama sorununu çözmek için PSSessionConfiguration ve RunAs kullanma hakkında bilgi için bkz. Çoklu sıçramalı PowerShell uzaktan iletişimiçin alternatif bir çözüm.

Avantajlar

  • WMF 3.0 veya sonraki bir sürümü olan tüm sunucularla çalışır.

Dezavantajlar

  • Her ara sunucuda (ServerB), PSSessionConfiguration ve RunAs yapılandırmasını gerektirir.
  • Etki alanı RunAs hesabı kullanılırken parola yönetimi gerektirir.

Kimlik bilgilerini Invoke-Command betik bloğu içinde geçirme

ScriptBlock parametresinin içinde kimlik bilgilerini, Invoke-Command cmdlet'ine bir çağrı sırasında geçirebilirsiniz.

Avantajlar

  • Özel sunucu yapılandırması gerektirmez.
  • WMF 2.0 veya üzerini çalıştıran tüm sunucularda çalışır.

Dezavantajlar

  • Garip bir kod tekniği gerektirir.
  • WMF 2.0 çalıştırılıyorsa, bağımsız değişkenleri uzak oturuma geçirmek için farklı bir söz dizimi kullanılması gerekir.

Örnek

Aşağıdaki örnek, kimlik bilgilerini bir betik bloğuna nasıl ileteceğinizi göstermektedir.

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

Ayrıca bkz.

PowerShell Uzaktan Bağlantı Güvenlik Dikkat Edilmesi Gerekenler

  • Last updated on