Constrained Delegation
Last updated
Was this helpful?
Last updated
Was this helpful?
제한된 위임 역시 Delegation에 조금 더 자세히 기술해뒀지만, 본 페이지에서도 간략하게 매커니즘에 대해서 설명하고 넘어가겠습니다. 근본적으로 제약없는 위임에서는 보안적인 측면과 기능적인 측면에서 단점이 있었습니다. 우선 Unconstrained Delegation이 설정된 머신에 사용자가 접근하면 TGT 사본을 메모리에 캐시한다는 점에서 보안성이 좋지 않았고, Windows에는 Kerberos 인증 외에도 NTLM 인증이 있지만 해당 인증을 사용할 경우 TGT를 전달하지 못해 사용자를 대신하여 서비스에 접근할 수 없다는 점이 있었습니다. 이런 배경에서 Constrained Delegation이 Windows Server 2003부터 도입되었습니다.
기존의 위임과 달라진 것으로는 더 이상 해당 서버에서 다른 사용자의 TGT를 캐시하도록 허용하지 않는 대신, 서버가 자신의 TGT를 이용해서 다른 사용자를 위한 TGS를 요청할 수 있도록 바뀐 것입니다.
위 사진은 IIS 서비스에 대한 Constrained Delegation 예시입니다. IIS 서비스는 Administrator의 Constrained 서비스에 대해서 어떤 사용자든 대신하여 서비스 티켓을 발급할 수 있게 됩니다. 기존의 제약없는 위임의 경우 IIS에 접근하는 모든 사용자들의 TGT가 캐시되어 IIS는 해당 사용자의 TGT 사본을 통해 Constrained라는 서비스에 접근할 서비스 티켓을 발급받았다면, 제약된 위임은 IIS 웹 서버가 Administrator의 Constrained 서비스에 대해서는 모든 사용자의 서비스 티켓을 대행하여 발급할 수 있게 작동합니다.
일반적인 도메인 객체의 경우 위임이 없기 때문에 msDS-AllowedToDelegateTo
속성 값이 비어있지만, 제약된 위임이 설정된 직후 이 속성 값은 SPN으로 채워지게 됩니다. 따라서 위임된 객체를 탐색할 땐 msDS-AllowedToDelegateTo
속성이 비어있지 않은 객체를 찾으면 됩니다.
Rubeus의 s4u에서 사용된 명령어 인자는 다음과 같습니다.
impersonateuser : Constrained Delegation을 통해 가장하고자 하는 사용자
msdsspn : 서비스가 위임할 수 있는 서비스 이름
user : 위임을 수행할 수 있는 주체
ticket : 위임을 수행할 수 있는 주체의 TGT
S4U를 통해 서비스 티켓이 생성되었다면 새로운 로그인 세션에 삽입하여 세션을 획득합니다.