VPN을 통한 SQL Server가 여전히 NTLM으로 폴백하는 이유

연결은 작동하고 로그인도 허용되는데, 모두가 Kerberos를 기대했을 때 SQL Server는 NTLM을 사용하고 있습니다. 그 결과는 VPN 결함이 아닙니다. 터널은 경로만 제공하며, 스킴은 클라이언트가 요청한 이름, 디렉터리에 등록된 보안 주체, 클라이언트가 실제로 얻을 수 있었던 티켓이 결정했습니다. 세 가지 조건이 동시에 성립해야 하며, 어느 조건이 물러났는지는 세션 자체가 알려 줍니다. 누군가 서비스 주체 이름을 편집하기 전에 그것을 읽으십시오.

세션은 실제로 받은 스킴을 알려 준다

인증 스킴은 서버나 터널이 아니라 연결에 속하므로, 확인은 관심 있는 세션 내부에서 실행해야 합니다. 보고서를 생성한 것과 동일한 클라이언트, 도구, 계정에서 아래 쿼리를 실행하고 결과 옆에 대상 이름과 전송을 기록하십시오.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

데이터베이스 호스트의 로컬 SSMS 창에서 가져온 행은 전혀 다른 연결을 설명하므로 쿼리는 클라이언트 쪽에서 실행해야 합니다. 출력은 타임스탬프와 함께 저장하십시오. 다음에 읽는 사람이 언제 수집했는지 묻기 때문입니다. 여러 애플리케이션이 하나의 엔드포인트를 공유하면 각각에서 샘플을 채취하십시오. 두 애플리케이션 사이의 데이터 원본 차이가 종종 전부이기 때문입니다.

첫 번째 조건: 이름이 SPN과 일치하는가

Kerberos는 명명된 서비스를 인증하므로 클라이언트는 특정 보안 주체에 대한 티켓을 디렉터리에 요청합니다. TCP 공급자의 경우 문서화된 형식은 MSSQLSvc/ 뒤에 정규화된 호스트 이름이 오고, 기본 인스턴스의 경우 포트도 옵니다. 명명된 인스턴스는 MSSQLSvc/db01.corp.example:SQLPROD를 등록하며, 접미사는 숫자가 아니라 인스턴스 이름입니다. 별칭, 다른 곳에서 확인되는 CNAME 또는 순수 IP 주소를 통해 수신기에 도달하면 요청된 이름이 바뀌고, 일치하는 보안 주체가 없는 요청에는 돌려줄 티켓이 없습니다.

한 애플리케이션은 한 네트워크에서 작동하고 다른 네트워크에서는 폴백하는 이유가 여기에 있습니다. DNS 응답, 별칭 레코드 또는 hosts 항목이 클라이언트가 사용한 이름을 바꾼 것입니다. 등록을 건드리기 전에 요청된 이름을 디렉터리가 보유한 이름과 비교하십시오.

두 번째 조건: SPN이 올바른 계정에 있는가

SPN은 SQL 서비스를 실행하는 계정에 속해야 하며, 클라이언트 계정이나 우연히 컴퓨터 개체에 속해서는 안 됩니다. SQL Server는 서비스 계정에 쓰기 권한이 있으면 시작할 때 자체 SPN을 등록할 수 있는데, 이는 편리하며 서비스 계정 변경 후 중복이 나타나는 방식이기도 합니다.

예상하는 이름을 디렉터리에 질의한 다음 해당 계정이 실제로 소유한 항목을 나열하십시오. 어떤 개체가 항목을 보유하는지가 이름이 포리스트 어딘가에 존재하는지보다 중요합니다. 불일치는 로그인이 문제였던 적이 없음을 의미하며, Microsoft의 SPN 가이드는 형식과 도메인 관리자가 항목을 만들어야 하는 경우를 문서화합니다.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

항목을 하나 더 추가하는 것은 안전한 실험이 아닙니다. 중복되거나 충돌하는 등록은 작동하던 클라이언트를 깨뜨릴 수 있으므로 변경 전에 소유권을 검사하고 변경 후에 다시 확인하십시오.

세 번째 조건: 클라이언트가 티켓을 얻을 수 있는가

클라이언트가 도메인 컨트롤러에 도달하지 못하거나 사용 가능한 자격 증명 컨텍스트가 없으면 올바른 SPN도 소용없습니다. 교환에는 VPN을 통한 KDC와 DNS가 필요하며, SQL 포트만 라우팅하는 터널은 바로 이 단계에서 실패합니다. 도달 가능성은 앞에 있는 방화벽이 아니라 동일한 머신과 동일한 계정에서 테스트해야 합니다.

머신과 애플리케이션을 실행하는 계정 아래에서 티켓 캐시를 검사하십시오. 권한이 높은 창에서 얻은 머신 전체 목록은 다른 사용자로 실행되는 서비스에 대해 아무것도 말해 주지 않으며, 해당 사용자의 빈 캐시는 불편이 아니라 발견 사항입니다.

klist
klist -li 0x3e7

다음으로 폴백이 무엇을 해도 되는지 결정하십시오. 정책이 Kerberos를 요구하면 NTLM은 명시적으로 거부해야 합니다. 조용한 폴백은 구성 오류를 요구 사항을 위반하는 작동 연결로 바꾸기 때문입니다. 일부 애플리케이션에 NTLM이 허용된다면 그 애플리케이션을 명시하고 모든 NTLM 세션을 사고로 취급하지 마십시오.

시작 프로그램 변경은 하나의 변수이지 해결책이 아니다

다른 자격 증명으로 SSMS를 시작하면 의도하지 않은 아웃바운드 ID를 치료할 수 있으며, 이는 실제 문제 분류입니다. 대상 이름, 등록 또는 티켓 경로에 대해 아무것도 증명하지 않으며 서버가 수락한 것을 바꾸지도 않습니다.

비교를 통제하십시오. 동일한 엔드포인트, 동일한 공급자, 알려진 실행 컨텍스트를 유지하고, 그다음 스킴을 검사할 새 연결을 만드십시오. 수락된 로그인과 데이터베이스 권한은 별도로 확인하십시오. 액세스와 인증은 서로 다른 이유로 실패합니다.

Kerberos가 필수라면 첫 경로가 왜 폴백했는지 기록하고, 수정을 하나 적용하고, 동일한 클라이언트에서 쿼리를 다시 실행하십시오. 시작 프로그램 변경 후 쿼리가 성공한 것은 액세스의 증거이며, 인증 요구 사항이 충족되었다는 증거는 아직 아닙니다.