MSSQLSERVER_18456

  • 아티클

적용 대상:SQL Server

세부 정보

attribute 값
제품 이름 SQL Server
이벤트 ID 18456
이벤트 원본 MSSQLSERVER
구성 요소 SQLEngine
심볼 이름 LOGON_FAILED
메시지 텍스트 사용자 '%.*ls'에 로그인하지 못했습니다.%.*ls

설명

인증 실패로 인해 연결 시도가 거부되면 이 오류 메시지가 표시됩니다. 사용자 로그인은 잘못된 자격 증명, 암호 만료 및 잘못된 인증 모드 사용과 같은 여러 가지 이유로 실패할 수 있습니다. 대부분의 경우 오류 코드에는 설명이 포함됩니다.

사용자 작업

다음 예제는 몇 가지 일반적인 로그인 실패입니다. 문제를 해결하기 위해 발생하는 정확한 오류를 선택합니다.

사용자 'username>'<에 로그인하지 못했거나 사용자 '<do기본>\<username>'에 로그인하지 못했습니다.

do기본 이름을 지정하지 않으면 실패한 SQL Server 로그인 시도가 문제입니다. do기본 이름을 지정하면 실패한 Windows 사용자 계정 로그인 문제가 발생합니다. 잠재적 원인 및 제안된 해결 방법은 다음을 참조하세요.

가능한 원인 제안된 해결 방법
SQL Server 인증을 사용하려고 하지만 SQL Server 인스턴스는 Windows 인증 모드로 구성됩니다. SQL Server가 SQL Server 및 Windows 인증 모드를 사용하도록 구성되어 있는지 확인합니다. SSMS(SQL Server Management Studio)의 해당 인스턴스에 대한 속성 아래의 보안 페이지에서 SQL Server 인스턴스에 대한 인증 모드를 검토하고 변경할 수 있습니다. 자세한 내용은 서버 인증 모드 변경을 참조 하세요. 또는 Windows 인증 모드를 사용하여 SQL Server에 연결하도록 애플리케이션을 변경할 수 있습니다.
참고: 이 시나리오에 대한 SQL Server 오류 로그에서 다음과 같은 메시지를 볼 수 있습니다.
Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only.
그룹을 통해 SQL Server에 액세스하려고 하면 오류 메시지가 표시됩니다. 서버에 액세스하는 데 필요한 권한이 없는 경우 공급자는 "사용자 'contoso/user1'에 대한 로그인 실패" 오류 메시지를 표시합니다. 그룹 멤버 자격에 따라 서버에 액세스하는 데 도움이 되는 "그룹을 통한 액세스" 기능을 사용합니다.
저장 프로시저를 xp_logininfo 'contoso/user1' 실행하면 다음이 발생할 수 있습니다.
- 오류가 표시되면 SQL Server에서 사용자 이름을 전혀 확인할 수 없습니다. 이름이 AD(Active Directory)에 없거나 DC(do기본 컨트롤러)에 연결하는 데 문제가 있을 수 있습니다. 문제가 특정 계정과 관련된 경우 다른 이름으로 검사.
- cross-do기본 서버에 연결하는 경우 구성원 자격을 확인할 수 있도록 그룹이 사용자가 기본 아니라 SQL Server do기본에 있어야 합니다.
- 데이터베이스 쿼리가 행을 반환하지 않으면 서버에 대한 액세스를 제공하는 그룹이 없음을 의미합니다. 쿼리가 하나 이상의 행을 반환하는 경우 사용자가 액세스를 제공하는 그룹에 속한다는 의미입니다.
DBA는 SSMS(SQL Server Management Studio)에서 Security\Logins 폴더를 검사 권한을 두 번 검사 수 있습니다. Security\Logins는 만든 로그인 목록을 표시합니다. 포함된 데이터베이스인 경우 DBA는 데이터베이스 이름 아래에 Security\Logins를 검사 로그인을 검사 관리할 수 있습니다.
자세한 내용은 사용자 액세스 제어 및 권한 구성을 참조 하세요.
SQL 로그인을 사용할 수 없습니다. DBMS(데이터베이스 관리 시스템)에는 메시지의 일부 변형이 Login failed for user '<username>' 표시될 수 있습니다. 이 문제를 해결하려면 다음 단계를 따릅니다.
1. SQL Server 오류 로그에 "사용자 'username>'<에 대한 로그인 실패" 오류 메시지가 포함되어 있는지 확인합니다. 이유: SQL 인증을 사용하여 로그인하지 못했습니다. 서버는 Windows 인증만 구성됩니다."
2. 다음 방법 중 하나를 사용하여 오류를 해결합니다.
- 통합 로그인을 사용합니다. 예를 들어 OLE DB 공급자의 경우 연결 문자열 추가하고 INTEGRATED SECURITY=SSPI ODBC 드라이버에 추가TRUSTED_CONNECTION=YES합니다. .NET 공급자는 두 구문 중 하나를 허용합니다.
참고: 통합 인증을 허용하도록 올바르게 구성되지 않은 경우 다른 문제가 발생할 수 있으며 별도의 문제로 조사해야 합니다.
- 서버에서 SQL 로그인을 사용하도록 설정합니다.
a. SQL Server Management Studio에서 개체 탐색기 SQL Server 이름을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.
b. 보안 창에서 SQL Server 및 Windows 인증 모드를 선택합니다.
c. 확인을 선택합니다.
d. 변경이 수행되도록 SQL Server를 다시 시작합니다.
참고: 이로 인해 SQL 로그인 정의와 같은 다른 문제가 발생할 수 있습니다.
- 로컬 Windows 계정 또는 사용자 이름에 대한 do기본 계정을 지정합니다. SQL 로그인만 허용됩니다. 애플리케이션은 통합 보안을 사용해야 합니다.
연결하려는 SQL Server 인스턴스에 로그인이 없습니다. SQL Server 로그인이 존재하고 철자가 제대로 지정되었는지 확인합니다. 로그인이 없으면 만듭니다. 있지만 철자가 틀린 경우 애플리케이션에서 연결 문자열 수정합니다. SQL Server Errorlog에는 다음 메시지 중 하나가 있습니다.
- Login failed for user 'username'. Reason: Could not find a login matching the name provided.
- Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.이는 DEV 또는 QA 서버를 사용하는 애플리케이션을 프로덕션 환경에 배포하고 연결 문자열 업데이트하지 못하는 경우 일반적인 문제가 될 수 있습니다. 이 문제를 해결하려면 적절한 서버에 연결하고 있는지 확인합니다. 그렇지 않은 경우 연결 문자열 수정합니다. 이 경우 SQL Server에 대한 로그인 액세스 권한을 부여합니다. 또는 Windows 로그인이 직접 액세스 권한을 부여하거나 데이터베이스 서버에 연결할 수 있는 로컬 또는 할기본 그룹에 추가합니다. 자세한 내용은 로그인 만들기를 참조하세요.
SQL Server 인증을 사용하고 있지만 SQL Server 로그인에 지정한 암호가 잘못되었습니다. SQL 오류 로그에서 "이유: 암호가 제공된 로그인의 암호와 일치하지 않습니다"와 같은 메시지를 확인하여 원인을 확인합니다. 이 문제를 해결하려면 애플리케이션에서 올바른 암호를 사용하거나 암호를 기억할 수 없는 경우 다른 계정을 사용합니다. 또는 SQL Server 관리자와 협력하여 계정의 암호를 다시 설정합니다.
애플리케이션이 SSIS(SQL Server Integration Services)인 경우 작업에 대한 여러 수준의 구성 파일이 있을 수 있으며 패키지에 대한 연결 관리자 설정을 재정의할 수 있습니다.
회사에서 애플리케이션을 작성하고 연결 문자열 프로그래밍 방식으로 생성된 경우 개발 팀에 문의하여 문제를 해결합니다. 임시 해결 방법으로 연결 문자열 하드 코딩하고 테스트합니다. UDL 파일 또는 스크립트를 사용하여 하드 코딩된 연결 문자열 연결이 가능하다는 것을 증명합니다.
서버 이름이 잘못되었습니다. 올바른 서버에 연결하고 있는지 확인합니다.
로그인 없음 SQL Server에 다음 메시지가 표시되는지 확인합니다.
Logon Error: 18456, Severity: 14, State: 11.
Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]
일부 오류는 익명 로그온 계정에 속합니다. 이는 Kerberos 문제와 관련이 있습니다. HOSTS 파일에 잘못된 수동 항목이 있습니다. 즉, 잘못된 서버 이름이 지정되었습니다.
다시 기본 문제는 다음 범주로 분류될 수 있습니다.
  • 최종 사용자에 대해 로그인이 거부되었거나 부여되지 않았습니다.
  • 계정은 관리istrators 그룹을 통해 액세스할 수 있었습니다.
  • 사용자가 속한 그룹에는 SQL Server에서 DENY 권한이 있습니다.
Windows 인증 사용하여 연결하려고 하지만 잘못된 기본 로그인됩니다. 올바른 기본 올바르게 로그인했는지 확인합니다. 오류 메시지는 일반적으로 do기본 이름을 표시합니다.
데이터베이스 사용 권한 확인 데이터베이스는 SQL Server Management Studio에서 오프라인으로 표시되지 않습니다. 다른 사용자(예: DBA가 DBA에 연결할 수 있습니다.)
해당 사용자 계정에 데이터베이스에 대한 명시적 액세스 권한이 부여되거나 SQL Server 역할 또는 로컬 Windows 그룹 또는 데이터베이스에 대한 액세스 권한이 있는 do기본 그룹에 추가되어야 합니다. 자세한 내용은 CREATE USER, ALTER ROLE 및 ALTER SERVER ROLE을 참조하세요.
관리자 권한으로 애플리케이션(예: SSMS)을 실행하고 있지 않습니다. 관리자 자격 증명을 사용하여 연결하려는 경우 관리로 실행 옵션을 사용하여 애플리케이션을 시작합니다. 연결되면 Windows 사용자를 개별 로그인으로 추가합니다.
포함된 데이터베이스 사용자로 마이그레이션한 후 로그인이 삭제됩니다. 데이터베이스 엔진 포함된 데이터베이스를 지원하는 경우 포함된 데이터베이스 사용자로 마이그레이션한 후 로그인이 삭제되지 않았는지 확인합니다. 자세한 내용은 포함된 데이터베이스 인증: 소개를 참조하세요.
로그인의 기본 데이터베이스가 오프라인이거나 사용할 수 없습니다. SQL Server 관리자에게 문의하고 데이터베이스 가용성과 관련된 문제를 해결합니다. 로그인에 서버의 다른 데이터베이스에 대한 권한이 있고 애플리케이션에서 현재 구성된 기본 데이터베이스에 액세스할 필요가 없는 경우 다음 옵션 중 하나를 사용합니다.
- ALTER LOGIN 문 또는 SSMS를 사용하여 로그인에 대한 기본 데이터베이스를 변경하도록 관리자에게 요청합니다.
- 애플리케이션 연결 문자열 다른 데이터베이스를 명시적으로 지정합니다. 또는 SSMS 스위치를 커넥트ion 속성 탭으로 전환하여 현재 사용할 수 있는 데이터베이스를 지정하는 경우SSMS와 같은 애플리케이션은 다음과 같은 오류 메시지를 표시할 수 있습니다.
Cannot open user default database. Login failed.
Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)
SQL Server Errorlog에는 다음과 같은 오류 메시지가 표시됩니다.
Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]
자세한 내용은 MSSQLSERVER_4064 참조하세요.
연결 문자열 또는 SSMS에 명시적으로 지정된 데이터베이스의 철자가 잘못되었거나 오프라인이거나 사용할 수 없습니다. - 연결 문자열 데이터베이스 이름을 수정합니다. 서버에서 대/소문자 구분 데이터 정렬을 사용하는 경우 대/소문자 구분에 주의하세요.
- 데이터베이스 이름이 올바른 경우 SQL Server 관리자에게 검사 데이터베이스 가용성과 관련된 문제를 해결합니다. 데이터베이스가 오프라인 상태인지, 복구되지 않는지 등을 확인합니다.
- 로그인이 서버의 다른 데이터베이스에 대한 사용 권한이 있는 사용자에게 매핑되었으며 애플리케이션에서 현재 구성된 데이터베이스에 액세스할 필요가 없는 경우 연결 문자열 다른 데이터베이스를 지정합니다. 또는 SSMS에 연결하는 경우 커넥트ion 속성 탭을 사용하여 현재 사용할 수 있는 데이터베이스를 지정합니다.
SQL Server Errorlog에는 다음과 같은 오류 메시지가 표시됩니다.
Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]
참고: 로그인의 기본 데이터베이스를 사용할 수 있는 경우 SQL Server에서 연결이 성공하도록 허용합니다. 자세한 내용은 MSSQLSERVER_4064 참조하세요.
사용자에게 요청된 데이터베이스에 대한 권한이 없습니다. - sysadmin 권한이 있는 다른 사용자로 연결하여 연결을 설정할 수 있는지 확인합니다.
- 해당 사용자를 만들어 데이터베이스에 대한 로그인 액세스 권한을 부여합니다(예: CREATE USER [<UserName>] FOR LOGIN [UserName]).

또한 문제 해결 오류 18456에서 광범위한 오류 코드 목록을 검사.

자세한 문제 해결 도움말은 SQL 클라이언트/서버 커넥트성 문제 해결을 참조하세요.

사용자 NT AUTHORITY\ANONYMOUS LOGON에 대한 로그인 실패

이 문제에 대한 시나리오는 4개 이상 있습니다. 다음 표에서 적용 가능한 각 잠재적 원인을 검사하고 적절한 해결을 사용합니다. 이중 홉이라는 용어에 대한 설명은 아래 표를 참조하세요.

잠재적 원인 제안된 해결 방법
NTLM(NT LAN Manager) 자격 증명을 한 서비스에서 동일한 컴퓨터의 다른 서비스(예: IIS에서 SQL Server로)로 전달하려고 하지만 프로세스에서 오류가 발생합니다. DisableLoopbackCheck 또는 Back커넥트ionHostNames 레지스트리 항목을 추가합니다.
여러 컴퓨터에서 이중 홉(제약 조건 위임) 시나리오가 있습니다. SPN(서비스 사용자 이름) 문제로 인해 Kerberos 연결이 실패하는 경우 오류가 발생할 수 있습니다. 각 SQL Server 및 웹 서버에서 SQLCheck를 실행합니다. 문제 해결 가이드: 0600 자격 증명 위임 문제 및 0650 SQL Server 연결된 서버 위임 문제를 사용합니다.
이중 홉(제약 조건 위임)이 관련되지 않은 경우 중복된 SPN이 존재하고 클라이언트가 Kerberos 자격 증명 대신 NTLM 자격 증명을 가져오는 LocalSystem 또는 다른 컴퓨터 계정으로 실행되고 있을 수 있습니다. SQLCheck 또는 Setspn.exe 사용하여 SPN 관련 문제를 진단하고 해결합니다. SQL Server용 Kerberos 구성 관리자 개요도 검토 합니다.
원격 인증 요청에 컴퓨터 계정을 사용하지 않도록 Windows 로컬 보안 정책이 구성되었을 수 있습니다. 로컬 보안 정책>로컬 정책>보안 옵션>네트워크 보안으로 이동합니다. 로컬 시스템에서 NTLM에 컴퓨터 ID를 사용하도록 허용하고, 설정을 사용하지 않도록 설정한 경우 사용 옵션을 선택한 다음 확인을 선택합니다.
참고: 설명 탭에 자세히 설명된 대로 이 정책은 기본적으로 Windows 7 이상 버전에서 사용하도록 설정됩니다.
제한된 위임을 사용할 때 이 문제가 간헐적으로 발생하면 중간 계층으로 갱신할 수 없는 만료된 티켓이 있음을 나타낼 수 있습니다. 이는 연결된 서버 시나리오 또는 10시간 이상 로그온 세션을 개최하는 모든 애플리케이션에서 예상되는 동작입니다. 중간 계층 서버의 위임 설정을 지정된 서비스로만 위임할 수 있도록 이 컴퓨터 신뢰에서 변경 - Kerberos만사용하여 지정된 서비스에만 위임하기 위해 이 컴퓨터를 신뢰합니다. 모든 프로토콜을 사용합니다. 자세한 내용은 SQL Server 연결된 서버 이중 홉의 일시적인 ANONYMOUS LOGON을 참조 하세요.
NTLM 피어 로그인 이 오류는 Microsoft Windows OS에서 사용하는 NTLM 인증 프로토콜과 관련이 있습니다. 워크스테이션에 있거나 서로 신뢰하지 않는 기본 컴퓨터 간에 통신하는 경우 두 컴퓨터에서 동일한 계정을 설정하고 NTLM 피어 인증 NTLM 피어 로그인을 사용할 수 있습니다. 로그인은 사용자 계정과 암호가 두 컴퓨터에서 모두 일치하는 경우에만 작동합니다.
루프백 보호 루프백 보호는 애플리케이션이 동일한 컴퓨터에서 다른 서비스를 호출하는 것을 금지하도록 설계되었습니다. 이를 허용하도록 (기본 설정) 레지스트리 키를 설정할 DisableLoopbackCheckBackConnectionHostNames 수 있습니다. 자세한 내용은 Windows Server 2003 서비스 팩 1을 설치한 후 FQDN 또는 해당 CNAME 별칭을 사용하여 서버에 로컬로 액세스하려고 할 때 오류 메시지를 참조 하세요. 액세스가 거부되었거나 네트워크 공급자가 지정된 네트워크 경로를 수락하지 않았습니다.
Always-On 수신기 루프백 보호 주 노드에서 Always-On 수신기에 연결할 때 연결은 NTLM이 됩니다. 그러면 루프백 검사가 수행되고 사용자가 신뢰할 수 없는 작업에서 온 것임을 나타내는 "로그인 실패" 오류가 발생합니다기본. 이 오류를 해결하려면 가용성 그룹의 모든 컴퓨터에서 수신기 NETBIOS 이름과 정규화된 이름을 BackConnectionHostNames 레지스트리 키에 입력합니다. 자세한 내용은 Windows Server 2003 서비스 팩 1을 설치한 후 FQDN 또는 해당 CNAME 별칭을 사용하여 서버에 로컬로 액세스하려고 할 때 오류 메시지를 참조 하세요. 액세스가 거부되었거나 네트워크 공급자가 지정된 네트워크 경로를 수락하지 않았습니다.
LANMAN 호환성 수준 일반적으로 이전 컴퓨터(Windows 2008 이전)와 최신 컴퓨터 간에 발생합니다.
모든 컴퓨터에서 LANMAN 호환성 수준을 5로 설정합니다. NTLM v1도 허용되지 않습니다. 이 문제를 방지하기 위해 Kerberos로 전환할 수도 있습니다.
중요한 계정 일부 계정은 Active Directory에서 중요로 표시될 수 있습니다. 이러한 계정은 더블 홉 시나리오에서 다른 서비스에 위임할 수 없습니다.
제한된 대상이 아님 특정 서비스 계정에 대해 제한된 위임을 사용하도록 설정하면 대상 서버의 SPN이 제한된 위임 대상 목록에 없으면 Kerberos가 실패합니다.
서비스별 SID 이 기능은 인증 방법으로 Kerberos가 아닌 NTLM을 사용하도록 로컬 연결을 제한합니다. 서비스는 NTLM 자격 증명을 사용하여 다른 서버에 단일 홉을 만들 수 있지만 제한된 위임을 사용하지 않으면 더 이상 위임할 수 없습니다.
NTLM 및 제한된 위임 대상이 파일 공유인 경우 중간 계층 서비스 계정의 위임 유형은 제한-Kerberos가 아닌 제한-모든 계정이어야 합니다.

참고 항목

일반적으로 이중 홉에는 여러 원격 컴퓨터에서 사용자 자격 증명 위임이 포함됩니다. 예를 들어 SQL2라는 원격 SQL Server에 연결된 서버를 만든 SQL1이라는 SQL Server 인스턴스가 있다고 가정합니다. 연결된 서버 보안 구성에서 로그인의 현재 보안 컨텍스트를 사용하여 수행할 옵션을 선택했습니다. 이 구성을 사용하는 경우 Client1이라는 원격 클라이언트 컴퓨터에서 SQL1에서 연결된 서버 쿼리를 실행하는 경우 Windows 자격 증명은 먼저 Client1에서 SQL1로 홉한 다음 SQL1에서 SQL2로 홉해야 합니다(따라서 이중 홉이라고 함). 자세한 내용은 Kerberos 더블 홉 및 Kerberos 제한된 위임 개요 이해를 참조하세요.

사용자에 대한 로그인 실패(비어 있음)

이 오류는 사용자가 로그인에 실패할 때 발생합니다. 이 오류는 컴퓨터가 네트워크에 연결되어 있지 않은 경우에 발생할 수 있습니다. 예를 들어 다음과 유사한 오류 메시지가 표시될 수 있습니다.

Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description: This computer was not able to set up a secure session with a domain controller in domain due to the following: The remote procedure call was cancelled.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

빈 문자열은 SQL Server가 LSASS(로컬 보안 기관 하위 시스템 서비스)에 자격 증명을 전달하려고 했지만 일부 문제로 인해 전달하지 못했음을 의미합니다. LSASS를 사용할 수 없거나 do기본 컨트롤러에 연결할 수 없습니다.

다음과 같은 해당 SSPI 오류 코드가 표시될 수도 있습니다.

통합 보안과의 연결을 설정하는 동안 오류 코드 0x80090311 SSPI 핸드셰이크가 실패했습니다. 연결이 닫혔습니다.

통합 보안과의 연결을 설정하는 동안 오류 코드 0x80090304 SSPI 핸드셰이크가 실패했습니다. 연결이 닫혔습니다.

이러한 오류 코드는 다음과 같이 변환됩니다.

오류 -2146893039(0x80090311): 인증을 위해 연락할 수 있는 권한이 없습니다. 오류 -2146893052(0x80090304): 로컬 보안 기관에 연결할 수 없습니다.

이러한 오류를 해결하려면 잘못된 DC를 오프라인으로 전환하거나 NLTEST.EXE 사용하여 DC를 전환할 수 있습니다. - DC를 쿼리하려면 명령을 실행합니다 NLTEST /SC_QUERY:CONTOSO . - DC를 변경하려면 명령을 실행합니다 NLTEST /SC_RESET:CONTOSO\DC03 .

추가 지원이 필요한 경우 Microsoft Active Directory 팀에 문의하세요.

클라이언트 및 서버의 이벤트 로그에서 오류 발생 시 기록된 네트워크 관련 메시지 또는 Active Directory 관련 메시지를 확인합니다. 있는 경우 do기본 관리자와 협력하여 문제를 해결합니다.

'(null)' 사용자에 대해 로그인하지 못했습니다.

"null"이 표시되면 LSASS가 SQL Server 서비스 계정 자격 증명을 사용하여 보안 토큰의 암호를 해독할 수 없다는 의미일 수 있습니다. 이 조건의 기본 이유는 SPN이 잘못된 계정과 연결되어 있기 때문입니다.

이 문제를 해결하려면 다음 단계를 수행합니다.

  1. SQLCheck 또는 Setspn.exe 사용하여 SPN 관련 문제를 진단하고 해결합니다.

  2. SQLCheck를 사용하여 SQL 서비스 계정이 위임에 대해 신뢰할 수 있는지 여부를 검사. 출력에서 계정이 위임에 대해 신뢰할 수 없다는 것을 나타내는 경우 Active Directory 관리자와 협력하여 계정에 대한 위임을 사용하도록 설정합니다.

참고 항목

SETSPN -X-Q 중복되거나 잘못 배치된 SPN에 대해 검사 유용한 명령입니다.

  1. DNS(Do기본 이름 시스템) 이름 확인 문제를 진단하고 수정합니다. 예시:

    • PowerShell 스크립트를 사용하여 IP 주소 Ping:

      • ping -a <your_target_machine>(특히 IPv4 및 -6 IPv6에 사용-4)
      • ping -a <your_remote_IPAddress>

    • NSLookup을 사용하여 로컬 및 원격 컴퓨터 이름과 IP 주소를 여러 번 입력합니다.

  2. 반환된 결과에서 불일치 및 불일치를 찾습니다. 성공적인 SQL Server 연결을 위해서는 네트워크에서 DNS 구성의 정확도가 중요합니다. 잘못된 DNS 항목으로 인해 나중에 수많은 연결 문제가 발생할 수 있습니다.

  3. 방화벽 또는 다른 네트워크 디바이스가 클라이언트가 do기본 컨트롤러에 연결하는 것을 차단하지 않는지 확인합니다. SPN은 Active Directory에 저장됩니다. 클라이언트가 디렉터리와 통신할 수 없는 경우 연결에 성공할 수 없습니다.

추가 오류 정보

보안을 강화하기 위해 클라이언트에 반환되는 오류 메시지는 의도적으로 인증 오류의 특성을 숨깁니다. 그러나 SQL Server 오류 로그에서 해당 오류에는 인증 실패 조건에 매핑되는 오류 상태가 포함됩니다. 로그인 실패 이유를 확인하려면 오류 상태를 다음 목록과 비교합니다.

시스템 상태 설명
1 오류 정보를 사용할 수 없습니다. 이 상태는 일반적으로 오류 세부 정보를 받을 수 있는 권한이 없다는 것을 의미합니다. 자세한 내용은 SQL Server 관리자에게 문의하세요.
2 사용자 ID가 잘못되었습니다.
5 사용자 ID가 잘못되었습니다.
6 SQL Server 인증에서 Windows 로그인 이름을 사용하려고 했습니다.
7 로그인을 사용할 수 없으며 암호가 올바르지 않습니다.
8 암호가 잘못되었습니다.
9 암호가 잘못되었습니다.
11 로그인이 유효하지만 서버 액세스에 실패했습니다. 이 오류의 한 가지 가능한 원인은 Windows 사용자가 로컬 관리자 그룹의 구성원으로 SQL Server에 액세스할 수 있지만 Windows에서 관리자 자격 증명을 제공하지 않는 경우입니다. 연결하려면 관리자 권한으로 실행 옵션을 사용하여 연결 프로그램을 시작한 다음 WINDOWS 사용자를 SQL Server에 특정 로그인으로 추가합니다.
12 로그인이 유효한 로그인이지만 서버 액세스에 실패했습니다.
18 암호를 변경해야 합니다.
38, 46 사용자가 요청한 데이터베이스를 찾을 수 없습니다.
58 SQL Server가 Windows 인증만 사용하도록 설정되어 있고 클라이언트가 SQL 인증을 사용하여 로그인을 시도하는 경우 또 다른 원인은 SID가 일치하지 않는 경우입니다.
102 - 111 Azure AD 오류입니다.
122 - 124 빈 사용자 이름 또는 암호로 인한 오류입니다.
126 사용자가 요청한 데이터베이스가 없습니다.
132 - 133 Azure AD 오류입니다.

다른 오류 상태가 존재하며 예기치 않은 내부 처리 오류를 나타냅니다.

더 드문 가능한 원인

오류 원인 SQL 인증을 사용하여 로그인하지 못했습니다. 서버는 Windows 인증 대해서만 구성됩니다. 다음과 같은 상황에서 반환할 수 있습니다.

  • 서버가 혼합 모드 인증을 위해 구성되고 ODBC 연결이 TCP 프로토콜을 사용하는 경우 연결에서 신뢰할 수 있는 연결을 사용하도록 명시적으로 지정하지 않습니다.

  • SQL Server가 혼합 모드 인증을 위해 구성되고 ODBC 연결에서 명명된 파이프를 사용하고 명명된 파이프를 여는 데 사용되는 자격 증명이 사용자를 자동으로 가장하는 데 사용되며 연결 문자열 신뢰할 수 있는 인증 사용을 명시적으로 지정하지 않습니다.

이 문제를 해결하려면 연결 문자열 포함합니다TRUSTED_CONNECTION = TRUE.

예제

이 예제에서 인증 오류 상태는 8입니다. 암호가 올바르지 않음을 나타냅니다.

날짜 원본 메시지
2007-12-05 20:12:56.34 로그온 오류: 18456, 심각도: 14, 상태: 8.
2007-12-05 20:12:56.34 로그온 사용자 'user_name>'<에 대한 로그인이 실패했습니다. [CLIENT: <ip address>]

참고 항목

SQL Server가 Windows 인증 모드를 사용하여 설치되고 나중에 SQL Server 및 Windows 인증 모드 로 변경되면 sa 로그인이 처음에 비활성화됩니다. 이로 인해 "사용자 'sa'에 대한 로그인이 실패했습니다." 상태 7 오류가 발생합니다. sa 로그인을 사용하도록 설정하려면 서버 인증 모드 변경을 참조하세요.

참고 항목