I. Kerberos vs. NTLM
NTLM 인증: Challenge-Response mechanism
1. 클라이언트가 서버로 사용자 이름을 보낸다.
2. 서버는 이에 대한 요청 값을 생성해 클라이언트로 보낸다.
3. 클라이언트는 이 요청 값을 사용자 암호로 암호화해 서버로 응답을 보낸다.
4. 로컬 계정인 경우 서버는 SAM(Security Account Manager)을 검색해 사용자의 응답을 검증한다.
5. 도메인 계정인 경우 서버는 이 응답을 도메인 컨트롤러로 전달해 검증하고 사용자 계정에 대한 그룹 정책을 받는다.
6. Access Token을 발급하고 세션을 맺는다.

Kerberos 인증: Trust-Third-Party Scheme
- Kerberos 인증 방법은 표준 프로토콜로 네트워크에서 클라이언트와 서버를 상호 인증하는 방식이다.
- 세 가지 주 요소는 KDC(Key Distribution Center), 클라이언트, 접근할 서비스를 가지는 서버
- KDC는 도메인 컨트롤러의 일부로서 설치되며 다음 두 가지 기능을 수행한다.
-- AS(Authentication Service), TGS(Ticket-Granting Service)

1. 사용자가 네트워크에 로그온하면 AS에 TGT(Ticket Grant Ticket)을 요청한다.
2. 클라이언트는 네트워크 자원에 접근할 때 TGT와 인증자(Authenticator), 대상 서버의 SPN(Service Principal Name)을 제시한다.
3. 클라이언트는 네트워크 서비스와의 통신에 사용될 세션 티켓을 받기위해 서비스 계정 도메인의 TGS에 접속한다.
4. 대상 서버가 인증자를 검증하고 나면 클라이언트 사용자에 대한 Access Token을 생성한다.


II. Kerberos와 NTLM 인증의 요구 사항
Kerberos
1. 클라이언트와 서버는 반드시 도메인 구성원이어야 한다. 만약 클라이언트와 서버가 서로 다른 도메인에 속하는 경우 두 도메인은 양방향 신뢰가 구성되어 있어야 한다.
2. SPN 등록. SPN은 서버에서 실행 중인 서비스에 대한 고유한 식별자다. Kerberos 인증을 필요로 하는 서비스는 SPN을 가지고 있어야 클라이언트가 네트워크에서 서비스를 식별할 수 있게 된다.

SPN(Service Principal Name)
SQL Server에 대한 SPN은 다음과 같은 요소로 구성된다.
- ServiceClass: 서비스를 식별하는 요소. SQL Server에 대한 Service Class는 MSSQLSvc이다.
- Host: SQL Server가 실행 중인 컴퓨터의 FQDN
- Port: 실행 중인 서비스가 수신 대기 중인 포트
예) MSSQLSvc/sqlserver.domain.com:1433

NTLM
NTLM은 요청-응답의 과정을 위해 사용자 암호를 요구한다. 이후 서버는 클라이언트로부터 암호를 요구하지 않고 클라이언트를 식별할 수 있게 된다. 만약 클라이언트가 시스템 계정으로 실행 중이라면 인증 정보를 보낼 수가 없기 때문에 인증은 실패하게 된다.

NTLM Fallback
NTLM(NT LAN Manager)는 Windows NT와 Windows 2000 Workgroup 환경에서 사용되던 인증 프로토콜이다.
Windows Server 2003, Windows XP, Windows 2000은 어느 인증 프로토콜을 사용할지 협상하는 알고리즘을 사용한다. Kerberos 프로토콜이 기본 값이며 Kerberos 인증이 실패할 경우 NTLM 인증을 시도한다.


III. SQL Server 2005에 접속 시 Kerberos와 NTLM
1. 만약 SPN이 존재하면 TCP/IP를 통한 원격 접속 시 Kerberos가 사용된다.
2. SPN이 존재하고 XP 컴퓨터의 로컬 TCP 연결을 하는 경우 Kerberos가 사용된다.
3. Windows Server 2003의 로컬 연결의 경우 NTLM이 사용된다.
4. 명명된 파이프 연결의 경우 NTLM이 사용된다.
5. SPN을 찾을 수 없고 TCP를 통해 연결하는 경우 NTLM이 사용된다.

SETSPN.EXE
1. SQL Server가 LocalSystem 또는 NetworkService 계정으로 실행 중인 경우 SPN 확인
SETSPN -L <SQL Server가 설치된 서버 이름>
2. SQL Server가 도메인 사용자 계정으로 실행 중인 경우 SPN 확인
SETSPN -L <도메인>\<사용자 계정>
3. 만약 도메인 계정이 관리자 계정이 아닌 상황에서 Kerberos 인증을 반드시 사용해야 하는 경우 SPN 등록
SETSPN -A <도메인>\<사용자 계정>
4. SQL Server는 다음 항목이 만족되는 경우 서비스 시작 시 자동으로 SPN을 등록한다. 아래 항목이 충족되지 않는 경우 Kerberos인증을 위해서는 SPN을 수동으로 등록해야만 한다.
- SQL Server가 LocalSystem 또는 Network Service 또는 도메인 관리자 계정으로 실행 중이다.
- TCP/IP 프로토콜이 활성화되어 있다.

일반적으로 클라이언트가 SQL Server로 TCP 연결을 맺는 경우 클라이언트의 SQL 드라이버는 SQL Server가 실행 중인 서버의 FQDN을 풀게된다. 그 다음 SQL Server의 SPN을 검색하고 협상 과정을 거쳐 KDC의 SPN 검증 여부에 따라 NTLM 또는 Kerberos를 사용해 인증을 시도한다. 만약 Kerberos 인증이 실패할 경우 NTLM 인증을 시도한다. 명명된 파이프로 접속하는 경우에는 SQL 드라이버는 빈 SPN을 생성해 NTLM 인증으로 인증을 시도한다.

AD Replication Design best practices
링크 속도와 네트워크 토폴로지의 이점을 가지기 위한 AD 토폴로지의 디자인

1. 느린 링크 속도에는 사이트 링크의 비용을 크게 설정한다.
    목적지로 가는 데에 사이트 링크의 비용에 따라 경로를 정하게 된다.
2. "dead spot"을 피한다. - 결과적으로 모든 사이트는 서로 연결되어야 한다.
    AD 디자인에 있어 격리된 사이트가 있어서는 안 된다.
3. 사이트 링크는 링크 당 두 개의 사이트만 있어야 한다.
   사이트 링크에 세 개 이상의 사이트가 있는 경우 DC failure 발생 시 예기치 않은 문제가 발생 할 수 있다.
4. 전체적인 복제의 흐름에 대해 도식화해야 한다. 도식화하면서 문제가 있는 부분을 알아낼 수도 있다.
5. 특별한 이유가 없는 이상 복제에 대한 일정을 설정하지 않고 문제가 없는지 완벽하게 테스트한다.
   일정을 수정하는 것이 후에 복제를 막는 결과를 낳을 수도 있다. (복제 간격은 복제 일정에 해당하는 경우에만 수행된다.)
6. AD를 Windows 2003 포리스트 기능 수준으로 사용한다.
   이는 모든 DC가 Windows Server 2003이고 모든 도메인이 Windows Server 2003 기능 수준이라는 것을 의미한다.
    이렇게 되면 Windows Server 2003의 장점인 Spanning tree 알고리즘과 압축 알고리즘을 사용할 수 있게 된다.
    이외에도 복제에 대해 Windows 2000 보다 더 효율적으로 동작한다.
7. Repladmin을 사용해 AD의 복제를 모니터 한다.
Repadmin /replsum /bydest /bysrc /sort:delta


효율적인 복제를 위한 Active Directory Tobology 정의
링크 속도를 기준으로 다음과 같이 Tier를 나눈다.
Site 1(Tier 1) – 가장 빠른 링크
Site 2(Tier 2) – 두 번째로 빠른 링크
Site 3(Tier 3) – 가장 느린 링크
* 한 개의 사이트 링크에 두 개의 사이트만 넣는다 *

http://support.microsoft.com/kb/179442/ko
Legacy 장비가 있는 경우 2000/2003 요구 Port 및 NT 요구 Port까지 열어야 한다.


Windows Server 2000 or 2003

Windows NT

1. 사용자는 User ID와 패스워드를 입력하여 Kerberos Server (Active Directory)에 인증 요청을 시도 한다.
2. Kerberos Server는 사용자와 Ticket-Granting 서버에 사용자가 입력한 패스워드에 기반하여 만든 Session key를 전달하며 추가적으로 사용자에게는 Ticket-Granting 서버에서 발급받은 발행일자, 시간 등이 적혀 있는 Ticket (아래 그림에서는 Service Ticket)을 전달받게 된다.
3. 이후 사용자는 접속하려는 Server로 Service 요청을 하게 되며 한번 Ticket을 부여 받았을 경우 설정에 따라 추가 인증 없이 자유롭게 이용할 수 있다. Active Directory 환경에서는 통상적으로 8시간 정도 유효하다.

System Management 컨테이너 생성
1. 도메인 관리자 권한으로 로그인
2. Support Tools 설치
3. ADSIEDIT 실행
4. Domain > Domain Name > CN=System
5. CN=System에 우클릭 -> New > Object
6. Class는 Container > Value는 System Management -> 생성

Domain Functional Level

(상위 기능 수준은 하위 기능 수준의 기능을 포함)

Forest Functional Level
(상위 기능 수준은 하위 기능 수준의 기능을 포함)