PowerShell 원격에서 두 번째 홉 만들기Making the second hop in PowerShell Remoting

"두 번째 홉 문제"는 다음과 같은 상황을 말합니다.The "second hop problem" refers to a situation like the following:

  1. _ServerA_에 로그인되어 있습니다.You are logged in to ServerA.
  2. _ServerA_에서 원격 PowerShell 세션을 시작하여 _ServerB_에 연결합니다.From ServerA, you start a remote PowerShell session to connect to ServerB.
  3. PowerShell 원격 세션을 통해 _ServerB_에서 실행하는 명령이 _ServerC_에 있는 리소스에 액세스하려고 합니다.A command you run on ServerB via your PowerShell Remoting session attempts to access a resource on ServerC.
  4. PowerShell 원격 세션을 만드는 데 사용한 자격 증명이 _ServerB_에서 _ServerC_로 전달되지 않았으므로 _ServerC_에 있는 리소스에 대한 액세스가 거부됩니다.Access to the resource on ServerC is denied, because the credentials you used to create the PowerShell Remoting session are not passed from ServerB to ServerC.

이 문제를 해결하는 방법은 여러 가지가 있습니다.There are several ways to address this problem. 이 항목에서는 두 번째 홉 문제에 대한 가장 인기 있는 해결 방법 몇 가지를 살펴보겠습니다.In this topic, we'll look at several of the most popular solutions to the second hop problem.

CredSSPCredSSP

인증에 Credential Security Support Provider (CredSSP)(CredSSP(자격 증명 보안 지원 공급자))를 사용할 수 있습니다.You can use the Credential Security Support Provider (CredSSP) for authentication. CredSSP는 원격 서버(ServerB)에 자격 증명을 캐시하므로, 이를 사용하면 자격 증명 도난 공격을 받을 수 있습니다.CredSSP caches credentials on the remote server (ServerB), so using it opens you up to credential theft attacks. 원격 컴퓨터의 보안이 손상되면 공격자가 사용자의 자격 증명에 액세스할 수 있습니다.If the remote computer is compromised, the attacker has access to the user's credentials. 기본적으로 CredSSP는 클라이언트 및 서버 컴퓨터 모두에서 사용하지 않도록 설정됩니다.CredSSP is disabled by default on both client and server computers. 가장 신뢰할 수 있는 환경에서만 CredSSP를 사용하도록 설정해야 합니다.You should enable CredSSP only in the most trusted environments. 예를 들어 도메인 컨트롤러는 매우 신뢰할 수 있으므로 도메인 관리자는 도메인 컨트롤러에 연결합니다.For example, a domain administrator connecting to a domain controller because the domain controller is highly trusted.

PowerShell 원격에 CredSSP 사용 시의 보안 우려 사항에 대한 자세한 내용은 Accidental Sabotage: Beware of CredSSP(고의적 파괴: CredSSP 조심)를 참조하세요.For more information about security concerns when using CredSSP for PowerShell Remoting, see Accidental Sabotage: Beware of CredSSP.

자격 증명 도난 공격에 대한 자세한 내용은 PtH(Pass-the-Hash) 공격 및 기타 자격 증명 도난 완화를 참조하세요.For more information about credential theft attacks, see Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft.

PowerShell 원격에 대해 CredSSP를 사용하도록 설정하고 사용하는 방법의 예는 Using CredSSP to solve the second-hop problem(CredSSP를 사용하여 두 번째 홉 문제 해결)을 참조하세요.For an example of how to enable and use CredSSP for PowerShell remoting, see Using CredSSP to solve the second-hop problem.

장점Pros

  • Windows Server 2008 이상이 설치된 모든 서버에 대해 작동합니다.It works for all servers with Windows Server 2008 or later.

단점Cons

  • 보안 취약성이 있습니다.Has security vulnerabilities.
  • 클라이언트 역할과 서버 역할을 둘 다 구성해야 합니다.Requires configuration of both client and server roles.

Kerberos 위임(비제한)Kerberos delegation (unconstrained)

Kerberos 비제한 위임을 사용하여 두 번째 홉을 만들 수도 있습니다.You can also used Kerberos unconstrained delegation to make the second hop. 그러나 이 방법을 사용할 경우 위임된 자격 증명이 사용되는 위치를 제어할 수 없습니다.However, this method provides no control of where delegated credentials are used.

참고: 계정이 민감하여 위임할 수 없음 속성이 설정된 Active Directory 계정은 위임할 수 없습니다.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. 자세한 내용은 Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts(보안 초점: 권한 있는 계정에 대한 '계정이 민감하여 위임할 수 없음' 분석) 및 Kerberos Authentication Tools and Settings(Kerberos 인증 도구 및 설정)를 참조하세요.For more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

장점Pros

  • 특수 코딩이 필요하지 않습니다.Requires no special coding.

단점Cons

  • WinRM에 대한 두 번째 홉을 지원하지 않습니다.Does not support the second hop for WinRM.
  • 자격 증명이 사용되는 위치를 제어할 수 없어 보안 취약성이 발생합니다.Provides no control over where credentials are used, creating a security vulnerability.

Kerberos 제한 위임Kerberos constrained delegation

레거시 제한 위임(리소스 기반 아님)을 사용하여 두 번째 홉을 만들 수 있습니다.You can use legacy constrained delegation (not resource-based) to make the second hop.

참고: 계정이 민감하여 위임할 수 없음 속성이 설정된 Active Directory 계정은 위임할 수 없습니다.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. 자세한 내용은 Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts(보안 초점: 권한 있는 계정에 대한 '계정이 민감하여 위임할 수 없음' 분석) 및 Kerberos Authentication Tools and Settings(Kerberos 인증 도구 및 설정)를 참조하세요.For more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

장점Pros

  • 특수 코딩이 필요하지 않습니다.Requires no special coding

단점Cons

  • WinRM에 대한 두 번째 홉을 지원하지 않습니다.Does not support the second hop for WinRM.
  • 원격 서버(ServerB)의 Active Directory 개체에 대해 구성해야 합니다.Must be configured on the Active Directory object of the remote server (ServerB).
  • 도메인 하나로 제한됩니다.Limited to one domain. 도메인 또는 포리스트를 벗어날 수 없습니다.Cannot cross domains or forests.
  • 개체 및 SPN(서비스 사용자 이름)을 업데이트할 수 있는 권한이 필요합니다.Requires rights to update objects and Service Principal Names (SPNs).

리소스 기반 Kerberos 제한 위임Resource-based Kerberos constrained delegation

리소스 기반 Kerberos 제한 위임(Windows Server 2012에 도입됨)을 사용하여 리소스가 있는 서버 개체에 대한 자격 증명 위임을 구성합니다.Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you configure credential delegation on the server object where resources reside. 위에서 설명한 두 번째 홉 시나리오에서 위임된 자격 증명을 허용할 위치를 지정하도록 _ServerC_를 구성합니다.In the second hop scenario described above, you configure ServerC to specify from where it will accept delegated credentials.

참고: 계정이 민감하여 위임할 수 없음 속성이 설정된 Active Directory 계정은 위임할 수 없습니다.Note: Active Directory accounts that have the Account is sensitive and cannot be delegated property set cannot be delegated. 자세한 내용은 Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts(보안 초점: 권한 있는 계정에 대한 '계정이 민감하여 위임할 수 없음' 분석) 및 Kerberos Authentication Tools and Settings(Kerberos 인증 도구 및 설정)를 참조하세요.For more information, see Security Focus: Analysing 'Account is sensitive and cannot be delegated' for Privileged Accounts and Kerberos Authentication Tools and Settings

장점Pros

  • 자격 증명이 저장되지 않습니다.Credentials are not stored.
  • PowerShell cmdlet을 사용하여 비교적 쉽게 구성할 수 있으며 특수 코딩이 필요하지 않습니다.Relatively easy to configure by using PowerShell cmdlets--no special coding required.
  • 특별 도메인 액세스가 필요하지 않습니다.No special domain access is required.
  • 도메인 및 포리스트에서 작동합니다.Works across domains and forests.
  • PowerShell 코드입니다.PowerShell code.

단점Cons

  • Windows Server 2012 이상이 필요합니다.Requires Windows Server 2012 or later.
  • WinRM에 대한 두 번째 홉을 지원하지 않습니다.Does not support the second hop for WinRM.
  • 개체 및 SPN(서비스 사용자 이름)을 업데이트할 수 있는 권한이 필요합니다.Requires rights to update objects and Service Principal Names (SPNs).

예제Example

_ServerB_의 위임된 자격 증명을 허용하도록 _ServerC_에 대해 리소스 기반 제한 위임을 구성하는 PowerShell 예제를 살펴보겠습니다.Let's look at a PowerShell example that configures resource based constrained delegation on ServerC to allow delegated credentials from a ServerB. 이 예제에서는 모든 서버가 Windows Server 2012 이상을 실행하고 있으며 서버가 속하는 각 도메인에 하나 이상의 Windows Server 2012 도메인 컨트롤러가 있다고 가정합니다.This example assumes that all servers are running Windows Server 2012 or later, and that there is at least one Windows Server 2012 domain controller each domain to which any of the servers belong.

제한 위임을 구성하기 전에 먼저 RSAT-AD-PowerShell 기능을 추가하여 Active Directory PowerShell 모듈을 설치한 다음 해당 모듈을 세션으로 가져와야 합니다.Before you can configure constrained delegation, you must add the RSAT-AD-PowerShell feature to install the Active Directory PowerShell module, and then import that module into your session:

PS C:\> Add-WindowsFeature RSAT-AD-PowerShell

PS C:\> Import-Module ActiveDirectory

이제 사용할 수 있는 여러 cmdlet에 PrincipalsAllowedToDelegateToAccount 매개 변수가 있습니다.Several available cmdlets now have a PrincipalsAllowedToDelegateToAccount parameter:

PS C:\> Get-Command -ParameterName 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 매개 변수는 Active Directory 개체 특성 msDS-AllowedToActOnBehalfOfOtherIdentity를 설정합니다. 이 특성은 자격 증명을 연결된 계정(이 예제에서는 _Server_의 컴퓨터 계정이 됨)에 위임할 수 있는 권한이 있는 계정을 지정하는 ACL(액세스 제어 목록)을 포함합니다.The PrincipalsAllowedToDelegateToAccount parameter sets the Active Directory object attribute msDS-AllowedToActOnBehalfOfOtherIdentity, which contains an access control list (ACL) that specifies which accounts have permission to delegate credentials to the associated account (in our example, it will be the machine account for Server).

이제 서버를 나타내는 데 사용할 변수를 설정하겠습니다.Now let's set up the variables we'll use to represent the servers:

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

WinRM(및 따라서 PowerShell 원격)은 기본적으로 컴퓨터 계정으로 실행됩니다.WinRM (and therefore PowerShell remoting) runs as the computer account by default. winrm 서비스의 StartName 속성을 살펴보아 이를 확인할 수 있습니다.You can see this by looking at the StartName property of the winrm service:

PS C:\> Get-WmiObject win32_service -filter 'name="winrm"' | Format-List StartName

StartName : NT AUTHORITY\NetworkService

_ServerC_가 _ServerB_의 PowerShell 원격 세션으로부터의 위임을 허용하도록 _ServerC_에 대한 PrincipalsAllowedToDelegateToAccount 매개 변수를 _ServerB_의 컴퓨터 개체로 설정하여 액세스 권한을 부여합니다.For ServerC to allow delegation from a PowerShell remoting session on ServerB, we will grant access by setting the PrincipalsAllowedToDelegateToAccount parameter on ServerC to the computer object of 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 Key Distribution Center (KDC)KDC(키 배포 센터)는 15분마다 거부된 액세스 시도(부정 캐시)를 캐시합니다.The Kerberos Key Distribution Center (KDC) caches denied access attempts (negative cache) for 15 minutes. _ServerB_가 이전에 _ServerC_에 액세스하려고 시도한 경우 다음 명령을 호출하여 _ServerB_의 캐시를 지워야 합니다.If ServerB has previously attempted to access ServerC, you will need to clear the cache on ServerB by invoking the following command:

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

캐시를 지우기 위해 컴퓨터를 다시 시작하거나 15분 이상 기다려야 할 수도 있습니다.You could also restart the computer, or wait at least 15 minutes to clear the cache.

캐시를 지운 후 _ServerA_에서 _ServerB_를 거쳐 _ServerC_까지 코드를 실행할 수 있습니다.After clearing the cache, you can successfully run code from ServerA through ServerB to 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_에 표시되도록 하는 데 사용됩니다.In this example, the $using variable is used to make the $ServerC variable visible to ServerB. $using 변수에 대한 자세한 내용은 about_Remote_Variables를 참조하세요.For more information about the $using variable, see about_Remote_Variables.

여러 서버가 _ServerC_에 자격 증명을 위임할 수 있도록 하려면 _ServerC_에 대한 PrincipalsAllowedToDelegateToAccount 매개 변수 값을 배열로 설정합니다.To allow multiple servers to delegate credentials to ServerC, set the value of the PrincipalsAllowedToDelegateToAccount parameter on ServerC to an 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

# Grant resource-based Kerberos constrained delegation
Set-ADComputer -Identity $ServerC `
    -PrincipalsAllowedToDelegateToAccount @($ServerB1,$ServerB2,$ServerB3)

도메인에 걸쳐 두 번째 홉을 만들려는 경우 _ServerB_가 속하는 도메인의 도메인 컨트롤러에 대한 FQDN(정규화된 도메인 이름)을 추가합니다.If you want to make the second hop across domains, add fully-qualified domain name (FQDN) of the domain controller of the domain to which ServerB belongs:

# 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로 설정합니다.To remove the ability to delegate credentials to ServerC, set the value of the PrincipalsAllowedToDelegateToAccount parameter on ServerC to $null:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

리소스 기반 Kerberos 제한 위임에 대한 정보Information on resource-based Kerberos constrained delegation

RunAs를 사용한 PSSessionConfigurationPSSessionConfiguration using RunAs

_ServerB_에 대한 세션 구성을 만들고 해당 RunAsCredential 매개 변수를 설정할 수 있습니다.You can create a session configuration on ServerB and set its RunAsCredential parameter.

PSSessionConfiguration 및 RunAs를 사용하여 두 번째 홉 문제를 해결하는 방법에 대한 자세한 내용은 Another solution to multi-hop PowerShell remoting(다중 홉 PowerShell 원격에 대한 다른 해결 방법)을 참조하세요.For information about using PSSessionConfiguration and RunAs to solve the second hop problem, see Another solution to multi-hop PowerShell remoting.

장점Pros

  • WMF 3.0 이상이 설치된 모든 서버에서 작동합니다.Works with any server with WMF 3.0 or later.

단점Cons

  • 모든 중간 서버(ServerB)에 대해 PSSessionConfigurationRunAs를 구성해야 합니다.Requires configuration of PSSessionConfiguration and RunAs on every intermediate server (ServerB).
  • 도메인 RunAs 계정을 사용할 경우 암호를 유지 관리해야 합니다.Requires password maintenance when using a domain RunAs account

JEA(Just Enough Administration)Just Enough Administration (JEA)

JEA를 사용하여 PowerShell 세션 동안 관리자가 실행할 수 있는 명령을 제한할 수 있습니다.JEA allows you to restrict what commands an administrator can run during a PowerShell session. 두 번째 홉 문제를 해결하는 데 JEA를 사용할 수 있습니다.It can be used to solve the second hop problem.

JEA에 대한 자세한 내용은 Just Enough Administration을 참조하세요.For information about JEA, see Just Enough Administration.

장점Pros

  • 가상 계정을 사용할 경우 암호를 유지 관리할 필요가 없습니다.No password maintenance when using a virtual account.

단점Cons

  • WMF 5.0 이상이 필요합니다.Requires WMF 5.0 or later.
  • 모든 중간 서버(ServerB)에 대한 구성이 필요합니다.Requires configuration on every intermediate server (ServerB).

Invoke-Command 스크립트 블록 내에 자격 증명 전달Pass credentials inside an Invoke-Command script block

Invoke-Command cmdlet 호출의 ScriptBlock 매개 변수 내에 자격 증명을 전달할 수 있습니다.You can pass credentials inside the ScriptBlock parameter of a call to the Invoke-Command cmdlet.

장점Pros

  • 특별한 서버 구성이 필요하지 않습니다.Does not require special server configuration.
  • WMF 2.0 이상을 실행하는 모든 서버에서 작동합니다.Works on any server running WMF 2.0 or later.

단점Cons

  • 불편한 코드 기법이 필요합니다.Requires an awkward code technique.
  • WMF 2.0을 실행하는 경우 원격 세션으로 인수를 전달하는 데 서로 다른 구문이 필요합니다.If running WMF 2.0, requires different syntax for passing arguments to a remote session.

예제Example

다음 예제에서는 Invoke-Command 스크립트 블록으로 자격 증명을 전달하는 방법을 보여 줍니다.The following example shows how to pass credentials in an Invoke-Command script block:

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

참고 항목See also

PowerShell Remoting 보안 고려 사항PowerShell Remoting Security Considerations