Windows 인증 과정3 (원격)

Windows 인증 과정1 (개요) : http://tribal1012.tistory.com/221

Windows 인증 과정2 (로컬) : http://tribal1012.tistory.com/222

-------------------------------------------------------------------------------------------------------------------------------------------

SPNEGO(Simple and Protected GSS-API Negotiation Mechanism)

  GSS-API를 사용하기 위해 협상하는 메커니즘이다. 절차에 따라 무사히 협상되게 되면 서버와 클라이언트는 서로가 같은 GSS(General Security Service)를 사용할 수 있고 이를 통해 암호화 등이 가능해진다.

※ MS에서는 GSS-API 인증 메커니즘을 사용하는 보안 프로토콜이라고 하고 있다.

SPNEGO(Simple and Protected GSS-API Negotiation Mechanism) 협상 절차

 

  설정된 메커니즘 컨텍스트에서 메시지별로 무결성 서비스를 이용할 수 있다고 가정한다.

1. GSS-API 게시 프로그램이 SPNEGO가 사용되도록 일반적으로 GSS_init_sec_context()를 호출한다. SPNEGO는 명시적으로 요청되거나 기본 메커니즘으로 허용되도록 할 수 있다.
2. GSS-API가 구현된 게시자는 컨텍스트 설정을 위해 사용되는 자격 증명 정보를 기반으로 이용 가능한 하나 이상의 보안 메커니즘 목록과 선택적으로 목록의 첫 번째 메커니즘을 위한 초기 보안 메커니즘 토큰이 포함되도록 협상 토큰을 생성한다. 

3. GSS-API 게시 어플리케이션은 토큰을 대상 어플리케이션에게 전송한다. GSS-API 대상 어플리케이션은 GSS_Accept_sec_context()를 호출함으로써 토큰을 전달한다. 
   
   

   게시자가 준비한 메커니즘이 허용되고, 낙관적인 메커니즘 토큰이 포함된 경우, 메커니즘 토큰은 GSS_Accept_sec_context()를 호출함으로써 선택된 메커니즘에게 전달되어야 한다. 응답 메커니즘 토큰이 반환된 경우, 응답 협상 토큰에 포함되어야 한다. 그렇지 않은 경우, 대상은 응답 메커니즘 토큰을 생성하지 않을 것이다.
   
   Acceptor는 다음 중에서 하나를 수행한다.
   

   • 제안된 메커니즘 중 어느 것도 받아들일 수 없는 경우, 그냥 종료된다. GSS_Accept_sec_context()는 GSS_S_BAD_MECH를 나타낸다. Acceptor는 reject 상태를 포함한 협상 토큰을 출력할 수 있다.
   • 개시자가 준비한 메커니즘이 대상에게 허용되지 않거나, 이 메커니즘이 허용되었지만 Acceptor가 선호하지 않는 메커니즘인 경우, GSS_Accept_sec_context는 GSS_S_CONTINUE_NEEDED를 나타낸다. Acceptor는 request-mic 상태를 포함한 협상 토큰을 출력해야 한다.
   • 그렇지 않은 경우, 컨텍스트 설정을 위해서 게시자로부터 최소한 하나의 추가 토큰이 요구된다. GSS_Accept_sec_context는 GSS_S_CONTINUE_NEEDED를 나타내고, Acceptor는 accept-incomplete 상태를 포함한 협상 토큰을 출력한다.
   • 그렇지 않은 경우, 컨텍스트 설정을 위해 게시자로부터 어떠한 추가 토큰도 요구되지 않는다. GSS_Accept_sec_context는 GSS_S_COMPLEGE를 나타내고, Acceptor는 accept-complete 상태를 포함한 협상 토큰을 출력한다.
4. GSS-API 대상 어플리케이션은 게시자 어플리케이션에게 협상 토큰을 반환한다. GSS-API 게시자 어플리케이션은 GSS_Init_sec_context()를 호출함으로써 토큰을 전달한다. 보안 컨텍스트 초기화는 선택된 메커니즘에 대한 표준 GSS-API 규약에 따라 계속된다. 선택된 메커니즘은 게시자와 대상 모두가 선택된 보안 메커니즘에 대해서 GSS_S_COMPLETE가 반환된 이후에 토큰은 협상 메시지의 어딘가에 캡슐화된다.
5. MIC 토큰은 그런 다음에 스킵되거나 섹션 5에 따라 교환된다.

  컨텍스트 설정을 위해 입력되는 *_req_flag 인자는 *_state 출력 인자와 같이 선택된 메커니즘과 관련있다. 이러한 인자는 협상 절차 차제에는 적용되지 않는다.

인증 패키지

Kerberos 인증 패키지

  로컬 로그인에 MSV1_0 인증 패키지가 사용되었다면, 네트워크 로그인(Windows Server를 생각해봐야 할 듯)은 Kerberos 인증 패키지가 사용된다. 인증 절차는 다음과 같다.

1. 사용자의 네트워크 계정의 로그온 데이터를 사용해 KDC(Key Distribute Center)에 연결해 TGT(Ticket Granted Ticked)을 부여 받는다.
   ※ KDC를 사용하지 못 한다면 MSV1_0 인증 패키지가 지원하는 도메인 컨트롤러 인증을 사용해 직접 인증을 한다.
2. TGT를 서버에 전송하여 서버와 연결을 맺는다.
3. 인증 완료

MSV1_0 인증 패키지(도메인 컨트롤러)

  MSV1_0 인증 패키지는 로컬 로그온 뿐만 아니라 도메인 로그온도 지원하는데 이 때 Netlogon 서비스를 사용한다.

1. 로컬 컴퓨터의 MSV1_0 인증 패키지는 도메인 컨트롤러 컴퓨터의 MSV1_0 인증 패키지를 Netlogon 서비스를 사용하여 호출한다. 
2. Netlogon 서비스를 통해 Credential을 도메인 컨트롤러의 MSV1_0 인증 패키지에 전달한다.
3. 도메인 컨트롤러의 MSV1_0 인증 패키지는 해당 PC의 LSA에 인증 정보를 전달한다.
4. LSA는 SAM에서 인증 정보가 일치하는지 확인한다.
5. 로그온 결과를 도메인 컨트롤러의 MSV1_0 인증 패키지에 전달한다.
6. 도메인 컨트롤러의 MSV1_0 인증 패키지는 결과를 로컬의 MSV1_0 인증 패키지로 Netlogon 서비스를 사용하여 전달한다.
7. 로컬의 MSV1_0 인증 패키지는 LSA에 해당 결과를 전달한다.

CredSSP 인증 패키지(RDP)

  CredSSP 인증 패키지는 RDP 서비스가 허용되었을 때, 인증 패키지에 등록된다. 기본적으로는 RDP 서비스가 허용되지 않기 때문에 볼 수 없다.

- https://tribal1012.tistory.com/231

참고

• Kerberos 기술 부록 : https://msdn.microsoft.com/en-us/library/ff649429.aspx
• 커버러스, SPNEGO : http://thekspace.com/home/component/content/article/54-kerberos-and-spnego.html
• SPNEGO RFC 문서 : https://www.rfc-editor.org/rfc/rfc4178.txt
• GSS 관련(서명 및 암호화) : https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.euvfb00/gsswrap.htm
• SPNEGO 토큰 설명 : https://msdn.microsoft.com/en-us/library/ms995330.aspx#http-sso-2_topic2