VPN은 연결되지만 SQL Server가 Windows 인증을 거부합니다

터널은 올라오고 서버는 ping에 응답하는데 데이터베이스 로그인은 여전히 인증 오류로 실패합니다. 이 조합은 VPN 연결에서 흔하며 네트워크가 고장 났다는 뜻은 아닙니다. 닿는 리스너와 승인된 로그인은 서로 다른 결과이기 때문입니다. 게이트웨이를 만족시킨 ID가 데이터베이스 클라이언트가 제시하는 ID와 같다는 보장은 없습니다. 어떤 계정이 도착했는지 밝히는 것이 이 작업의 전부입니다.

증상: 서버는 닿지만 로그인이 거부됨

시간 초과는 패킷이 어떤 리스너에도 닿지 않았다는 뜻입니다. 인증 오류는 리스너가 응답하고 자격 증명을 거부했다는 뜻입니다. 이 두 메시지는 서로 다른 팀으로 보내야 하며, 섞으면 문제도 아니었던 방화벽 규칙에 하루를 쓰게 됩니다.

오류가 로그인 실패라면 포트를 보는 일을 멈추십시오. 남은 질문은 클라이언트가 어떤 Windows ID를 제시했는지, 서버가 그 ID를 받아들였는지, 그리고 권한이 있는 데이터베이스 사용자로 해석되었는지입니다.

두 개의 ID, 하나의 터널

VPN 계정은 게이트웨이에서 인증되고 대부분의 배포에서는 거기서 끝납니다. 데이터베이스 클라이언트는 별도로 Windows 토큰을 제시하는데, 이는 자신을 실행하는 프로세스에서 가져오며, 연결 문자열이 요구하면 SQL 로그인을 제시합니다. 게이트웨이 로컬 VPN 사용자는 SQL Server를 호스팅하는 도메인과 아무 관계가 없고, 터널이 그런 관계를 만들지도 않습니다.

개인 컴퓨터를 VPN에 연결한다고 해서 도메인에 가입되는 것도 아닙니다. 로컬 계정의 이름을 바꾸고 암호를 도메인 사용자와 맞춘다고 해서 가입 절차가 되는 것이 아니며, 도메인 컨트롤러가 그 사용자로 받아들이지 않을 토큰이 만들어집니다.

일부 Windows 네이티브 원격 액세스 클라이언트는 프로필이 그렇게 구성되어 있으면 네트워크 리소스에 VPN 자격 증명을 재사용할 수 있습니다. 그 동작은 특정 클라이언트와 프로필에 속하며 VPN 연결 일반의 성질이 아니므로, 가정하지 말고 사용 중인 클라이언트에서 확인하십시오.

클라이언트가 요청한 모드를 읽으십시오

연결 문자열이 클라이언트가 택할 인증 경로를 결정합니다. 통합 보안은 Windows 토큰을 사용하고, 사용자와 암호 쌍은 SQL 로그인을 선택합니다. 이들은 서버 구성에서 별개의 모드이며, 특정 연결 시도에서는 둘 중 하나만 활성화할 수 있습니다.

Server=tcp:sql.lab.example,1433;Database=ops;Integrated Security=SSPI;Encrypt=True;TrustServerCertificate=False;

Windows 로그인이 실패했다고 SQL 로그인으로 바꾸는 것은 ID 문제를 가리는 우회책이며, 보통은 새 로그인과 암호를 결국 만들어야 합니다. 배포가 Windows 인증을 요구한다면 모드를 유지하고 ID 경로를 고치십시오. SQL 로그인에도 자체 권한이 필요하므로 우회책은 유지할 두 번째 계정을 사는 셈입니다.

어떤 애플리케이션이 연결하는지도 확인하십시오. 시스템 계정으로 실행되는 서비스, 예약된 작업, 대화형 쿼리 창은 같은 컴퓨터에서 서로 다른 세 개의 토큰을 제시할 수 있으며, 마지막 하나만 사용자가 whoami 를 실행할 때 보는 것과 일치합니다.

서버가 실제로 무엇을 보았는지 물으십시오

서버는 어떤 로그인을 해석했는지, 연결이 어떻게 인증되었는지 알려 줄 수 있습니다. 조사 중인 세션 안에서 쿼리를 실행하십시오. 관리자의 별도 성공 연결은 실패하는 클라이언트에 대해 아무것도 증명하지 않습니다.

SELECT ORIGINAL_LOGIN() AS original_login,
       SUSER_SNAME() AS current_context;
SELECT auth_scheme, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

첫 번째 행은 세션을 연 로그인과 현재 적용되는 보안 컨텍스트를 구분하며, 가장 아래에서는 이 둘이 다릅니다. 두 번째는 인증 스킴을 지목하므로 KERBEROS, NTLM, SQL 이 추측이 아니라 눈에 보이는 사실이 됩니다. Kerberos 를 기대한 곳에서 NTLM 을 보고하는 연결은 암호 문제가 아니라 이름 확인이나 SPN 문제입니다.

오류 번호가 범위를 더 좁힙니다. 상태 5 는 보통 로그인 이름이 전혀 해석되지 않았다는 뜻이고, 상태 8 은 보통 암호가 맞지 않았다는 뜻이며, 상태 11 은 자격 증명은 받아들여졌지만 서버 접근이 실패했다는 뜻입니다. 전체 메시지 대신 상태를 관리자에게 물으십시오. 메시지만으로는 의도적으로 모호합니다.

ID가 도착해도 Kerberos 가 계속 실패할 때

서버가 의도한 Windows ID를 보고 있는데 통합 인증이 계속 실패한다면 교환 자체가 문제입니다. Kerberos 는 SQL 서비스 계정에 등록된 서비스 주체 이름과 그에 맞는 이름으로 서비스를 요청하는 클라이언트를 필요로 합니다. IP 주소로 연결하면 이름 기반 SPN 과 맞을 수 없고, 별칭은 그것도 등록되어 있을 때만 맞을 수 있습니다. 무엇보다 먼저 클라이언트가 입력한 이름을 확인하십시오. 호스트 이름으로는 되고 IP 로는 실패하는 연결이 바로 이 문제를 설명합니다.

관리자에게는 시행착오로 중복 SPN 을 만들지 말고 등록된 ID와 서비스 계정을 검토해 달라고 요청하십시오. 중복 등록은 간헐적 장애를 만들어 원래 문제보다 진단하기 어렵게 합니다.

인증이 동작한 뒤에도 로그인에는 데이터베이스 사용자와 권한이 필요합니다. VPN 로그인 성공, Windows 로그인 성공, 특정 테이블을 읽을 권한은 서로 다른 세 가지 결과이며, 티켓을 닫기 전에 각각 따로 확인할 가치가 있습니다.