Aracılığıyla paylaş

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

  • Makale

"İkinci atlama sorunu" aşağıdaki gibi bir duruma başvurur:

  1. ServerA'da 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 İletişim oturumunu oluştururken kullandığınız kimlik bilgileri ServerB'den ServerC'ye geçirilmediğinden ServerC'de 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.

Yapılandırma Not
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ıtlanmış temsili Yüksek güvenlik, ancak Etki Alanı Yönetici istrator 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ğunun içine geçirme 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ı'nı (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, etki alanı denetleyicisi son derece güvenilir olduğundan etki alanı denetleyicisine bağlanan bir etki alanı yöneticisi.

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: CredSSP'ye dikkat 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ıtlanmış temsili

İkinci atlama için eski kısıtlanmış temsili (kaynak tabanlı değil) 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önetici istrator erişimi gerektirir.
  • Uzak sunucunun (ServerB) Active Directory nesnesinde yapılandırılmalıdır.
  • 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ı müdahalesi olmadan kullanıcı adına ServerC'ye bir Kerberos bileti alabilir.

Not

Hesabı hassas olan ve temsilci seçilemedi özellik kümesine sahip Active Directory hesaplarına temsilci atanamaz. Daha fazla bilgi için, Ayrıcalıklı Hesaplar ve Kerberos Kimlik Doğrulama Araçları ve Ayarlar için Bkz. Güvenlik Odağı: 'Hesap hassas ve temsilci seçilemiyor' analizi.

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'yi 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önetici istrator erişimi gerektirmez.
  • 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.

Not

Hesabı hassas olan ve temsilci seçilemedi özellik kümesine sahip Active Directory hesaplarına temsilci atanamaz. Daha fazla bilgi için, Ayrıcalıklı Hesaplar ve Kerberos Kimlik Doğrulama Araçları ve Ayarlar için Bkz. Güvenlik Odağı: 'Hesap hassas ve temsilci seçilemiyor' analizi.

Örnek

ServerB'den temsilci kimlik bilgilerine izin vermek için ServerC'de kaynak tabanlı kısıtlanmış temsili yapılandıran bir PowerShell örneğine göz atalı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ü RSAT-AD-PowerShell yüklemek için ö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

Kullanılabilir birkaç cmdlet'in principalsAllowedToDelegateToAccount parametresi vardır:

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, hangi hesapların ilişkili hesaba kimlik bilgilerini devretme iznine sahip olduğunu belirten bir erişim denetimi listesi (ACL) içeren msDS-AllowedToActOnBehalfOfOtherIdentity Active Directory nesne özniteliğini ayarlar (örneğimizde, SunucuA için makine hesabı olacaktır).

Ş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 iletişim) varsayılan olarak bilgisayar hesabı olarak çalışır. Hizmetin StartName özelliğine winrm bakarak bunu görebilirsiniz:

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

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

ServerC'nin ServerB'de bir PowerShell uzaktan iletişim oturumundan temsilci seçmeye izin vermesi için, ServerC'de PrincipalsAllowedToDelegateToAccount parametresini ServerB'nin bilgisayar 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), reddedilen erişim girişimlerini (negatif önbellek) 15 dakika boyunca önbelleğe alır. ServerB daha önce ServerC'ye erişmeye çalıştıysa, aşağıdaki komutu çağırarak ServerB önbelleğini 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, ServerA'dan ServerB'den ServerC'ye kodu başarıyla ç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 değişken, $using değişkenin ServerB'ye görünür olmasını sağlamak $ServerC için kullanılır. Değişken hakkında $using daha fazla bilgi için bkz . about_Remote_Variables.

Birden çok sunucunun ServerC'ye kimlik bilgileri atamasına izin vermek için ServerC'de PrincipalsAllowedToDelegateToAccount parametresinin değerini bir dizi olarak 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'nin ait olduğu etki alanının etki alanı denetleyicisinin tam etki alanı adını (FQDN) belirtmek için Sunucu 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

Kimlik bilgilerini ServerC'ye devretme özelliğini kaldırmak için ServerC'de PrincipalsAllowedToDelegateToAccount parametresinin değerini olarak $nullayarlayın:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

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

Kerberos temsilcisi (kısıtlanmamış)

İkinci atlama için Kerberos kısıtlanmamış temsili 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. Just Enough Yönetici istration.

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'de 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. Çok atlamalı PowerShell uzaktan iletişiminin başka 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 RunA'ların yapılandırılmasını gerektirir.
  • Etki alanı RunAs hesabı kullanılırken parola bakımı gerektirir

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

Invoke-Command cmdlet'ine bir çağrının ScriptBlock parametresi içinde kimlik bilgilerini 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ı söz dizimi gerekir.

Örnek

Aşağıdaki örnekte, kimlik bilgilerinin bir betik bloğuna nasıl ilettiği gösterilmektedir:

# 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 İletişim Güvenlik Konuları