gMSA 계정이 자동으로 순환되면 약 1~10분 동안 로그인 실패가 발생합니다. 이는 MS SQL 서버에 연결하는 gMSA 클라이언트 계정에서 특히 두드러지지만 다른 gMSA 계정에서도 발생하는 것 같습니다. MS SQL 서버는 gMSA 계정으로 실행되지 않지만 우리 애플리케이션은 gMSA를 사용하여 클라이언트를 SQL에 연결합니다. 기본적으로 ManagedPasswordIntervalInDays는 30일마다이므로 매월 동시에 볼 수 있습니다.
도메인 컨트롤러 로그를 확인할 때 gMSA 사용자에 대한 로그인 실패는 표시되지 않지만 SQL Server는 다음 오류를 기록합니다.
통합 보안을 사용하여 연결을 설정하는 동안 오류 코드 0x8009030c, 상태 14로 인해 SSPI 핸드셰이크가 실패했습니다. 연결이 닫혔습니다. 이유: AcceptSecurityContext가 실패했습니다. 운영 체제 오류 코드는 실패 원인을 나타냅니다. 로그온 시도가 실패했습니다. [클라이언트: xxxx]
내가 찾은 바에 따르면 이 오류는 일반적으로 잘못된 사용자 이름/비밀번호 조합을 나타냅니다.
이는 여러 클라이언트에서 발생하며 각 클라이언트는 결국 1~10분 후에 다시 연결되기 시작합니다. 클라이언트가 모두 동시에 연결을 시작하지는 않지만 해당 시간 창 내에서 무작위로 연결되는 것 같습니다.
처음에는 변경된 비밀번호의 AD 복제와 관련이 있을 것이라고 생각하여 기본 사이트 간 복제 간격을 USE_NOTIFY로 수정하여 즉시 복제했습니다. 복제가 문제인 경우 DC에서는 로그인 실패가 발생할 것으로 예상되지만 DC에서는 로그온 실패가 표시되지 않습니다. 또한 SQL 서버가 인증 토큰을 캐싱하고 있을 수도 있다고 생각했지만, 그렇다면 모든 클라이언트가 동시에 해결되는 것을 볼 수 있을 것으로 예상합니다(예: SQL 서버가 새로 고쳐질 때). 클라이언트가 각각 다시 작업을 시작합니다. 다른 때에는 SQL 서버 측에 있는 것처럼 보이지 않지만 클라이언트 측에 있을 가능성이 더 높습니다. gMSA 비밀번호를 캐싱하거나 시간 초과 및 백오프 재시도와 관련된 것일 수 있습니다.
답변1
gMSA가 Kerberos 대신 NTLM을 통해 SQL Server에 인증하게 만드는 SPN 문제로 인해 동일한 오류가 발생했습니다. SQL Server에 로그인하여 세션을 확인하면 sys.dm_exec_connectionsNTLM을 사용한 세션 목록이 표시됩니다.
klist sessions( CLI에서 세션을 볼 수도 있습니다 )
우리는 로그 분석 도구를 사용하여 오류와 비밀번호 변경의 상관 관계를 파악할 수 있었기 때문에 그것이 범인이라는 것을 알았습니다. SCM이 비밀번호 사본을 얼마나 자주 새로 고치는지 모르지만 서비스가 SQL Server를 인증하고 Kerberos를 사용하는 경우 비밀번호 변경은 Kerberos 세션 수명/갱신과 독립적이어야 하므로 생성된 오류는 다음과 같은 확실한 단서입니다. 비밀번호는 NTLM을 통해 SQL Server 호스트로 전송됩니다. 추가 DNS A 레코드로 인해 발생한 SPN 문제를 해결한 후 세션은 Kerberos 인증으로 전환되었습니다.
답변2
나는 이것이 Windows 서비스가 구성된 방식 때문이라는 것을 알았습니다. Windows 서비스는 관리 계정을 사용하는 Windows 서비스가 아닌 gMSA 계정인 일반 사용자 계정을 사용하여 표준 서비스로 구성되었습니다.
이는 다음을 통해 확인할 수 있습니다.
>sc.exe qmanagedaccount ServiceName
[SC] QueryServiceConfig2 SUCCESS
ACCOUNT MANAGED : FALSE
이는 다음을 실행하여 변경할 수 있습니다.
sc.exe managedaccount ServiceName TRUE
관리할 Windows 서비스 계정 유형을 변경한 후 초기 테스트에서는 이제 gMSA 암호 교체 중에 로그인이 성공한 것으로 나타났습니다.