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

"두 번째 홉 문제"는 다음과 같은 상황을 나타냅니다.

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

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

CredSSP

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

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

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

PowerShell 원격에 대해 CredSSP를 사용하도록 설정하고 사용하는 방법의 예는 Enable PowerShell "Second-Hop" Functionality with CredSSP(CredSSP를 사용하여 PowerShell "두 번째 홉" 기능 사용)을 참조하세요.

장점

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

단점

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

Kerberos 제한 위임

리소스 기반이 아닌 레거시 제한 위임을 사용하여 두 번째 홉을 만들 수 있습니다. "모든 인증 프로토콜 사용" 옵션을 사용하여 프로토콜 전환을 허용하도록 Kerberos 제한 위임을 구성합니다.

장점

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

단점

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

리소스 기반 Kerberos 제한 위임

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

장점

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

단점

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

예시

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

제한된 위임을 구성하려면 먼저 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 매개 변수는 연결된 계정에 자격 증명을 위임할 권한이 있는 계정을 지정하는 ACL(액세스 제어 목록)이 포함된 Active Directory 개체 특성 msDS-AllowedToActOnBehalfOfOtherIdentity를 설정합니다(이 예에서는 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 원격 세션에서 위임을 허용하려면 ServerC의 PrincipalsAllowedToDelegateToAccount 매개 변수를 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

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

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

# 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 매개 변수 값을 $null로 설정합니다.

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

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

• Kerberos 인증의 새로운 기능
• Windows Server 2012가 Kerberos 제한 위임의 고통을 덜어주는 방법, 1부
• How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2(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
• Remote Administration Without Constrained Delegation Using PrincipalsAllowedToDelegateToAccount(PrincipalsAllowedToDelegateToAccount를 사용한 제한 위임 없는 원격 관리)

Kerberos 위임(제한되지 않음)

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

JEA(Just Enough Administration)

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

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

장점

• 가상 계정을 사용할 경우 암호를 유지 관리할 필요가 없습니다.

단점

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

RunAs를 사용하는 PSSessionConfiguration

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

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

장점

• WMF 3.0 이상이 설치된 모든 서버에서 작동합니다.

단점

• 모든 중간 서버(ServerB)에서 PSSessionConfiguration 및 RunA를 구성해야 합니다.
• do기본 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 원격 보안 고려 사항