AD FS 페더레이션 메타데이터 자동 업데이트 및 SSL 핸드셰이크 오류 (Event ID 317) 조치

안녕하세요 Min-joon 님,

말씀하신 AD FS 환경에서 발생하는 Event ID 317 오류는 페더레이션 메타데이터 자동 업데이트가 SSL/TLS 핸드셰이크 문제로 실패할 때 흔히 나타납니다. 이 경우 두 가지 접근이 필요합니다. 하나는 즉각적인 수동 메타데이터 갱신, 다른 하나는 SSL/TLS 계층 문제를 근본적으로 해결하는 것입니다.

먼저 수동 갱신은 PowerShell에서 Update-AdfsRelyingPartyTrust cmdlet을 사용하면 됩니다. 기본 구문은 다음과 같습니다:

powershell

Update-AdfsRelyingPartyTrust -TargetName "<Relying Party Display Name>"

여기서 <Relying Party Display Name>은 AD FS 관리 콘솔에서 해당 파트너 트러스트의 표시 이름과 정확히 일치해야 합니다. 만약 메타데이터 URL이 변경되었거나 SSL 인증서 문제가 의심된다면, Set-AdfsRelyingPartyTrust -TargetName "<Name>" -MetadataUrl "https://partner.domain/federationmetadata/2007-06/federationmetadata.xml" 명령으로 URL을 갱신한 뒤 다시 Update-AdfsRelyingPartyTrust를 실행하는 것이 안전합니다.

SSL/TLS 핸드셰이크 오류는 주로 세 가지 원인에서 발생합니다. 첫째, 방화벽이나 프록시가 TLS 1.2 이상을 지원하지 않는 경우입니다. 이때는 AD FS 서버와 네트워크 경로 상의 모든 장비에서 TLS 1.2 이상이 활성화되어 있는지 확인해야 합니다. 둘째, 파트너가 사용하는 SSL 인증서의 루트 CA가 로컬 서버에 설치되지 않았거나 갱신되지 않은 경우입니다. certlm.msc에서 신뢰할 수 있는 루트 인증서를 확인하고 최신 루트 CA를 배포해야 합니다. 셋째, 암호화 스위트 불일치입니다. AD FS는 기본적으로 Windows Schannel 설정을 따르므로, 레지스트리 경로 HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites에서 지원되는 암호화 패키지를 검증하고, 파트너 측과 호환되는지 확인해야 합니다.

재발 방지를 위해서는 AD FS 자동 메타데이터 업데이트가 실패하지 않도록 모니터링 체계를 구축하는 것이 중요합니다. 일반적으로는 System Center Operations Manager(SCOM)이나 Azure Monitor를 활용해 AD FS 이벤트 로그(Event ID 317, 364 등)를 주기적으로 수집하고 알림을 설정합니다. 또한 파트너 메타데이터 URL에 대해 Invoke-WebRequest -Uri "https://partner.domain/federationmetadata/2007-06/federationmetadata.xml" 같은 간단한 PowerShell 헬스 체크 스크립트를 예약 작업으로 실행하여 SSL 인증서 유효성, 응답 상태 코드(200 OK 여부)를 검증하는 방식이 효과적입니다.

정리하면, 지금은 Update-AdfsRelyingPartyTrust로 수동 갱신을 먼저 시도하시고, 병행해서 TLS 지원, 루트 인증서, 암호화 스위트 호환성을 점검하셔야 합니다. 이후에는 모니터링 체계를 통해 자동 업데이트 실패를 조기에 탐지하는 것이 최선입니다.여기서 유용한 정보를 얻으셨기를 바랍니다. 이 내용이 문제에 대한 통찰을 얻는 데 도움이 되었다면 답변을 채택해 주시면 감사하겠습니다. 추가로 궁금한 점이 있으시면 언제든지 메시지를 남겨 주세요. 좋은 하루 보내세요!

HP.