[MSSQL] ERROR 18452 로그인 실패

MSSQL ERROR 18452 로그인 실패

1️⃣ 오류 개요

MSSQL ERROR 18452 – Login failed. Not associated with a trusted SQL Server connection 오류는 클라이언트가 SQL Server에 로그인 시도는 했지만, 서버가 해당 연결을 신뢰할 수 있는 보안 컨텍스트로 인식하지 못할 때 발생한다. 주로 다음과 같은 환경에서 자주 보고된다.

• Kerberos 또는 Active Directory(AD) 인증 체계에 문제가 있는 경우
• SQL Server가 Windows 인증 전용 모드인데 SQL 로그인으로 접속을 시도하는 경우
• 도메인 간 트러스트(Trust) 관계가 깨졌거나, 잘못된 도메인 계정으로 접속할 때

MSSQL ERROR 18452
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Not associated with a trusted SQL Server connection.
    

핵심 포인트:
- 로그인 자체는 도달했지만 보안 컨텍스트 검증 단계에서 실패
- Kerberos/AD, 인증 모드, 연결 문자열 설정을 먼저 의심해야 함

2️⃣ 발생 환경과 대표 증상

ERROR 18452는 특히 도메인 기반 인증이 중요한 다음 환경에서 자주 발생한다.

• 사내 AD 도메인에 가입된 Windows 클라이언트 → 도메인 계정으로 SQL Server 접속
• Azure SQL / Managed Instance 환경에서 AAD 인증 또는 Windows 인증 사용 시도
• 도메인에 가입되지 않은 PC에서 도메인 계정으로 로그인 시도
• 리눅스·중간 애플리케이션 서버를 거쳐 더블 홉(2-hop)으로 MSSQL에 접속하는 구조

증상은 다음과 같다.

• SSMS, 애플리케이션, ODBC 모두 동일하게 로그인 실패
• 같은 계정이라도 특정 PC에서는 접속 가능하지만, 다른 PC에서는 ERROR 18452 발생
• SQL Server ERRORLOG에 18452 로그인 실패 기록이 반복적으로 남음

3️⃣ 주요 원인

■ 1) 인증 모드와 로그인 방식 불일치

• 서버가 Windows 인증 모드(Windows only)인데, SQL 로그인으로 접속 시도
• 반대로 SQL 로그인만 허용되는데, 도메인 계정으로 Windows 인증 접속 시도

■ 2) Kerberos·AD 문제

• 도메인 컨트롤러와의 통신 오류 또는 트러스트 관계 손상
• SPN(Service Principal Name) 미등록 또는 중복 등록
• 서버/클라이언트 시스템 시간 불일치(NTP 설정 오류)
• DNS 역방향 조회 문제로 올바른 SPN을 찾지 못하는 경우

■ 3) 네트워크·토폴로지 이슈

• 중간 애플리케이션 서버를 거치는 더블 홉(Delegation) 환경에서 Kerberos 위임 미구성
• VPN, 방화벽, 로드밸런서를 사용할 때 원래 클라이언트 정보가 올바르게 전달되지 않는 경우

정리하면,
- 인증 모드 설정 오류
- Kerberos/AD 인프라 이상
- 네트워크 토폴로지 및 Delegation 설정 문제
이 세 가지 축에서 원인을 찾는 것이 ERROR 18452 분석의 핵심이다.

4️⃣ 분석 절차

■ 1) SQL Server 인증 모드 확인

-- 현재 인증 모드 확인 (레지스트리 또는 서버 속성 GUI로도 확인 가능)
EXEC xp_instance_regread
  N'HKEY_LOCAL_MACHINE',
  N'Software\Microsoft\MSSQLServer\MSSQLServer',
  N'LoginMode';

-- 결과
-- 1 = Windows 인증 모드
-- 2 = 혼합 모드(Windows + SQL Server 인증)
    

클라이언트에서 사용하는 접속 방식(Windows 인증인지, SQL 로그인인지)과 실제 서버 인증 모드가 일치하는지 먼저 확인한다.

■ 2) ERRORLOG 및 로그인 시도 정보 확인

-- 최근 로그인 실패 기록 조회 (SQL 2012 이상: sys.dm_exec_sessions, sys.dm_exec_connections 등 활용)
EXEC xp_readerrorlog 0, 1, 'Error: 18452';
    

• 어떤 계정, 어떤 IP/호스트에서 실패하는지 확인
• 특정 애플리케이션 서버나 특정 사용자에 국한되는지 파악

■ 3) Kerberos·SPN 상태 점검(요약)

• 도메인에서 setspn -L <서비스계정> 명령으로 SPN 등록 상태 확인
• 중복된 SPN이 있는지, MSSQL 서비스 계정에 올바르게 등록되어 있는지 확인
• 서버와 도메인의 시간 동기화(NTP) 상태 확인

5️⃣ 조치 방법

■ 1) 인증 모드 정정

• SQL 로그인 사용이 필요하다면 SQL Server를 혼합 모드(Windows + SQL)로 변경
• 반대로 보안 정책상 Windows 인증만 허용해야 한다면, 모든 애플리케이션이 도메인 계정 기반으로 접속하도록 수정

인증 모드 변경은 SSMS의 서버 속성 > 보안 탭에서 수행 후 서비스 재시작이 필요하다.

■ 2) Kerberos·AD 관련 조치

• MSSQL 서비스 계정에 올바른 SPN 등록

  
  setspn -S MSSQLSvc/server-name:1433 domain\sqlservice
  setspn -S MSSQLSvc/server-fqdn:1433 domain\sqlservice
          

• 중복 SPN 제거 및 DNS 이름/역방향 조회가 일치하도록 정리
• 서버·클라이언트의 시스템 시간이 도메인 컨트롤러와 일치하도록 NTP 재설정
• 더블 홉 구조라면 AD에서 Kerberos delegation(위임) 설정 검토

■ 3) 연결 문자열 및 계정 사용 방식 점검

• 애플리케이션 연결 문자열에서 Trusted_Connection=Yes 또는 Integrated Security=SSPI 사용 시, 실제 실행 계정이 도메인에 가입된 계정인지 확인
• 로컬 계정 또는 도메인 밖 계정으로 실행된다면, 명시적인 SQL 로그인 또는 서비스 계정 변경 필요
• Azure SQL / Managed Instance의 경우 AAD 인증 사용 시, 토큰·계정 권한·방화벽 규칙을 함께 검토

실무 팁:
- 같은 계정으로 서버 콘솔에서 SSMS 로그인 테스트
- 도메인 로그인은 정상인데 애플리케이션에서만 실패한다면, 애플리케이션 실행 계정·연결 문자열을 집중 점검

6️⃣ 예방 전략

• 정기적으로 SPN·DNS·시간 동기화 상태 점검
• 신규 SQL 인스턴스 구축 시 인증 모드 정책을 명확히 정의
• 애플리케이션 개발 시 인증 방식(Windows / SQL)을 설계 단계에서 결정하고 문서화
• 도메인 트러스트 변경, 계정 정책 변경 시 주요 DB 시스템과의 영향 분석 수행
• 로그인 실패 알람(18452, 18456 등)을 모니터링 시스템에 연동하여 조기 탐지

7️⃣ 기본 오류 대응 4단계

1단계 원인 파악
- ERRORLOG에서 18452 발생 계정·호스트·시간대 확인
- 인증 모드와 접속 방식 일치 여부 점검

2단계 영향 범위 확인
- 특정 사용자/서버에 국한된 문제인지, 전사적 장애인지 구분

3단계 임시 조치
- 긴급히 필요한 계정은 임시로 SQL 로그인 생성 또는 대체 계정 제공
- 운영 중단을 최소화하는 범위 내에서 인증 모드·연결 문자열 임시 수정

4단계 근본 원인 제거
- Kerberos·SPN·DNS·시간 동기화 재정비
- 인증 정책·애플리케이션 설정을 장기적으로 일관성 있게 재구성

8️⃣ 오류 분석 흐름도

• 외부 노출 확인: 로그인 실패가 외부 네트워크에서도 발생하는지 여부 점검
• 역할·기능 비활성화: 불필요한 테스트 계정·임시 계정 즉시 잠금
• 포트·경로 관리: 관리되지 않는 중간 서버·우회 경로 차단
• 로그 모니터링: ERROR 18452·18456 패턴을 상시 관제하여 재발 여부 확인