%EB%A5%BC%20%EB%B9%84%ED%99%9C%EC%84%B1%ED%99%94%ED%95%A0%20%EC%88%98%20%EC%97%86%EC%8A%B5%EB%8B%88%EB%8B%A4..png)
저는 Windows 도메인 내에서 내부적으로 호스팅되는 웹 응용 프로그램용 NTLM을 대체하기 위해 Kerberos SSO(Single Sign On)를 탐색해 왔습니다.
테스트 서비스에 대한 SPN(서비스 사용자 이름)을 생성한 후(setspn -s) Fiddler 또는 WireShark를 사용하여 인증이 NTLM에서 Kerberos로 전환되었음을 명확하게 확인할 수 있습니다.
신중한 인프라 팀을 보유하면 변경 사항을 빠르고 쉽게 취소할 수 있음을 증명하고 싶습니다. 웹 서버 구성을 통해 NTLM을 강제로 적용하고 싶지 않습니다. 이에 따라 SPN이 삭제되고(setspn -d) 삭제가 확인됩니다(setspn -q).
클라이언트에서 모든 서비스 티켓을 제거하려면 다음 명령을 실행합니다.
C:\>klist purge
Current LogonId is 0:0x521ac
Deleting all tickets:
Ticket(s) purged!
C:\>
웹 응용 프로그램과 추가 상호 작용이 발생하면 또 다른 서비스 티켓이 생성되고 Kerberos는 계속해서 SSO 인증 메커니즘으로 사용됩니다. 이는 이전에 서비스를 사용한 적이 없는 사용자에게도 적용됩니다. 모든 상호 작용이 밤새(12~14시간) 유휴 상태가 된 다음 날에도 마찬가지입니다.
관찰된 지속성에 대한 설명을 찾기 위해 반복적으로 검색했지만 빈손으로 나왔습니다. 하지만 기사에서 단서를 찾은 것 같습니다.사용자 이름이 변경된 경우 LsaLookupSids 함수는 새 사용자 이름 대신 이전 사용자 이름을 반환할 수 있습니다.:
LSA(로컬 보안 기관)는 SID와 사용자 이름 간의 매핑을 도메인 구성원 컴퓨터의 로컬 캐시에 캐시합니다. 캐시된 사용자 이름은 도메인 컨트롤러와 동기화되지 않습니다. 도메인 구성원 컴퓨터의 LSA는 먼저 로컬 SID 캐시를 쿼리합니다. 기존 매핑이 이미 로컬 SID 캐시에 있는 경우 LSA는 도메인 컨트롤러에 쿼리하는 대신 캐시된 사용자 이름 정보를 반환합니다. 이 동작은 성능을 향상시키기 위한 것입니다.
캐시 항목은 시간 초과되지만 응용 프로그램의 반복 쿼리로 인해 캐시 항목의 최대 수명 동안 기존 캐시 항목이 활성 상태로 유지될 가능성이 있습니다.
KDC(키 배포 센터)가 비슷한 방식으로 SPN 항목을 캐시하는지 확인할 수 있습니까(또는 대체 설명을 제공할 수 있습니까?) 그렇다면 캐시 항목의 최대 수명은 얼마나 됩니까?
답변1
문제를 발견했습니다. 서비스의 DNS 레코드는 "A" 레코드가 아니라 실제로 "CNAME" 레코드였습니다. 이는 브라우저가 서비스 계정에 대한 키를 생성했음을 의미합니다. 이는 "False"(기본값)로 설정된 사이트/서버의 "useAppPoolCredentials" 설정과 관련이 있습니다. 변경한 SPN은 진행 중인 Kerberos 인증에 참여하지 않았습니다.