PowerShell 원격에서 두 번째 홉 만들기

"두 번째 홉 문제"는 다음과 같은 상황을 설명합니다.

1. ServerA에 로그인됩니다.
2. ServerA에서 원격 PowerShell 세션을 시작하여 ServerB에 연결합니다.
3. PowerShell 원격 세션을 통해 ServerB 에서 실행하는 명령은 ServerC의 리소스에 액세스하려고 시도합니다.
4. PowerShell 원격 세션을 만드는 데 사용한 자격 증명이 ServerB에서 ServerC로 전달되지 않으므로 ServerC의 리소스에 대한 액세스가 거부됩니다.

이 문제를 해결하는 방법에는 여러 가지가 있습니다. 다음 표에서는 기본 설정 순서로 메서드를 나열합니다.

크레드SSP

인증에는 자격 증명 보안 지원 공급자(CredSSP)를 사용할 수 있습니다. CredSSP는 원격 서버(ServerB)에서 자격 증명을 캐시하므로 자격 증명을 사용하면 자격 증명 도난 공격이 시작됩니다. 원격 컴퓨터의 보안이 손상되면 공격자가 사용자의 자격 증명에 액세스할 수 있습니다. 기본적으로 CredSSP는 클라이언트 및 서버 컴퓨터 모두에서 사용하지 않도록 설정됩니다. 가장 신뢰할 수 있는 환경에서만 CredSSP를 사용하도록 설정해야 합니다. 예를 들어, 도메인 관리자가 매우 신뢰할 수 있는 도메인 컨트롤러에 연결하는 경우입니다.

PowerShell 원격에 CredSSP를 사용할 때 발생하는 보안 문제에 대한 자세한 내용은 실수로 인한 사보타주: CredSSP 주의를 참조하세요.

자격 증명 도난 공격에 대한 자세한 내용은 PtH(Pass-the-Hash) 공격 및 기타 자격 증명 도난 완화를 참조하세요.

PowerShell 원격에 CredSSP를 사용하도록 설정하고 사용하는 방법에 대한 예제는 CredSSP를 사용하여 PowerShell "두 번째 홉" 기능 사용을 참조하세요.

장점

• Windows Server 2008 이상의 모든 서버에서 작동합니다.

단점

• 보안 취약성이 있습니다.
• 클라이언트 역할과 서버 역할을 모두 구성해야 합니다.
• 는 보호된 사용자 그룹에서 작동하지 않습니다. 자세한 내용은 보호된 사용자 보안 그룹을 참조하세요.

Kerberos 제한 위임

레거시 제약된 위임(리소스 기반 아님)을 사용하여 두 번째 홉을 수행할 수 있습니다. 프로토콜 전환을 허용하려면 "모든 인증 프로토콜 사용" 옵션을 사용하여 Kerberos 제한 위임을 구성합니다.

장점

• 특별한 코딩이 필요하지 않습니다.
• 자격 증명은 저장되지 않습니다.

단점

• WinRM에 대한 두 번째 홉을 지원하지 않습니다.
• 구성하려면 도메인 관리자 액세스 권한이 필요합니다.
• 원격 서버(ServerB)의 Active Directory 개체에서 구성해야 합니다.
• 하나의 도메인으로 제한됩니다. 도메인 또는 포레스트를 교차할 수 없습니다.
• 개체 및 SPN(서비스 사용자 이름)을 업데이트할 수 있는 권한이 필요합니다.
• ServerB 는 사용자 개입 없이 사용자를 대신하여 ServerC 에 대한 Kerberos 티켓을 획득할 수 있습니다.

리소스 기반 Kerberos 제한 위임

리소스 기반 Kerberos 제한 위임(Windows Server 2012에서 도입됨)을 사용하여 리소스가 있는 서버 개체에서 자격 증명 위임을 구성합니다. 위에서 설명한 두 번째 홉 시나리오에서는 위임된 자격 증명을 수락하는 위치를 지정하도록 ServerC 를 구성합니다.

장점

• 자격 증명은 저장되지 않습니다.
• PowerShell cmdlet을 사용하여 구성됩니다. 특별한 코딩이 필요하지 않습니다.
• 구성하려면 도메인 관리자 액세스 권한이 필요하지 않습니다.
• 도메인 및 포리스트에서 작동합니다.

단점

• Windows Server 2012 이상이 필요합니다.
• WinRM에 대한 두 번째 홉을 지원하지 않습니다.
• 개체 및 SPN(서비스 사용자 이름)을 업데이트할 수 있는 권한이 필요합니다.

예시

ServerB에서 위임된 자격 증명을 허용하도록 ServerC에서 리소스 기반 제한 위임을 구성하는 PowerShell 예제를 살펴보겠습니다. 이 예제에서는 모든 서버가 지원되는 버전의 Windows Server를 실행하고 있으며 신뢰할 수 있는 각 도메인에 대해 하나 이상의 Windows 도메인 컨트롤러가 있다고 가정합니다.

제한된 위임을 구성하려면 먼저 Active Directory PowerShell 모듈을 설치하는 기능을 추가 RSAT-AD-PowerShell 한 다음 해당 모듈을 세션으로 가져와야 합니다.

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

이제 몇 가지 사용 가능한 cmdlet에 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

PrincipalsAllowedToDelegateToAccount 매개 변수는 msDS-AllowedToActOnBehalfOfOtherIdentity라는 Active Directory 개체 특성을 설정하며, 이 특성에는 연결된 계정에 자격 증명을 위임할 권한이 있는 계정을 명시하는 ACL(액세스 제어 목록)이 포함됩니다. 여기서 예로 들면, 해당 계정은 ServerA의 컴퓨터 계정이 됩니다.

이제 서버를 나타내는 데 사용할 변수를 설정해 보겠습니다.

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

WinRM은 기본적으로 컴퓨터 계정으로 실행됩니다. 따라서 PowerShell 원격 관리도 기본적으로 같은 방식으로 실행됩니다. 서비스의 StartName 속성을 winrm 보면 이를 확인할 수 있습니다.

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

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

ServerC에서 ServerB의 PowerShell 원격 세션으로부터 위임을 허용하려면, PrincipalsAllowedToDelegateToAccount 매개 변수를 ServerB의 컴퓨터 개체로 ServerC에 설정해야 합니다.

# 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 KDC(키 배포 센터) 는 15분 동안 액세스 거부 시도(음수 캐시)를 캐시합니다. ServerB가 이전에 ServerC에 액세스하려고 시도한 경우 다음 명령을 호출하여 ServerB의 캐시를 지워야 합니다.

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

컴퓨터를 다시 시작하거나 캐시를 지우기 위해 15분 이상 기다릴 수도 있습니다.

캐시를 지우면 ServerA에서 ServerB를 통해 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)
}

이 예제에서는 Using: 스코프 수정자를 사용하여 $ServerC 변수가 ServerB에 보이도록 설정합니다. 범위 한정자에 Using: 대한 자세한 내용은 about_Remote_Variables 참조하세요.

여러 서버가 ServerC에 자격 증명을 위임할 수 있도록 하려면 ServerC의 PrincipalsAllowedToDelegateToAccount 매개 변수 값을 배열로 설정합니다.

# 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

도메인 간에 두 번째 홉을 만들려면 Server 매개 변수를 사용하여 ServerB 가 속한 도메인의 도메인 컨트롤러에 대한 FQDN(정규화된 도메인 이름)을 지정합니다.

# 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에 자격 증명을 위임하는 기능을 제거하려면 ServerC의 PrincipalsAllowedToDelegateToAccount 매개 변수 값을 로 설정하십시오.

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

리소스 기반 Kerberos 제한 위임에 대한 정보

• Kerberos 인증의 새로운 기능
• Windows Server 2012가 Kerberos 제한 위임의 고통을 덜어주는 방법, 1부
• Windows Server 2012가 Kerberos 제한 위임의 고통을 덜어주는 방법, 2부
• Windows 통합 인증을 사용하여 Microsoft Entra 애플리케이션 프록시 배포에 대한 Kerberos 제한 위임 이해
• [MS-ADA2 Active Directory 스키마 특성 M2.210 특성 msDS-AllowedToActOnBehalfOfOtherIdentity]MS-ADA2
• [MS-SFU Kerberos 프로토콜 확장: 사용자 및 제한된 위임 프로토콜 1.3.2 S4U2proxy용 서비스]MS-SFU
• 원격 관리에서 PrincipalsAllowedToDelegateToAccount를 사용하여 제한된 위임 없이

Kerberos 위임(제한되지 않음)

Kerberos 제한되지 않은 위임을 사용하여 두 번째 홉을 만들 수도 있습니다. 모든 Kerberos 시나리오와 마찬가지로 자격 증명은 저장되지 않습니다. 이 메서드는 WinRM에 대한 두 번째 홉을 지원하지 않습니다.

JEA(Just Enough Administration)

JEA를 사용하면 PowerShell 세션 중에 관리자가 실행할 수 있는 명령을 제한할 수 있습니다. 두 번째 홉 문제를 해결하는 데 사용할 수 있습니다.

JEA에 대한 자세한 내용은 Just Enough Administration을 참조하세요.

장점

• 가상 계정을 사용하는 경우 암호 유지 관리가 없습니다.

단점

• WMF 5.0 이상이 필요합니다.
• 모든 중간 서버(ServerB)에 대한 구성이 필요합니다.

RunAs를 사용하는 PSSessionConfiguration

ServerB에서 세션 구성을 만들고 RunAsCredential 매개 변수를 설정할 수 있습니다.

PSSessionConfiguration 및 RunAs를 사용하여 두 번째 홉 문제를 해결하는 방법에 대한 자세한 내용은 다중 홉 PowerShell 원격에 대한 다른 솔루션을 참조하세요.

장점

• WMF 3.0 이상을 사용하여 모든 서버에서 작동합니다.

단점

• 모든 중간 서버(ServerB)에서 PSSessionConfiguration 및 RunA를 구성해야 합니다.
• 도메인 RunAs 계정을 사용할 때 암호 유지 관리 필요

Invoke-Command 스크립트 블록 내에 자격 증명 전달

Invoke-Command cmdlet에 대한 호출의 ScriptBlock 매개 변수 내에 자격 증명을 전달할 수 있습니다.

장점

• 특별한 서버 구성이 필요하지 않습니다.
• WMF 2.0 이상을 실행하는 모든 서버에서 작동합니다.

단점

• 어색한 코드 기술이 필요합니다.
• WMF 2.0을 실행하는 경우 원격 세션에 인수를 전달하기 위해 다른 구문이 필요합니다.

예시

다음 예제에서는 스크립트 블록에 자격 증명을 전달하는 방법을 보여줍니다.

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

참고하십시오

PowerShell 원격 보안 고려 사항