참고 Kerberos 구성 관리자는 SQL Server와의 Kerberos 관련 연결 문제를 해결하는 데 도움이 되는 진단 도구입니다. 여기에 문제가 생기면 "SSPI 컨텍스트를 생성할 수 없습니다"와 같은 오류가 발생할 수 있습니다. 이 도구는 현재 사용할 수 있으며 다음 위치에서 다운로드할 수 있습니다.

https://www.microsoft.com/ko-kr/download/details.aspx

자세한 내용은 다음 Microsoft 기술 자료 문서를 참조하세요.

새로운 도구: "SQL Server용 Microsoft Kerberos 구성 관리자"가 Kerberos/연결 문제를 해결할 준비가 되었습니다

SQL Server용 Kerberos 구성 관리자를 사용할 수 있습니다

 

이 섹션에서는 "SSPI 컨텍스트를 생성할 수 없습니다"라는 오류 메시지가 나타나는 이유와 오류를 해결하는 방법에 대한 배경 정보를 제공합니다. 다음 조건에 해당하면 이 오류 메시지가 나타날 수 있습니다.

  • Microsoft SQL Server에 연결 중입니다.

  • 통합 보안을 사용 중입니다.

  • Kerberos 인증은 보안 위임을 수행하는 데 사용됩니다.

Kerberos 용어 및 서비스 사용자 이름 이해 클라이언트 컴퓨터의 SQL Server 드라이버는 SQL Server를 실행하는 컴퓨터에 성공적으로 연결하기 위해 사용자 계정의 Windows 보안 토큰을 사용하는 통합 보안을 사용합니다. Windows 보안 토큰은 클라이언트에서 SQL Server를 실행하는 컴퓨터로 위임됩니다. SQL Server 드라이버는 한 컴퓨터에서 다른 컴퓨터로 사용자의 보안 토큰을 위임할 때 다음 구성 중 하나를 사용하여 위임을 수행합니다.

  • 명명된 파이프에 대한 NTLM(보안 지원 공급자 인터페이스(SSPI)를 사용하지 않음)

  • 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)"이라는 식별자를 사용합니다. SPN을 서버 리소스의 일부 인스턴스에 대한 도메인 또는 포리스트 고유 식별자로 간주합니다. 사용자는 웹 서비스, SQL 서비스 또는 SMTP 서비스에 대한 SPN을 가질 수 있습니다. 고유한 SPN이 있는 동일한 실제 컴퓨터에 여러 웹 서비스 인스턴스를 가질 수도 있습니다.

SQL Server용 SPN은 다음과 같은 요소들로 구성됩니다.

  • ServiceClass: 일반적인 서비스 클래스를 식별합니다. SQL Server용으로 항상 사용되는 MSSQLSvc입니다.

  • Host: SQL Server를 실행하는 컴퓨터의 정규화된 도메인 이름 DNS입니다.

  • 포트: 서비스가 수신 대기 중인 포트 번호입니다.

예를 들어 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를 호출합니다. SQL Server를 실행하는 컴퓨터의 이름으로 IP 주소나 호스트 이름이 전달되는 경우에도 컴퓨터가 통합 보안을 사용하는 경우 SQL Server 드라이버는 컴퓨터의 정규화된 DNS를 확인하려고 시도합니다.

클라이언트의 SQL Server 드라이버가 SQL Server를 실행하는 컴퓨터의 정규화된 DNS를 확인하면 이 컴퓨터의 SPN을 구성하는 데 해당 DNS가 사용됩니다. 따라서 IP 주소 또는 호스트 이름이 WinSock에 의해 정규화된 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=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를 확인하면 클라이언트 쪽 확인도 성공하게 됩니다.

SQL Server 서비스 사용자 이름 만들기 이는 Kerberos 인증 및 SQL Server 상호 작용의 중요한 부분 중 하나입니다. SQL Server를 사용하면 LocalSystem 계정, 로컬 사용자 계정 또는 도메인 사용자 계정 중 하나에서 SQL Server 서비스를 실행할 수 있습니다. SQL Server 서비스 인스턴스가 시작되면 DsWriteAccountSpn API 호출을 사용하여 자체 SPN을 Active Directory에 등록하려고 시도합니다. 호출이 성공적이지 않으면 이벤트 뷰어에 다음과 같은 경고가 기록됩니다. DsWriteAccountSpn 기능에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하세요.

http://msdn2.microsoft.com/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을 만들 수 없습니다. 따라서 SQL Server를 실행하는 컴퓨터에 연결할 때 Kerberos 인증을 사용하려면 SQL Server를 실행하는 컴퓨터에 SPN을 수동으로 만들어야 합니다. 도메인 사용자 계정 또는 로컬 사용자 계정으로 SQL Server를 실행하는 경우에도 마찬가지입니다. 사용자가 만든 SPN은 해당 컴퓨터의 SQL Server 서비스의 서비스 계정에 할당되어야 합니다. SQL Server를 실행하는 컴퓨터가 로컬 시스템 계정으로 시작되지 않는 한 SPN은 컴퓨터 컨테이너에 할당될 수 없습니다. SPN은 단 하나만 있어야 하며 적절한 컨테이너에 할당되어야 합니다. 일반적으로 현재 SQL Server 서비스 계정이지만 이 경우 로컬 시스템 계정이 있는 컴퓨터 계정 컨테이너입니다.
 

 

이 섹션에서는 컴퓨터에서 SSPI 문제가 발생하지 않도록 하는 단계를 보여줍니다.

도메인 확인 사용자가 로그온한 도메인이 SQL Server를 실행하는 컴퓨터가 속한 도메인과 통신할 수 있는지 확인합니다. 도메인의 이름 확인도 정확해야 합니다.

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

    • 도메인 계정이 잠겨 있습니다.

    • 계정 암호가 변경되었습니다. 그러나 사용자가 암호 변경 후 SQL Server 서비스를 다시 시작하지 않았습니다.

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

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

  4. SQL Server를 시작할 때 Active Directory 사용자 및 컴퓨터의 위임에 대해 계정을 신뢰할 수 있음 옵션을 사용합니다.


    참고 '위임에 대해 계정을 신뢰할 수 있음' 권한은 Windows 인증을 사용하는 분산 쿼리(연결된 서버 쿼리)와 같은 더블 홉 시나리오에서와 같이 대상 SQL 서버의 자격 증명을 원격 SQL 서버에 위임할 때만 필요합니다.

  5. Windows 2000 Resource Kit에서 계정에 대한 서비스 사용자 이름 조작(SetSPN.exe) 유틸리티를 사용합니다. Windows 2000 도메인 관리자 계정 또는 Windows Server 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 온라인 설명서의 "보안 계정 위임" 항목을 참조하세요. 다음 Microsoft 웹 사이트로 이동하시면 됩니다.

    http://msdn2.microsoft.com/library/aa905162(SQL.80).aspx Windows 2000 Resource Kits에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하세요.

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true

  6. 이름 확인이 올바르게 수행되고 있는지 확인합니다. 이름 확인 방법에는 DNS, WINS, 호스트 파일 및 Lmhosts 파일이 포함될 수 있습니다. 이름 확인 문제 및 문제 해결에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    169790 기본 TCP/IP 문제를 해결하는 방법
     

  7. Active Directory의 액세스 가능성 및 방화벽 문제를 해결하는 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    291382 Windows 2000 DNS와 Windows Server 2003 DNS에 대해 자주 묻는 질문
     

    224196 특정 포트로 Active Directory 복제 트래픽 및 클라이언트 RPC 트래픽 제한

SQL Server 인스턴스에 대해 동적으로 SPN을 만들도록 SQL Server 서비스 구성 SPN을 동적으로 생성하도록 SQL Server 서비스를 구성하려면 Active Directory 디렉터리 서비스에서 계정의 액세스 제어 설정을 변경해야 합니다. SQL Server 서비스 계정에 "ServicePrincipalName 읽기" 권한과 "ServicePrincipalName 쓰기" 권한을 부여해야 합니다.

경고 Active Directory 서비스 인터페이스(ADSI) 편집 스냅인, LDP 유틸리티 또는 다른 LDAP 버전 3 클라이언트를 사용하며 Active Directory 개체의 특성을 잘못 변경하는 경우 심각한 문제가 발생할 수 있습니다. 이러한 문제로 인해 Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, 또는 Windows와 Exchange 모두를 다시 설치해야 할 수 있습니다. Active Directory 개체의 특성을 잘못 변경하여 발생하는 문제는 해결을 보장할 수 없습니다. 이러한 속성 변경에 따른 모든 책임은 사용자에게 있습니다.

참고 SQL Server 시작 계정에 적절한 사용 권한 및 사용자 권한을 부여하려면 도메인 관리자로 로그온해야 하며, 또는 도메인 관리자에게 해당 작업을 요청해야 합니다.

SPN을 동적으로 생성하도록 SQL Server 서비스를 구성하려면 다음 단계를 수행합니다.

  1. 시작, 실행을 차례로 클릭하고 Adsiedit.msc를 입력한 다음 확인을 클릭합니다.

  2. ADSI 편집 스냅인에서 도메인 [DomainName], DC= RootDomainName, CN=Users를 차례로 확장하고 CN= AccountName을 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

    참고

    • DomainName은 도메인 이름의 자리 표시자입니다.

    • RootDomainName은 루트 도메인 이름의 자리 표시자입니다.

    • AccountName은 SQL Server 서비스를 시작하기 위해 지정한 계정의 자리 표시자입니다.

    • SQL Server 서비스 시작을 위해 로컬 시스템 계정을 지정한 경우 AccountName은 Microsoft Windows에 로그온하는 데 사용하는 계정의 자리 표시자입니다.

    • SQL Server 서비스 시작을 위해 도메인 사용자 계정을 지정한 경우 AccountName은 도메인 사용자 계정의 자리 표시자입니다.

  3. CN= AccountName 속성 대화 상자에서 보안 탭을 클릭합니다.

  4. 보안 탭에서 고급을 클릭합니다.

  5. 고급 보안 설정 대화 상자에서 권한 항목 아래에 SELF가 나열되어 있는지 확인합니다.

    SELF가 표시되지 않으면 추가를 클릭한 다음 SELF를 추가합니다.

  6. 사용 권한 항목에서 SELF를 클릭한 다음, 편집을 클릭합니다.

  7. 사용 권한 항목 대화 상자에서 속성 탭을 클릭합니다.

  8. 속성 탭의 적용 대상 목록에서 이 개체만을 클릭한 다음 사용 권한에서 다음과 같은 사용 권한 확인란이 선택되어 있는지 확인합니다.

    • ServicePrincipalName 읽기

    • ServicePrincipalName 쓰기

  9. 확인을 세 번 클릭한 다음 ADSI 편집 스냅인을 종료합니다.

이 프로세스에 대한 도움을 받으려면 Active Directory 제품 지원부에 문의하여 이 Microsoft 기술 자료 문서를 언급합니다.


중요 다음 조건에 해당하는 경우 SQL 서비스 계정에 WriteServicePrincipalName 권한을 부여하지 않는 것이 좋습니다.

  • 여러 도메인 컨트롤러가 있습니다.

  • SQL Server가 클러스터됩니다.

이 시나리오에서는 Active Directory 복제 대기 시간으로 인해 SQL Server용 SPN이 삭제될 수 있습니다. 이로 인해 SQL Server 인스턴스에 연결 문제가 발생할 수 있습니다.

다음을 가정합니다.

  • SQL 가상 인스턴스 Sqlcluster에 두 개의 노드 포함: 노드 A와 노드 B.

  • 노드 A는 도메인 컨트롤러 A에 의해 인증되고 노드 B는 도메인 컨트롤러 B에 의해 인증됩니다.



다음과 같은 상황이 발생할 수 있습니다.

  1. Sqlcluster 인스턴스는 노드 A에서 활성화되며 시작하는 동안 도메인 컨트롤러 A에 SQL SPN을 등록합니다.

  2. 노드 A가 정상적으로 종료되면 Sqlcluster 인스턴스가 노드 B로 장애 조치(fail over)됩니다.

  3. Sqlcluster 인스턴스는 노드 A에서 종료 프로세스가 진행되는 동안 도메인 컨트롤러 A에서 SPN을 등록 취소합니다.

  4. SPN은 도메인 컨트롤러 A에서 제거되지만 변경 내용이 아직 도메인 컨트롤러 B에 복제되지 않았습니다.

  5. 노드 B에서 시작할 때 Sqlcluster 인스턴스는 SQL SPN을 도메인 컨트롤러 B에 등록하려고 시도합니다. SPN이 여전히 존재하기 때문에 노드 B는 SPN을 등록하지 않습니다.

  6. 잠시 후 도메인 컨트롤러 A는 Active Directory 복제의 일부로 도메인 컨트롤러 B에 SPN 삭제(3단계)를 복제합니다. 최종 결과는 도메인의 SQL 인스턴스에 유효한 SPN이 없으므로 Sqlcluster 인스턴스에 연결 문제가 나타납니다.


참고 이 문제는 SQL Server 2012에서 해결됩니다.

서버 환경 확인 SQL Server가 설치된 컴퓨터의 기본 설정을 확인합니다.

  1. Kerberos 인증은 Windows 2000에 서비스 팩 3(또는 이후 버전)을 적용하지 않는 한 Windows 클러스터링을 실행하는 Windows 2000 기반 컴퓨터에서 지원되지 않습니다. 따라서 SQL Server의 클러스터된 인스턴스에서 SSPI 인증을 사용하려는 시도가 실패 할 수 있습니다. 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    235529 Windows 2000 기반 서버 클러스터에서의 Kerberos 인증 지원
     

  2. 서버가 Windows 2000 서비스 팩 1(SP1)을 실행 중인지 확인합니다. Windows 2000 기반 서버에서의 Kerberos 인증 지원에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    267588 SQL Server 2000에 연결할 때 "SSPI 컨텍스트를 생성할 수 없습니다" 오류 메시지가 표시됨
     

  3. 클러스터에서 SQL Server, SQL Server 에이전트 또는 전체 텍스트 검색 서비스를 시작하는 데 사용하는 계정(예: 새 암호)이 변경되면 다음 Microsoft 기술 자료 문서에서 제공하는 단계를 수행합니다.

    239885 SQL Server를 실행하는 클러스터된 컴퓨터의 서비스 계정을 변경하는 방법
     

  4. SQL Server를 시작하는 데 사용하는 계정에 적절한 사용 권한이 있는지 확인합니다. 로컬 관리자 그룹의 구성원이 아닌 계정을 사용하는 경우 이 계정에 있어야 하는 사용 권한의 자세한 목록은 SQL Server 온라인 설명서의 "Windows 서비스 계정 설정" 항목을 참조하세요.

    http://msdn2.microsoft.com/library/aa176564(SQL.80).aspx

클라이언트 환경 확인 클라이언트에서 다음을 확인합니다.

  1. NTLM 보안 지원 공급자가 올바르게 설치되어 있고 클라이언트에서 활성화되어 있는지 확인합니다. 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    269541 Windows NT LM 보안 지원 공급자 레지스트리 키가 누락된 경우 SQL Server에 연결할 때 오류 메시지가 나타납니다. "SSPI 컨텍스트를 생성할 수 없습니다"
     

  2. 캐시된 자격 증명을 사용하고 있는지 확인합니다. 캐시된 자격 증명을 사용하여 클라이언트에 로그온한 경우 컴퓨터를 로그오프한 다음 도메인 컨트롤러에 연결할 수 있을 때 다시 로그온하여 캐시된 자격 증명이 사용되지 않도록 합니다. 캐시된 자격 증명을 사용하고 있는지 확인하는 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    242536 도메인 캐시된 자격 증명을 사용하여 로그온할 때 경고가 표시되지 않음
     

  3. 클라이언트와 서버의 날짜가 유효한지 확인합니다. 날짜가 너무 멀리 떨어져 있으면 사용자의 인증서가 유효하지 않은 것으로 간주될 수 있습니다.

  4. SSPI는 Security.dll이라는 파일을 사용합니다. 다른 응용 프로그램에서 이 이름을 사용하는 파일을 설치하면 실제 SSPI 파일 대신 다른 파일이 사용될 수 있습니다. 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    253577 오류: 80004005 - MS ODBC SQL Server 드라이버가 SSPI 패키지를 초기화할 수 없습니다
     

  5. 클라이언트의 운영 체제가 Microsoft Windows 98인 경우 클라이언트에 Microsoft Networks용 클라이언트 구성 요소를 설치해야 합니다.

    자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

    267550 버그: TCP/IP를 통해 SQL Server에 연결할 때 "어설션 실패"
     

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

  1. 일반 탭의 프로토콜 정의 방법은 MDAC 버전에 따라 다릅니다. 이전 버전의 MDAC에서는 "기본" 프로토콜을 선택할 수 있습니다. 최신 버전의 MDAC에서는 SQL Server에 연결할 때 목록 맨 위에 있는 것과 더불어 하나 이상의 프로토콜을 함께 사용할 수 있습니다. SSPI는 TCP/IP에만 적용되므로 명명된 파이프와 같은 다른 프로토콜을 사용하여 오류를 피할 수 있습니다.

  2. CNU의 별칭 탭을 확인하여 연결하려는 서버에 별칭이 정의되어 있는지 확인합니다. 서버 별칭이 정의된 경우 컴퓨터가 SQL Server에 연결되는 방식에 대한 설정을 확인합니다. 별칭 서버를 삭제하여 동작이 변경되는지 확인할 수 있습니다.

  3. 별칭 서버가 CNU에 정의되어 있지 않으면 연결 중인 서버에 별칭을 추가합니다. 이 작업을 수행할 때 프로토콜을 명시적으로 정의하고 선택적으로 IP 주소와 포트를 정의할 수도 있습니다.

SQL Server의 서비스 사용자 이름 수동으로 설정 SQL Server의 서비스 사용자 이름을 수동으로 설정하는 방법에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

319723 SQL Server에서 Kerberos 인증을 사용하는 방법
  보안 지원 공급자 인터페이스(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 매개 변수에 대해 "협상"을 전달합니다. 이는 기본 보안 공급자에게 협상 위임을 수행할 것을 알립니다. 여기에서 협상이란 Windows 기반 컴퓨터에서 Kerberos 또는 NTLM 인증을 시도하는 것을 의미합니다. 즉, SQL Server를 실행하는 대상 컴퓨터에 SPN이 올바르게 구성되어 있으면 Windows에서 Kerberos 위임을 사용합니다. 그렇지 않으면 Windows에서 NTLM 위임을 사용합니다.

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

 

이 문서의 문제 해결 단계를 수행하여 문제의 원인을 파악할 수 없는 경우 다음 정보를 수집하고 Microsoft 고객 지원(CSS) 사례를 엽니다.

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

http://support.microsoft.com/ko-kr/contactus/?ws=support

  1. SQL Server에서 sqldiag 보고서를 생성합니다. 자세한 내용은 SQL Server 온라인 설명서의 "sqldiag 유틸리티" 항목을 참조하세요.

  2. 클라이언트의 오류 화면 스크린샷을 캡처합니다.

  3. SQL Server에 연결할 수 없는 노드에서 명령 프롬프트를 열고 다음 명령을 입력합니다.

    net start > started.txt 이 명령은 명령을 실행하는 디렉터리에서 Started.txt라는 파일을 생성합니다.

  4. 클라이언트 컴퓨터에서 다음 레지스트리 키 아래에 레지스트리 키 값을 저장합니다.

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO

  5. 클러스터된 환경에서 클러스터의 각 노드에 대한 다음 레지스트리 키 값을 찾습니다.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel

  6. 클러스터된 환경에서 각 클러스터 서버 노드에 다음 레지스트리 키가 있는지 확인합니다.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp

  7. 클라이언트의 범용 명명 규칙(UNC) 이름(또는 클러스터의 SQL 네트워크 이름)을 사용하여 SQL Server에 연결하면 결과를 캡처합니다.

  8. 클라이언트에서 컴퓨터 이름(또는 클러스터의 SQL 네트워크 이름)을 ping하면 결과를 캡처합니다.

  9. 각 SQL Server 서비스(MSSQLServer, SQLServerAgent, MSSearch)를 시작하는 데 사용하는 사용자 계정의 이름을 저장합니다.

  10. 지원 전문가는 SQL Server가 혼합 인증 또는 Windows 전용 인증으로 구성되는지 여부를 알아야 합니다.

  11. SQL Server 인증을 사용하여 동일한 클라이언트에서 SQL Server를 실행하는 컴퓨터에 연결할 수 있는지 확인합니다.

  12. 명명된 파이프 프로토콜을 사용하여 연결할 수 있는지 확인합니다.

참고 자료 Kerberos 인증 및 SSPI 보안 작동 방식에 대한 자세한 내용은 다음 문서 번호를 클릭하여 Microsoft 기술 자료 문서를 참조하세요.

266080 자주 묻는 Kerberos 인증 질문에 대한 답변
 

231789 Windows 2000의 로컬 로그온 프로세스
 

304161 SSPI 상호 인증이 클라이언트 쪽에서는 표시되지만 서버 쪽에서는 표시되지 않습니다
 

232179 Windows 2000의 Kerberos 인증
 

230476 Windows 2000의 일반적인 Kerberos 관련 오류에 대한 설명
 

262177 Kerberos 이벤트 로깅을 사용 설정하는 방법
 

277658 도메인 이름이 SQL Server SPN이 등록된 NetBIOS 이름과 다른 경우 Setspn 실패

244474 Windows Server 2003, Windows XP, Windows 2000에서 Kerberos가 UDP 대신 TCP를 사용하도록 하는 방법
  Microsoft SQL Server 2000 보안에 대한 백서를 보려면 다음 Microsoft 웹 사이트를 참조하세요.

http://technet.microsoft.com/cc984178.aspx

추가 도움이 필요하신가요?

기술 향상
교육 살펴보기
새로운 기능 우선 가져오기
Microsoft Insider 참가

이 정보가 유용한가요?

번역 품질에 얼마나 만족하시나요?

사용 경험에 어떠한 영향을 주었나요?

추가 피드백이 있으신가요? (선택 사항)

소중한 의견에 감사드립니다.

×