로그인

Select the product you need help with

"SSPI 컨텍스트를 생성할 수 없습니다." 오류 메시지 문제 해결 방법

기술 자료: 811889 - 이 문서가 적용되는 제품 보기.

Small Business를 사용하는 고객은 Small Business 지원
(http://smallbusiness.support.microsoft.com)
사이트에서 추가적인 문제 해결 방법 및 학습 리소스를 찾을 수 있습니다.

모두 확대 | 모두 축소

요약

이 문서에서는 "SSPI 컨텍스트를 생성할 수 없습니다." 오류 메시지의 가장 일반적인 원인을 해결하는 방법을 단계별로 설명합니다. 아래와 같은 조건에 해당하면 이 오류 메시지가 나타날 수 있습니다.

SQL Server에 연결되어 있습니다.
통합 보안을 사용하고 있습니다.
Kerberos를 사용하여 보안 위임을 수행하고 있습니다.

Kerberos 용어 및 서비스 사용자 이름 이해

클라이언트 컴퓨터의 SQL Server 드라이버는 통합 보안을 통해 사용자 계정의 Windows 보안 토큰을 사용하여 SQL Server를 실행하고 있는 컴퓨터에 연결합니다. Windows 보안 토큰은 클라이언트에서 SQL Server를 실행하는 컴퓨터로 위임됩니다. SQL Server 드라이버는 다음 구성 중 하나를 통해 사용자의 보안 토큰이 한 컴퓨터에서 다른 컴퓨터로 위임될 때 이러한 위임을 수행합니다.

SSPI(보안 지원 공급자 인터페이스)를 사용하지 않는 명명된 파이프를 통한 NTLM
SSPI를 사용하는 TCP/IP 소켓을 통한 NTLM
SSPI를 사용하는 TCP/IP 소켓을 통한 Kerberos

SSPI(보안 지원 공급자 인터페이스)는 TCP/IP 소켓 같은 일반적인 데이터 전송 계층을 통해 위임과 상호 인증을 허용하는 Windows API의 집합입니다. 따라서 SSPI를 사용하면 Windows 운영 체제를 실행하는 컴퓨터가 원시 데이터 바이트를 전송할 수 있는 전송 계층을 통해 한 컴퓨터에서 다른 컴퓨터로 사용자 보안 토큰을 안전하게 위임할 수 있습니다.

SSPI가 Kerberos를 사용하여 TCP/IP를 통해 위임하는 경우 Kerberos가 SQL Server를 실행하는 대상 컴퓨터로 사용자 보안 토큰을 위임하는 데 필요한 작업을 완료할 수 없으면 "SSPI 컨텍스트를 생성할 수 없습니다."라는 오류가 생성됩니다.

보안 지원 공급자 인터페이스에서 NTLM이나 Kerberos를 사용하는 이유

Kerberos는 "서비스 사용자 이름"(SPN)이라는 ID를 사용합니다. SPN은 네트워크 서버 리소스에 있는 일부 인스턴스의 도메인 또는 포리스트 고유 ID로 간주할 수 있습니다. 웹 서비스, SQL 서비스 또는 SMTP 서비스에 대한 SPN이 있을 수 있으며 고유한 SPN을 가진 한 컴퓨터에 웹 서비스 인스턴스가 여러 개 있을 수도 있습니다.

SQL Server의 SPN은 다음 요소로 구성되어 있습니다.

ServiceClass: 서비스의 일반 클래스를 나타냅니다. SQL Server의 경우 항상 MSSQLSvc입니다.
Host: SQL Server를 실행하는 컴퓨터의 정규화된 DNS입니다.
Port: 서비스가 수신 대기하는 포트 번호입니다.

예를 들어, SQL Server를 실행하는 컴퓨터의 SPN은 일반적으로 다음과 같습니다.

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

기본 인스턴스의 SPN 형식과 명명된 인스턴스 SPN 형식은 서로 같습니다. 포트 번호를 통해 SPN을 특정 인스턴스에 연결합니다.

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

클라이언트의 SQL Server 드라이버가 SQL Server를 실행하는 컴퓨터의 정규화된 DNS를 확인하면 해당 DNS가 이 컴퓨터의 SPN을 만드는 데 사용됩니다. 따라서 WinSock을 통해 IP 주소나 호스트 이름을 정규화된 DNS로 확인하는 방식에서 문제가 발생하면 SQL Server 드라이버가 SQL Server를 실행하는 컴퓨터에 대해 잘못된 SPN을 만들 수 있습니다.

예를 들어, 클라이언트 쪽 SQL Server 드라이버가 확인된 정규화된 DNS로 만들 수 있는 잘못된 SPN은 다음과 같습니다.

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을 조회하려고 하기 때문에 인증은 계속 수행되지만 SPN을 찾지는 못합니다, SSPI 인터페이스에서 SPN을 찾지 못하면 Kerberos 인증은 수행되지 않습니다. 이 시점에서 SSPI 레이어는 NTLM 인증 모드로 전환되며 로그온할 때 NTLM 인증을 사용하면 일반적으로 성공합니다. SQL Server 드라이버가 올바른 SPN을 만들어도 적합한 컨테이너에 할당되지 않으면, 이 드라이버가 SPN을 사용하려고 해도 사용할 수 없으며 "SSPI 컨텍스트를 생성할 수 없습니다." 오류 메시지가 나타납니다. SQL Server 시작 계정이 로컬 시스템 계정인 경우 적합한 컨테이너는 컴퓨터 이름이며 다른 모든 계정의 경우 적합한 컨테이너는 SQL Server 시작 계정입니다. 인증에서는 처음으로 발견된 SPN을 사용하려고 하기 때문에 적합한 컨테이너에 SPN이 할당되었는지 확인해야 합니다. 다시 말해 각 SPN은 하나의 컨테이너에만 할당되어야 합니다.

Kerberos 인증이 성공적으로 수행되려면 네트워크에서 DNS 기능이 올바로 작동해야 합니다. Ping 명령줄 유틸리티를 사용하여 클라이언트와 서버에서 이 기능을 확인할 수 있습니다. 클라이언트 컴퓨터에서 다음 명령을 실행하여 SQL Server를 실행하는 서버의 IP 주소를 얻습니다. 여기서 SQL Server를 실행하는 컴퓨터의 이름은 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=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply 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=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Reply from 123.123.123.123: bytes=32 time<10ms TTL=128Ping 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로 확인되면 클라이언트쪽 확인도 성공적으로 수행됩니다.

SQL Server 서비스 사용자 이름 만들기

이 작업은 Kerberos와 SQL Server 상호 작용에서 필수적인 부분 중 하나입니다. SQL Server에서 LocalSystem 계정, 로컬 사용자 계정 또는 도메인 사용자 계정 중 하나로 SQL Server 서비스를 실행할 수 있습니다. SQL Server 서비스 인스턴스가 시작되면 DsWriteAccountSpn API 호출을 사용하여 Active Directory에 고유 SPN을 등록하려고 합니다. 호출이 성공하지 못하면 다음과 같은 경고가 이벤트 뷰어에 기록됩니다.

원본: MSSQLServer 이벤트 ID: 19011 설명: SuperSocket 정보: (SpnRegister) : 오류 8344.

DsWriteAccountSpn 함수에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 방문하십시오.

http://msdn2.microsoft.com/en-us/library/ms676056.aspx

(http://msdn2.microsoft.com/en-us/library/ms676056.aspx)

(영문)

간단한 설명

LocalSystem 계정으로 SQL Server 서비스를 실행하면 SPN이 일반적으로 등록되고 Kerberos가 SQL Server를 실행하는 컴퓨터와 성공적으로 상호 작용합니다. 하지만 도메인 계정이나 로컬 계정으로 SQL Server 서비스를 실행하는 경우, 도메인 계정과 로컬 계정에는 고유 SPN을 설정할 수 있는 권한이 없으므로 대부분의 경우 SPN을 만들지 못합니다. SPN을 만들지 못한다는 것은 SQL Server를 실행하는 컴퓨터에 대해 설정된 SPN이 없음을 의미합니다. SQL Server 서비스 계정으로 도메인 관리자 계정을 사용해 보면 SPN을 만드는 데 필요한 도메인 관리자 수준의 자격 증명이 있기 때문에 SPN이 성공적으로 만들어집니다.

보안 위험을 방지하기 위해 도메인 관리자 계정으로는 SQL Server 서비스를 실행하지 않기 때문에 SQL Server를 실행하는 컴퓨터는 고유 SPN을 만들 수 없습니다. 따라서 Kerberos를 사용하여 SQL Server를 실행하는 컴퓨터에 연결하려면 SQL Server를 실행하는 컴퓨터에 대한 SPN을 수동으로 만들어야 합니다. 도메인 사용자 계정이나 로컬 사용자 계정으로 SQL Server를 실행 중인 경우에도 마찬가지입니다. 사용자가 만든 SPN은 해당 컴퓨터에 있는 SQL Server 서비스의 서비스 계정에 할당되어야 합니다. SQL Server를 실행 중인 컴퓨터에서 로컬 시스템으로 시작하지 않으면 SPN을 컴퓨터 컨테이너에 할당할 수 없습니다. SPN은 하나씩만 있어야 하며 적합한 컨테이너에 할당되어야 합니다. 일반적으로는 현재 SQL Server 서비스 계정이지만 이것은 로컬 시스템을 사용하는 컴퓨터 계정입니다.

도메인 확인

로그온하는 도메인이 SQL Server를 실행하는 컴퓨터가 속한 도메인과 통신할 수 있는지 확인합니다. 또한 도메인에는 적절한 이름 확인도 있어야 합니다.

로그온 도메인이 SQL Server를 실행하는 컴퓨터가 속한 도메인이면 Windows 인증을 사용하여 SQL Server에 로그온합니다. 인증에 실패하면 Windows 계정이나 도메인 계정에 해결해야 할 문제가 있는 것입니다. 보안 관리자나 네트워크 관리자에게 문의하여 Windows 계정이나 도메인 계정에 적절한 사용 권한이 있는지 확인합니다.
로그온 도메인이 SQL Server를 실행하는 컴퓨터의 도메인과 다르면 도메인 간의 트러스트 관계를 확인합니다.
서버가 속한 도메인과 연결에 사용하는 도메인 계정이 같은 포리스트에 있는지 확인합니다. 이것은 SSPI가 작동하기 위해 필요합니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
274438
(http://support.microsoft.com/kb/274438/ )
Windows 2000에서 두 포리스트 간에 Kerberos 트러스트 관계를 사용할 수 없다
SQL Server를 시작할 때 Active Directory 사용자 및 컴퓨터에서 계정이 위임에 트러스트되었습니다 옵션을 사용합니다.
Windows 2000 Resource Kit에서 계정에 대한 서비스 사용자 이름 조작(Manipulate Service Principal Names for Accounts) 유틸리티인 SetSPN.exe를 사용합니다. Windows 2000 도메인 관리자 계정 또는 Windows 2003 도메인 관리자 계정은 이 유틸리티를 사용하여 계정과 서비스에 할당된 SPN을 제어할 수 있습니다. SQL Server의 경우 SPN은 하나씩만 있어야 합니다. SPN은 적합한 컨테이너에 할당되어야 하며 대부분의 경우 현재 SQL Server 서비스 계정이고 로컬 시스템 계정으로 SQL Server를 시작하는 경우 컴퓨터 계정입니다. LocalSystem 계정으로 로그온한 상태에서 SQL Server를 시작하면 SPN이 자동으로 설정됩니다. 하지만 도메인 계정을 사용하여 SQL Server를 시작하는 경우나 SQL Server를 시작하는 데 사용할 계정을 변경하는 경우에는 SetSPN.exe를 실행하여 만료된 SPN을 제거한 다음 유효한 SPN을 추가해야 합니다. 자세한 내용은 SQL Server 2000 온라인 설명서의 "보안 계정 위임(Security Account Delegation)" 항목을 참조하십시오. 이 항목을 보려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://msdn.microsoft.com/library/en-us/adminsql/ad_security_2gmm.asp
(http://msdn.microsoft.com/library/en-us/adminsql/ad_security_2gmm.asp)
(영문)
Windows 2000 Resource Kit에 대한 자세한 내용을 보려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true
(http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true)
(영문)
이름 확인이 올바로 수행되는지 확인합니다. 이름 확인 방법에는 DNS, WINS, HOSTS, LMHOSTS 파일 등이 포함될 수 있습니다. 이름 확인 문제와 해결에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
169790
(http://support.microsoft.com/kb/169790/ )
기본 TCP/IP 문제를 해결하는 방법
Active Directory에서 액세스 가능성 및 방화벽 문제를 해결하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
291382
(http://support.microsoft.com/kb/291382/ )
Windows 2000 DNS 및 Windows Server 2003 DNS에 대한 질문과 대답
224196
(http://support.microsoft.com/kb/224196/ )
특정 포트로 Active Directory 복제 트래픽 제한

서버 환경 확인

SQL Server가 설치된 컴퓨터에서 일부 기본 설정을 확인합니다.

Windows 클러스터링을 실행하는 Windows 2000 기반 컴퓨터에서는 Windows 2000에 서비스 팩 3 이상을 적용하는 경우에만 Kerberos가 지원됩니다. 따라서 클러스터된 SQL Server의 인스턴스에서 SSPI 인증을 사용하지 못할 수도 있습니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
235529
(http://support.microsoft.com/kb/235529/ )
Windows 2000 기반 서버 클러스터에서 Kerberos 지원
서버가 Windows 2000 서비스 팩 1(SP1)을 실행하는지 확인합니다. Windows 2000 기반 서버에서 Kerberos 지원에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
267588
(http://support.microsoft.com/kb/267588/ )
SQL Server 2000에 연결할 때 "SSPI 컨텍스트를 생성할 수 없습니다." 오류 메시지가 표시된다
클러스터에서 SQL Server, SQL Server 에이전트 또는 전체 텍스트 검색 서비스를 시작하는 데 사용하는 계정이 변경되면(예: 새 암호) Microsoft 기술 자료의 다음 문서에서 제공되는 단계를 따르십시오.
239885
(http://support.microsoft.com/kb/239885/ )
INF: SQL 가상 서버에서 서비스 계정을 변경하는 방법
SQL Server를 시작하는 데 사용하는 계정에 적절한 사용 권한이 있는지 확인합니다. Local Administrators 그룹의 구성원이 아닌 계정을 사용하고 있는 경우 이 계정에 필요한 사용 권한의 자세한 목록은 SQL Server 온라인 설명서의 "Windows 서비스 계정 설정(Setting up Windows Services Accounts)" 항목을 참조하십시오.
http://msdn.microsoft.com/library/en-us/instsql/in_overview_6k1f.asp
(http://msdn.microsoft.com/library/en-us/instsql/in_overview_6k1f.asp)
(영문)

클라이언트 환경 확인

클라이언트에서 다음 사항을 확인합니다.

NTLM 보안 지원 공급자가 클라이언트에 제대로 설치되고 설정되어 있는지 확인합니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
269541
(http://support.microsoft.com/kb/269541/ )
Windows NTLM 보안 지원 공급자 레지스트리 키가 없는 경우 SQL Server에 연결하면 "SSPI 컨텍스트를 생성할 수 없습니다." 오류 메시지가 나타난다
캐시된 자격 증명을 사용하고 있는지 확인합니다. 캐시된 자격 증명을 사용하여 클라이언트에 로그온되어 있으면 컴퓨터를 로그오프한 다음 도메인 컨트롤러에 연결할 수 있을 때 다시 로그온하여 캐시된 자격 증명이 사용되지 못하게 합니다. 캐시된 자격 증명을 사용하는지 확인하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
242536
(http://support.microsoft.com/kb/242536/ )
도메인의 캐시된 자격 증명을 사용하여 로그온할 때 경고가 나타나지 않는다
클라이언트와 서버의 날짜가 유효한지 확인합니다. 두 날짜가 너무 멀리 떨어져 있으면 인증서가 잘못된 것으로 간주될 수 있습니다.
SSPI는 Security.dll이라는 파일을 사용합니다. 그러나 다른 응용 프로그램에서 동일한 이름의 파일을 설치하면 실제 SSPI 파일 대신 이 파일이 사용될 수 있습니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
253577
(http://support.microsoft.com/kb/253577/ )
PRB: 오류: 80004005 - MS ODBC SQL Server 드라이버가 SSPI 패키지를 초기화할 수 없습니다
클라이언트의 운영 체제가 Microsoft Windows 98이면 클라이언트에 Microsoft 네트워크용 클라이언트 구성 요소를 설치해야 합니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
267550
(http://support.microsoft.com/kb/267550/ )
BUG: TCP/IP를 통해 SQL Server에 연결하면 "어설션 오류"가 나타난다

클라이언트 네트워크 유틸리티 확인

클라이언트 네트워크 유틸리티(CNU)는 Microsoft Data Access Components(MDAC)와 함께 제공되며 SQL Server를 실행하는 컴퓨터에 대한 연결을 구성하는 데 사용됩니다. MDAC Cliconfg.exe CNU 유틸리티를 사용하여 연결을 구성할 수 있습니다.

일반 탭에서 프로토콜이 정의된 방식은 MDAC 버전에 따라 다릅니다. 이전 버전의 MDAC에서는 "기본" 프로토콜을 선택할 수 있습니다. 최신 버전의 MDAC에서는 SQL Server에 연결할 때 목록의 맨 위에 있는 것과 함께 하나 이상의 프로토콜을 설정할 수 있습니다. SSPI는 TCP/IP에만 적용되기 때문에 명명된 파이프 같은 다른 프로토콜을 사용하여 오류를 막을 수 있습니다.
CNU에서 별칭 탭을 확인하여 연결하려는 서버에 별칭이 정의되어 있는지 알아봅니다. 서버 별칭이 정의되어 있으면 이 컴퓨터가 SQL Server에 연결하도록 구성된 방식에 대한 설정을 확인합니다. 별칭 서버를 삭제하여 동작이 변경되는지 알아보면 이것을 확인할 수 있습니다.
별칭 서버가 CNU에 정의되지 않았으면 연결하려는 서버의 별칭을 추가합니다. 이 작업을 수행할 때 또한 프로토콜을 명시적으로 정의하고 IP 주소와 포트를 선택적으로 정의해야 합니다.

Microsoft 고객기술지원부(PSS)에 지원을 요청하기 위해 수집할 정보

이 문서의 문제 해결 단계를 사용하여 문제의 원인을 알아낼 수 없으면 다음 정보를 수집하여 Microsoft 고객기술지원부(PSS)에 지원을 요청합니다.

Microsoft 고객기술지원부 전화 번호의 전체 목록과 지원 비용에 대한 정보는 다음 Microsoft 웹 사이트를 참조하십시오.

기술지원 서비스 안내

(http://support.microsoft.com/default.aspx?scid=fh;KO;serviceoverview)

SQL Server에서 sqldiag 보고서를 생성합니다. 자세한 내용은 SQL Server 온라인 설명서의 "sqldiag 유틸리티(sqldiag Utility)" 항목을 참조하십시오.
클라이언트에서 오류에 대한 스크린 샷을 캡처합니다.
SQL Server에 연결할 수 없는 노드에서 명령 프롬프트에 다음 명령을 입력합니다.
net start > started.txt
이 명령을 사용하면 명령을 실행하는 디렉터리에 Started.txt라는 파일이 생성됩니다.
클라이언트 컴퓨터의 다음 레지스트리 키에 있는 레지스트리 키 값을 저장합니다.
HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
클러스터된 환경에서 클러스터의 각 노드에 대한 다음 레지스트리 키 값을 얻습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
클러스터된 환경에서 각 클러스터 서버 노드에 다음 레지스트리 키가 있는지 확인합니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
클라이언트에서 UNC(범용 명명 규칙) 이름이나 클러스터의 SQL 네트워크 이름을 사용하여 SQL Server에 연결하는 경우 결과를 캡처합니다.
클라이언트에서 컴퓨터 이름이나 클러스터의 SQL 네트워크 이름을 핑(ping)하는 경우 결과를 캡처합니다.
SQL Server 서비스(MSSQLServer, SQLServerAgent, MSSearch) 중 하나를 시작하는 데 사용하는 사용자 계정의 이름을 저장합니다.
지원 전문가는 SQL Server가 혼합 인증으로 구성되어 있는지 또는 Windows만 인증으로 구성되어 있는지 알아야 합니다.
SQL Server 인증을 사용하여 같은 클라이언트에서 SQL Server를 실행하는 컴퓨터에 연결할 수 있는지 확인합니다.
명명된 파이프 프로토콜을 사용하여 연결할 수 있는지 확인합니다.

SQL Server의 서비스 사용자 이름을 수동으로 설정하는 방법

SSPI(보안 지원 공급자 인터페이스)는 Kerberos 인증에 사용되는 Microsoft Windows NT 보안에 대한 인터페이스이며 NTLM 보안 지원 공급자에 대한 인증 구성표를 지원합니다. 인증은 Windows 도메인에 로그온할 때 운영 체제 수준에서 수행됩니다. Kerberos 인증은 Kerberos가 설정되어 있고 Active Directory를 사용하는 Windows 2000 기반 컴퓨터에서만 사용할 수 있습니다.

SSPI는 Windows 인증을 사용하여 만들어진 TCP/IP 연결에만 사용됩니다. Windows 인증은 트러스트된 연결 또는 통합 보안이라고도 합니다. SSPI는 명명된 파이프나 멀티프로토콜 연결에서는 사용되지 않습니다. 따라서 TCP/IP가 아닌 프로토콜에서 연결하도록 클라이언트를 구성하여 문제를 방지할 수 있습니다.

SQL Server 클라이언트가 SQL Server를 실행하는 원격 컴퓨터에 대해 TCP/IP 소켓을 통한 통합 보안을 사용하려고 하면 SQL Server 클라이언트 네트워크 라이브러리는 SSPI API를 사용하여 보안 위임을 수행합니다. SQL Server 네트워크 클라이언트(Dbnetlib.dll)는 AcquireCredentialsHandle 함수를 호출하고 pszPackage 매개 변수에 대해 "협상(negotiate)"을 넘겨줍니다. 이를 통해 기본 보안 공급자에게 협상 위임을 수행하도록 알립니다. 이 컨텍스트에서 협상은 Windows 기반 컴퓨터에서 Kerberos 또는 NTLM 인증을 시도하는 것을 의미합니다. 즉, SQL Server를 실행하는 대상 컴퓨터에 올바로 구성된 관련 SPN이 있으면 Windows는 Kerberos 위임을 사용합니다. 아니면 Windows는 NTLM 위임을 사용합니다.

참고 SQL Server 서비스(MSSQLServer, SQLServerAgent, MSSearch)를 시작하는 데 "SYSTEM"이라는 계정을 사용하고 있지 않은지 확인하십시오. 키워드 SYSTEM은 KDC(키 배포 센터)에서 충돌을 일으킬 수 있습니다.