본문 바로가기

Security

Active Directory - Kerberos

Kerberos는 송수신 과정의 네트워크 패킷을 들여다 볼 수 있고, 변조가 가능한 개방된 네트워크 환경에서 Client와 Server간에 상호 인증(Authentication)을 위한 기능을 제공합니다.

 

안정적인 인증을 제공하기 위해서 Kerberos는 Symmetric Keys, Encrypted Objects, Keberos 서비스를 이용합니다.

Kerberos 인증은 여러 종류의 Key를 사용합니다.

1) User, service, system keys : 패스워드에서 생성한 Symmetric keys

2) Public keys : Smart card와 사용되는 Asymmetric keys

3) Session keys : Domain Controller가 생성한 Symmetric keys

 

이러한 Key들을 분산시키기 위해서, 그리스 신화에서 머리가 3개 달린 Kerberos라는 이름을 따와 지은 Client, Server, Trusted third party로 구성된 Kerberos Protocol을 이용합니다.

Trusted third party는 Client와 Server 사이에서 중재하는 역할을 담당합니다.

Kerberos 환경

Client와 Server는 Trusted third party인 KDC를 신뢰하고, Client가 Server에 접근하기 위해서 KDC로부터 Ticket을 발급받는 구성입니다.

 

이 중에서 KDC에 대해서 알아보면,

1) KDC는 Ticket을 발급하는 역할을 담당합니다.

2) KDC는 실제로는 Domain Controller 서버에 Kerberos Key Distribution Center라는 이름의 서비스로 등록되어 있습니다.

3) KDC는 Domain 내에 있는 모든 계정 정보(Security Principals)를 담고 있는 AD Database를 이용합니다.

4) Client는 Ticket을 발급받을 권한을 위한 TGT와 서비스를 요청하기 위한 Ticket인 TGS 두 가지를 KDC를 통해서 발급받습니다.

5) 이는 각각, KDC 내에 AS(Authentication Service)TGS(Ticket Granting Server)가 담당합니다.

AS는 Kerberos Procotol의 flow에서 AS_Request/AS_Reply 단계에서 동작하며, TGS는 TGS_Request/TGS_Reply 단계에서 동작합니다.

 

참고로 TGT는 Client의 Password hash 값으로 암호화가 되고, TGS는 서비스를 제공하는 Target Server의 Password hash 값으로 암호화가 됩니다.

 

이번에는 중요한 Service ticket을 발급받는 과정에 대해서 알아보겠습니다.

1) Client가 Request에 서비스를 받고자 하는 Kerberos target의 SPN(Service Principal Name)을 KDC에 보내서 어떤 서비스에 접속하려고 하는지를 전달합니다.

2) KDC는 AD 내에서 SPN과 관련된 Object를 찾아 해당 Object(target) Account의 Password hash 값으로 Service ticket을 암호화 하여 Client에게 이 Ticket을 전달합니다.

3) Client는 KDC로부터 전달받은 Service ticket을 Target에게 보내고, Target이 정상적으로 Service ticket을 복호화하게 되면 연결이 성공하게 됩니다.

 

이 과정을 도식화해보면 다음과 같습니다.

AS_Reqeust/AS_Reply는 생략되었지만, 대부분의 Flow가 담겨 있습니다.

 

실제로 이러한 Flow를 눈으로 보기 위해서 인증 과정 중 네트워크 Packet을 수집하여 확인할 수 있습니다.

아래 예제는 Client PC에서 같은 Domain 내에 있는 File Server에 생성된 공유 폴더에 접근할 때 수집한 Packet 입니다.

TCP 3-way handshake between client and domain controller
71448	2022-09-27 08:48:14.017261	192.168.1.4	192.168.1.2	TCP	66	49705 → 88 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
71449	2022-09-27 08:48:14.017361	192.168.1.2	192.168.1.4	TCP	66	88 → 49705 [SYN, ACK, ECN] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
71450	2022-09-27 08:48:14.017511	192.168.1.4	192.168.1.2	TCP	60	49705 → 88 [ACK] Seq=1 Ack=1 Win=2102272 Len=0

AS-REQ / AS-REP
71459	2022-09-27 08:48:14.018550	192.168.1.4	192.168.1.2	KRB5	357	AS-REQ
71460	2022-09-27 08:48:14.018952	192.168.1.2	192.168.1.4	KRB5	1577	AS-REP

TGS-REQ / TGS-REP
71469	2022-09-27 08:48:14.019634	192.168.1.4	192.168.1.2	KRB5	197	TGS-REQ
71471	2022-09-27 08:48:14.020483	192.168.1.2	192.168.1.4	KRB5	1673	TGS-REP

TCP 3-way handshake between client and file server
1273	2022-09-27 08:48:14.003802	192.168.1.4	192.168.1.5	TCP	66	49704 → 445 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1274	2022-09-27 08:48:14.004065	192.168.1.5	192.168.1.4	TCP	66	445 → 49704 [SYN, ACK, ECN] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
1275	2022-09-27 08:48:14.004101	192.168.1.4	192.168.1.5	TCP	54	49704 → 445 [ACK] Seq=1 Ack=1 Win=2102272 Len=0

SMB Negotiate
1278	2022-09-27 08:48:14.004646	192.168.1.4	192.168.1.5	SMB2	232	Negotiate Protocol Request
1279	2022-09-27 08:48:14.005033	192.168.1.5	192.168.1.4	SMB2	366	Negotiate Protocol Response

SMB Session Setup
1309	2022-09-27 08:48:14.009403	192.168.1.4	192.168.1.5	SMB2	1750	Session Setup Request
1311	2022-09-27 08:48:14.010323	192.168.1.5	192.168.1.4	SMB2	314	Session Setup Response

SMB Tree Connect
1319	2022-09-27 08:48:14.012944	192.168.1.4	192.168.1.5	SMB2	176	Tree Connect Request Tree: \\fs01.contoso.com\test
1320	2022-09-27 08:48:14.013187	192.168.1.5	192.168.1.4	SMB2	138	Tree Connect Response

 

Packet을 통해서 AS-REQ / AS-REP, TGS-REQ / TGS-REP, AP-REQ / AP-REP 의 순서를 대략적으로 이해할 수 있습니다. 

※ AP-REQ / AP-REP의 경우 시나리오에 따라서 Packet에서 확인이 되지 않을 수 있습니다.

 

다음 Article에서 Kerberos Protocl Packet에 대한 자세한 Field들을 다뤄보도록 하겠습니다.