Windows 인증을 사용하여 SQL Server에 연결할 때 "SSPI 컨텍스트를 생성할 수 없습니다" 오류

적용 대상: SQL Server
원래 KB 번호: 811889

Windows 인증을 사용하여 SQL Server 인스턴스를 원격으로 연결할 때 다음 오류 메시지가 나타납니다.

대상 사용자 이름이 잘못되었습니다. SSPI 컨텍스트를 생성할 수 없습니다.

자주 묻는 질문

SSPI란?

SSPI(Security Support Provider Interface)는 TCP/IP 소켓과 같은 일반 데이터 전송 계층을 통해 위임 및 상호 인증을 허용하는 Windows API 세트입니다. 하나 이상의 소프트웨어 모듈이 실제 인증 기능을 제공합니다. 각 모듈을 SSP(Security Support Provider)라고 하며 DLL(Dynamic Link Library)로 구현됩니다.

Kerberos란?

Kerberos v5 프로토콜은 업계 표준 보안 패키지이며 Windows 운영 체제의 세 가지 보안 패키지 중 하나입니다. 자세한 내용은 SSP(Security Support Provider)를 참조하세요.

"SSPI 컨텍스트를 생성할 수 없습니다" 오류는 무엇을 의미합니까?

이 오류는 SSPI가 TCP/IP 또는 명명된 파이프를 통해 SQL Server에 클라이언트 자격 증명을 위임하기 위해 Kerberos 인증을 시도하지만 사용할 수 없음을 의미합니다. 대부분의 경우 잘못 구성된 SPN(서비스 사용자 이름)으로 인해 이 오류가 발생합니다.

SPN이란?

SPN(서비스 사용자 이름)은 서비스 인스턴스의 고유 식별자입니다. SPN은 Kerberos 인증에서 서비스 인스턴스를 서비스 로그온 계정과 연결하는 데 사용됩니다. 이 연결 프로세스를 사용하면 클라이언트에 계정 이름이 없는 경우에도 클라이언트 애플리케이션이 서비스에 계정 인증을 요청할 수 있습니다.

예를 들어 SQL Server 인스턴스를 실행하는 서버의 일반적인 SPN은 다음과 같습니다.

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

기본 인스턴스의 SPN 형식은 명명된 인스턴스의 SPN과 동일합니다. 포트 번호는 SPN을 특정 인스턴스에 연결하는 것입니다. SQL Server 서비스 SPN 등록에 대한 자세한 내용은 Kerberos 연결을 위한 서비스 사용자 이름 등록을 참조하세요.

SSPI에서 NTLM 또는 Kerberos 인증을 사용하는 이유는 무엇인가요?

Windows 인증은 사용자가 SQL Server에 인증하기 위해 선호하는 방법입니다. Windows 인증을 사용하는 클라이언트는 NTLM 또는 Kerberos를 사용하여 인증됩니다.

SQL Server 클라이언트가 TCP/IP 소켓을 통해 SQL Server를 실행하는 원격 서버에 대한 통합 보안을 사용하는 경우 SQL Server 클라이언트 네트워크 라이브러리는 SSPI API를 사용하여 보안 위임을 수행합니다. SQL Server 네트워크 클라이언트는 AcquireCredentialsHandle 함수를 호출하고 pszPackage 매개 변수에 대해 "협상"을 전달합니다. 이 프로세스는 기본 보안 공급자에게 위임을 협상하도록 알려줍니다. 여기서 "협상"은 Windows 기반 컴퓨터에서 Kerberos 또는 NTLM 인증을 시도하는 것을 의미합니다. 즉, SQL Server를 실행하는 대상 컴퓨터에 연결되고 올바르게 구성된 SPN이 있는 경우 Windows는 Kerberos 위임을 사용합니다. 그렇지 않으면 Windows에서 NTLM 위임을 사용합니다. SQL Server 클라이언트가 SQL Server가 있는 동일한 시스템에서 로컬로 연결하는 경우 NTLM이 항상 사용됩니다.

Kerberos 문제가 발생한 후 연결이 NTLM으로 장애 조치되지 않는 이유는 무엇입니까?

클라이언트의 SQL Server 드라이버 코드는 드라이버가 Windows 인증을 사용하여 SQL Server에 연결할 때 서버의 정규화된 DNS를 확인하기 위해 WinSock 네트워크 API를 사용합니다. 이 작업을 수행하기 위해 드라이버 코드는 gethostbyname 및 gethostbyaddr WinSock API를 호출합니다. 통합 보안을 사용하는 경우 드라이버는 IP 주소 또는 호스트 이름이 서버 이름으로 전달되더라도 서버의 정규화된 DNS를 확인하려고 시도합니다.

클라이언트의 SQL Server 드라이버가 서버의 정규화된 DNS를 확인하면 해당 DNS가 서버의 SPN을 형성하는 데 사용됩니다. 따라서 WinSock에서 IP 주소 또는 호스트 이름을 정규화된 DNS로 확인하는 문제로 인해 SQL Server 드라이버가 서버에 대해 잘못된 SPN을 만들 수 있습니다.

예를 들어 클라이언트 쪽 SQL Server 드라이버는 다음과 같이 잘못된 SPN을 해결하기 위해 정규화된 DNS로 사용될 수 있습니다.

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

SQL Server 드라이버가 잘못된 SPN을 형성하면 SSPI 인터페이스가 Active Directory 서비스에서 SPN 조회를 시도하기 때문에 인증이 계속 작동합니다. SSPI 인터페이스에서 SPN을 찾지 못하면 Kerberos 인증이 이루어지지 않습니다. 이 시점에서 SSPI 계층은 NTLM 인증 모드로 전환되고 로그온은 NTLM 인증을 사용하며 일반적으로 성공합니다. SQL Server 드라이버가 적절한 컨테이너에 할당되지 않은 유효한 SPN을 형성하는 경우 드라이버는 SPN을 시도하지만 사용할 수 없습니다. 이 경우 "SSPI 컨텍스트를 생성할 수 없음" 오류가 발생할 수 있습니다. SQL Server 시작 계정이 로컬 시스템 계정인 경우 적절한 컨테이너는 컴퓨터 이름입니다. 다른 계정의 경우 적절한 컨테이너는 SQL Server 시작 계정입니다. 인증은 검색한 첫 번째 SPN을 사용하므로 잘못된 컨테이너에 SPN이 할당되지 않았는지 확인합니다. 즉, 각 SPN은 하나의 컨테이너에만 할당되어야 합니다.

연결의 인증 방법을 확인하려면 어떻게 해야 하나요?

연결의 인증 방법을 확인하려면 다음 쿼리를 실행합니다.

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

자세한 내용은 Kerberos 인증을 사용하여 SQL Server에 연결되었는지 여부를 확인하세요.

SQL Server 대한 SPN을 만드는 방법

SQL Server 데이터베이스 엔진의 인스턴스가 시작되면 SQL Server DsWriteAccountSpn API를 사용하여 SQL Server 서비스에 대한 SPN을 자동으로 등록하려고 시도합니다. 이 호출은 SQL Server 서비스 계정에 Active Directory의 읽기 servicePrincipalName 및 쓰기 servicePrincipalName 권한이 있는 경우 성공합니다. 그렇지 않으면 Active Directory 관리자가 microsoft Kerberos Manager for SQL Server 또는 기본 제공 Setspn 도구를 사용하여 올바른 SPN을 수동으로 등록해야 합니다. SQL Server용 SPN 관리에 대한 자세한 내용은 Kerberos 연결에 대한 서비스 주체 이름 등록을 참조하세요.

Kerberos 구성 관리자 오류 수정(권장)

잘못 구성된 SPN, 이름 확인 문제 또는 SQL Server 서비스 시작 계정에 대한 권한 부족 등 Kerberos 연결이 실패하는 여러 가지 이유가 있습니다. Microsoft Kerberos Configuration Manager(KCM)는 오류의 원인을 확인하는 데 도움이 되는 도구입니다. KCM은 프로세스에서 식별된 문제를 해결하는 옵션도 제공합니다.

다음 단계에 따라 KCM을 사용하여 오류를 해결합니다.

1. 연결 문제가 있는 컴퓨터에서 Kerberos 구성 관리자를 다운로드하여 설치합니다.

2. %SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager 폴더에서 KerberosConfigMgr.exe를 시작합니다. 그런 다음 연결할 수 없는 SQL Server 컴퓨터에 연결할 수 있는 권한이 있는 도메인 계정을 사용합니다.

3. SQL Server 컴퓨터에서 KCM을 실행하는 경우 서버 이름 및 기타 세부 정보를 시나리오에 적용할 수 있는 빈 상태로 두고 연결을 선택합니다. 연결을 선택하여 분석을 수행합니다. KCM이 필요한 정보 검색을 완료하면 자동으로 SPN 탭으로 전환되고 기본적으로 SQL Server, SQL Server Reporting Services, Analysis Services 및 AG 수신기에 대한 정보가 표시됩니다. 이 오류를 해결하려면 SQL Server 제외한 모든 항목을 선택 취소합니다.

4. 상태 열을 사용하여 도구에서 진단을 검토하고 관련 단계에 따라 문제를 해결합니다.

   상태	추가 정보	작업
   좋아요	선택한 항목이 제대로 구성되었습니다. 출력에서 다음 항목으로 진행할 수 있습니다.	필요한 작업은 없습니다.
   필수 SPN이 없습니다.	이 상태는 Active Directory의 SQL Server 시작 계정에 대해 필수 SPN 열에서 식별된 SPN이 누락된 경우 보고됩니다.	1. 수정을 선택하여 경고 대화 상자의 정보를 검토합니다. 2. Active Directory에 누락된 SPN을 추가하려면 예를 선택합니다. 3. 도메인 계정에 Active Directory를 업데이트하는 데 필요한 권한이 있는 경우 필요한 SPN이 Active Directory에 추가됩니다. 4. 도메인 계정에 Active Directory를 업데이트하는 데 필요한 권한이 없는 경우 생성 또는 모두 생성 을 사용하여 Active Directory 관리자가 누락된 SPN을 추가하는 데 도움이 되는 스크립트를 생성합니다. 5. SPN이 추가된 후 Kerberos 구성 관리자를 다시 실행하여 SPN 문제가 해결되었는지 확인합니다. 6. 또한 다음 명령을 사용할 수 있습니다. - 를 사용하여 SETSPN -Q spnName SPN 및 해당 현재 계정을 찾습니다. - 잘못된 계정에서 SPN을 제거하는 데 사용합니다 SETSPN -D .
   Kerberos 구성을 사용하려면 TCP를 사용하도록 설정해야 합니다.	이 문제는 클라이언트 컴퓨터에서 TCP를 사용하도록 설정하지 않은 경우에 발생합니다.	SQL Server 인스턴스에 대해 TCP/IP 프로토콜을 사용하도록 설정하려면 다음 단계를 수행합니다. 1. SQL Server 구성 관리자 콘솔 창에서 SQL Server 네트워크 구성을 확장합니다. 2. 콘솔 창에서 instance 이름>에 대한 프로토콜을 <선택합니다. 3. 세부정보 창에서 TCP/IP를 마우스 오른쪽 버튼으로 클릭한 다음 활성화를 선택합니다. 4. 콘솔 창에서 SQL Server 서비스를 선택합니다. 5. 세부 정보 창에서 SQL Server(<instance 이름>)을 마우스 오른쪽 단추로 클릭한 다음 다시 시작을 선택하여 SQL Server 서비스를 중지하고 다시 시작합니다. 자세한 내용은 서버 네트워크 프로토콜 사용 또는 사용 안 함을 참조하세요.
   동적 포트	이 메시지는 동적 포트(기본 구성)를 사용하는 명명된 인스턴스에 대해 표시됩니다. Kerberos를 사용하여 SQL Server 연결해야 하는 환경에서는 명명된 인스턴스를 정적 포트로 설정하고 SPN을 등록할 때 이 포트를 사용해야 합니다.	정적 포트를 사용하도록 SQL Server 인스턴스를 구성하려면 다음 단계를 수행합니다. 1. SQL Server 구성 관리자 콘솔 창에서 SQL Server 네트워크 구성을 확장하고 instance 이름>에 대한 <프로토콜을 확장한 다음 TCP/IP를 두 번 클릭합니다. 2. TCP/IP 속성 대화 상자의 프로토콜 탭에서 모두 수신 대기 설정을 확인합니다. 3. 모두 수신 대기 설정이 예로 설정된 경우 IP 주소 탭으로 전환하고 Windows 아래쪽으로 스크롤하여 IPAll 설정을 찾습니다. TCP 동적 포트에 있는 현재 값을 삭제하고 TCP 포트 필드에서 원하는 값을 설정합니다. 확인을 선택하고 SQL Server 인스턴스를 다시 시작하여 설정을 적용합니다. 4. 모두 수신 대기 설정이 아니요로 설정된 경우 IP 주소 탭으로 전환하고 IP1, IP2에 표시되는 각 IP 주소를 확인합니다. 활성화된 IP 주소의 경우 TCP 동적 포트 필드에 있는 현재 값을 제거하고 TCP 포트 필드에서 원하는 값을 설정합니다. 확인을 선택하고 SQL Server 인스턴스를 다시 시작하여 설정을 적용합니다. 자세한 내용은 특정 TCP 포트에서 수신 대기하도록 서버 구성을 참조하세요.
   중복 SPN	Active Directory에서 동일한 SPN이 다른 계정으로 등록되는 상황이 발생할 수 있습니다.	1. 수정 단추를 선택하고 경고 대화 상자에서 정보를 확인한 후 누락된 SPN을 Active Directory에 추가할 수 있으면 예를 선택합니다. 2. 도메인 계정에 Active Directory를 업데이트하는 데 필요한 권한이 있는 경우 잘못된 SPN이 삭제됩니다. 3. 도메인 계정에 Active Directory를 업데이트하는 데 필요한 권한이 없는 경우 생성 또는 모두 생성 단추를 사용하여 사용자에게 전달할 수 있는 필요한 스크립트를 생성합니다. Active Directory 관리자가 중복 SPN을 제거합니다. SPN이 제거되면 KCM을 다시 실행하여 SPN 문제가 해결되었는지 확인합니다.

   참고

   KCM을 시작하는 도메인 계정에 Active Directory에서 SPN을 조작할 권한이 없는 경우, SPN 스크립트 열 아래에 있는 해당 생성 또는 모두 생성 단추를 사용하여 필요한 명령을 생성하고 Active Directory 관리자와 협력하여 KCM에서 식별한 문제를 해결할 수 있습니다.

5. KCM에서 식별된 모든 문제를 해결한 후 도구를 다시 실행합니다. 다른 문제가 보고되지 않았는지 확인하고 다시 연결합니다. 도구에서 여전히 문제를 보고하는 경우라면 이전 절차를 반복합니다.

Kerberos 구성 관리자 없이 오류 수정

KCM을 사용할 수 없는 경우 다음 단계를 수행합니다.

1단계: Ping 명령을 사용하여 이름 확인

Kerberos 인증을 성공시키는 핵심 요소는 네트워크에서 유효한 DNS 기능입니다. Ping 명령 프롬프트 유틸리티를 사용하여 클라이언트와 서버에서 이 기능을 확인할 수 있습니다. 클라이언트 컴퓨터에서 다음 명령을 실행하여 SQL Server를 실행하는 서버의 IP 주소를 가져옵니다(여기서 컴퓨터 이름은 SQLServer1입니다).

ping sqlserver1

Ping 유틸리티가 SQLServer1의 정규화된 DNS를 확인하는지 확인하려면 다음 명령을 실행합니다.

ping -a <IPAddress>

예시:

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

ping -a <IPAddress> 명령이 SQL Server를 실행하는 컴퓨터의 올바른 정규화된 DNS로 확인되면 클라이언트 쪽 확인도 성공한 것입니다.

자세한 진단을 위해 Test-NetConnection 또는 Test-Connection cmdlet을 사용하여 컴퓨터에 설치된 PowerShell 버전에 따라 TCP 연결을 테스트합니다. PowerShell cmdlet에 대한 자세한 내용은 Cmdlet 개요를 참조하세요.

대상 SQL Server의 별칭이 SQL Server 구성 관리자와 SQL Server 클라이언트 네트워크 유틸리티에 있는지 확인합니다. 이러한 별칭이 있는 경우 서버 이름, 네트워크 프로토콜, 포트 번호 등을 확인하여 올바르게 구성되었는지 확인합니다. SQL Server 별칭으로 인해 예기치 않은 SPN이 생성될 수 있습니다. 이렇게 하면 SPN을 찾을 수 없거나 실수로 다른 서버의 SPN과 일치하는 경우 SSPI 오류가 발생하는 경우 NTLM 자격 증명이 발생합니다.

2단계: 도메인 간 통신 확인

로그인한 도메인이 SQL Server를 실행하는 서버의 도메인과 통신할 수 있는지 확인합니다. 또한 도메인에 올바른 이름 확인이 있어야 합니다.

1. SQL Server 서비스 시작 계정과 동일한 도메인 계정 및 암호를 사용하여 Windows에 로그인할 수 있는지 확인합니다. 예를 들어 SSPI 오류는 다음 상황 중 하나에서 발생할 수 있습니다.

   • 도메인 계정이 잠겨 있습니다.
   • 계정의 암호가 변경된 후 SQL Server 서비스를 다시 시작하지 않았습니다.

2. 로그온 도메인이 SQL Server를 실행하는 서버의 도메인과 다른 경우 도메인 간의 트러스트 관계를 확인합니다.

3. 서버가 속한 도메인과 연결에 사용하는 도메인 계정이 같은 포리스트에 있는지 확인합니다. SSPI가 작동하려면 이 단계가 필요합니다.

3단계: SQLCHECK 및 Setspn 도구를 사용하여 SQL Server SPN 확인

SQL Server 컴퓨터에 로컬로 로그인하고 관리자 액세스 권한이 있는 경우 SQLCHECK를 사용합니다. SQLCheck는 문제 해결에 필요한 대부분의 정보를 하나의 파일로 제공합니다. 도구를 사용하는 방법과 도구가 수집하는 정보에 대한 자세한 내용은 도구의 홈 페이지를 확인하세요. 권장되는 전제조건 및 체크리스트 페이지도 확인할 수 있습니다. 출력 파일을 생성한 후에는 출력 파일의 SQL Server 정보 섹션에서 SQL Server 인스턴스에 대한 SPN 구성을 확인합니다.

출력 예제:

Suggested SPN                                               Exists  Status              

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

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

위의 출력을 사용하여 다음 단계를 결정하고(아래 예 참조) Setspn 도구를 사용하여 SPN 문제를 수정하는 데 필요한 조치를 취합니다.

4단계: 연결된 서버에서 SQL Server 시작 계정에 대한 계정 권한 확인

연결된 서버의 보안 페이지에서 인증 옵션으로 가장을 사용하는 경우 SQL Server는 들어오는 자격 증명을 원격 SQL Server에 전달해야 합니다. 연결된 서버가 정의된 SQL Server 시작 계정에는 Active Directory에서 할당된 위임에 대해 신뢰할 수 있는 계정 권한이 있어야 합니다. 자세한 내용은 컴퓨터 및 사용자 계정을 위임용으로 신뢰할 수 있도록 설정을 참조하세요.

참고 항목

• SQL Server의 연결 문제 해결
• 일관된 인증 문제 해결
• SSPI 클라이언트 도구
• Kerberos 이벤트 로깅 사용
• Windows에서 Kerberos가 UDP 대신 TCP를 사용하도록 강제하는 방법