다음을 통해 공유


AD FS용 Microsoft Entra Connect Health 에이전트

이 문서에서는 Microsoft Entra Connect Health 에이전트를 설치하고 구성하는 방법에 관해 설명합니다. 다음 설명서는 Microsoft Entra Connect Health를 사용하여 AD FS 인프라를 설치 및 모니터링하는 것과 관련이 있습니다. Microsoft Entra Connect Health를 사용하여 Microsoft Entra Connect(동기화)를 모니터링하는 방법에 대한 자세한 내용은 동기화용 Microsoft Entra Connect Health 사용을 참조하세요. 또한 Microsoft Entra Connect Health를 사용하여 Active Directory Domain Services를 모니터링하는 방법에 대한 자세한 내용은 AD DS와 함께 Microsoft Entra Connect Health 사용을 참조하세요.

에이전트를 다운로드하는 방법을 알아봅니다.

참고 항목

Microsoft Entra Connect Health는 중국 소버린 클라우드에서 사용할 수 없습니다.

요구 사항

다음 표는 Microsoft Entra Connect Health를 사용하기 위한 요구 사항 목록입니다.

요구 사항 설명
Microsoft Entra ID P1 또는 P2 구독이 있습니다. Microsoft Entra Connect Health는 Microsoft Entra ID P1 또는 P2의 기능입니다. 자세한 내용은 Microsoft Entra ID P1 또는 P2 등록을 참조하세요.

30일 평가판을 시작하려면 평가판 시작을 참조하세요.
사용자는 Microsoft Entra ID의 전역 관리자입니다. 현재 전역 관리자 계정만 상태 에이전트를 설치하고 구성할 수 있습니다. 자세한 내용은 Microsoft Entra 디렉터리 관리를 참조하세요.

Azure RBAC(역할 기반 액세스 제어)를 사용하여 조직의 다른 사용자가 Microsoft Entra Connect Health에 액세스하는 것을 허용할 수 있습니다. 자세한 내용은 Microsoft Entra Connect Health를 위한 Azure RBAC를 참조하세요.

중요: 회사 또는 학교 계정을 사용하여 에이전트를 설치하세요. Microsoft 계정을 사용하여 에이전트를 설치할 수 없습니다. 자세한 내용은 조직으로 Azure 가입을 참조하세요.
Microsoft Entra Connect Health 에이전트는 각 대상 서버에 설치됩니다. Health 에이전트는 데이터를 수신하고 모니터링 및 분석 기능을 제공할 수 있도록 대상 서버에 설치되고 구성되어야 합니다.

예를 들어 AD FS(Active Directory Federation Services) 인프라에서 데이터를 가져오려면 AD FS 서버와 웹 애플리케이션 프록시 서버에 에이전트를 설치해야 합니다. 마찬가지로 온-프레미스 AD Domain Services 인프라에서 데이터를 가져오려면 도메인 컨트롤러에 에이전트를 설치해야 합니다.
Azure 서비스 엔드포인트에 아웃바운드 연결이 있습니다. 에이전트는 설치 및 런타임 중에 Microsoft Entra Connect Health 서비스 엔드포인트에 연결되어야 합니다. 방화벽이 아웃바운드 연결을 차단하는 경우에는 아웃바운드 연결 엔드포인트를 허용 목록에 추가합니다.
아웃바운드 연결은 IP 주소를 기반으로 합니다. IP 주소를 기반으로 하는 방화벽 필터링에 대한 자세한 내용은 Azure IP 범위를 참조하세요.
아웃바운드 트래픽에 대한 TLS 검사를 필터링하거나 사용하지 않도록 설정합니다. 네트워크 계층에서 아웃바운드 트래픽에 대해 TLS 검사 또는 종료가 이루어지는 경우 에이전트 등록 단계 또는 데이터 업로드 작업이 실패할 수 있습니다. 자세한 내용은 TLS 검사 설정을 참조하세요.
서버의 방화벽 포트에서 에이전트를 실행 중입니다. 에이전트는 Microsoft Entra Connect Health 서비스 엔드포인트와 통신할 수 있도록 다음 방화벽 포트가 열려 있어야 합니다.
- TCP 포트 443
- TCP 포트 5671

최신 버전의 에이전트에는 포트 5671이 필요하지 않습니다. 포트 443만 필요하도록 최신 버전으로 업그레이드합니다. 자세한 내용은 포트 및 프로토콜이 필요한 하이브리드 ID를 참조하세요.
Internet Explorer 보안 강화가 사용하도록 설정된 경우 지정된 웹 사이트를 허용합니다. Internet Explorer 보안 강화가 사용하도록 설정된 경우 에이전트를 설치한 서버에서 다음 웹 사이트를 허용합니다.
- https://login.microsoftonline.com
- https://secure.aadcdn.microsoftonline-p.com
- https://login.windows.net
- https://aadcdn.msftauth.net
- Microsoft Entra ID에서 신뢰할 수 있는 조직의 페더레이션 서버(예: https://sts.contoso.com)

자세한 내용은 Internet Explorer를 구성하는 방법을 참조하세요. 네트워크에 프록시가 있는 경우 이 표 끝에 나오는 정보를 참조하세요.
PowerShell 버전 5.0 이상이 설치되어 있습니다. Windows Server 2016에는 PowerShell 버전 5.0이 포함되어 있습니다.

Important

Windows Server Core는 Microsoft Entra Connect Health 에이전트 설치를 지원하지 않습니다.

참고 항목

매우 폐쇄적이고 제약이 많은 환경을 사용하는 경우에는 Internet Explorer 보안 강화 표에 나와 있는 것보다 많은 URL을 추가해야 합니다. 또한 다음 섹션의 표에 나와 있는 URL을 추가합니다.

에이전트의 새 버전 및 자동 업그레이드

새 버전의 Health Agent가 릴리스되면 기존에 설치된 모든 에이전트가 자동으로 업데이트됩니다.

Azure 서비스 엔드포인트에 대한 아웃바운드 연결

에이전트는 설치 및 런타임 중에 Microsoft Entra Connect Health 서비스 엔드포인트에 연결되어야 합니다. 방화벽이 아웃바운드 연결을 차단하는 경우에는 다음 표에 나와 있는 URL이 기본적으로 차단되지 않아야 합니다.

해당 URL에 대해 보안 모니터링 또는 검사를 사용하지 않도록 하지 마세요. 대신 다른 인터넷 트래픽을 허용하는 것처럼 허용하세요.

해당 URL은 Microsoft Entra Connect Health 서비스 엔드포인트와의 통신을 허용합니다. 이 문서의 뒷부분에서는 Test-AzureADConnectHealthConnectivity를 사용하여 아웃바운드 연결을 확인하는 방법을 알아봅니다.

도메인 환경 필수 Azure 서비스 엔드포인트
일반 공개 - *.blob.core.windows.net
- *.aadconnecthealth.azure.com
- **.servicebus.windows.net - 포트: 5671(5671이 차단되면 에이전트는 443으로 대체되지만 포트 5671을 사용하는 것이 좋습니다. 이 엔드포인트는 최신 버전의 에이전트에서 필요하지 않습니다.)
- *.adhybridhealth.azure.com/
- https://management.azure.com
- https://policykeyservice.dc.ad.msft.net/
- https://login.windows.net
- https://login.microsoftonline.com
- https://secure.aadcdn.microsoftonline-p.com
- https://www.office.com (이 엔드포인트는 등록하는 동안 검색 용도로만 사용합니다.)
- https://aadcdn.msftauth.net
- https://aadcdn.msauth.net
- https://autoupdate.msappproxy.net
- https://www.microsoft.com
Azure Government - *.blob.core.usgovcloudapi.net
- *.servicebus.usgovcloudapi.net
- *.aadconnecthealth.microsoftazure.us
- https://management.usgovcloudapi.net
- https://policykeyservice.aadcdi.azure.us
- https://login.microsoftonline.us
- https://secure.aadcdn.microsoftonline-p.com
- https://www.office.com (이 엔드포인트는 등록하는 동안 검색 용도로만 사용합니다.)
- https://aadcdn.msftauth.net
- https://aadcdn.msauth.net
- https://autoupdate.msappproxy.us
- http://www.microsoft.com
- https://www.microsoft.com

에이전트 다운로드

Microsoft Entra Connect Health 에이전트를 다운로드하여 설치하려면 다음을 수행합니다.

AD FS용 에이전트를 설치

참고 항목

AD FS 서버는 동기화 서버와 다릅니다. 동기화 서버에 AD FS 에이전트를 설치하지 마세요.

참고 항목

동기화용 Health 에이전트는 Microsoft Entra Connect의 일부로 설치됩니다(버전 1.0.9125.0 이상). Microsoft Entra Connect 서버에 이전 버전의 AD FS용 상태 에이전트를 설치하려고 하면 오류가 발생합니다. 컴퓨터에 AD FS용 상태 에이전트를 설치해야 하는 경우 최신 버전을 다운로드한 다음 Microsoft Entra Connect 설치 중에 설치된 버전을 제거해야 합니다.

에이전트를 설치하기 전에 AD FS 서버 호스트 이름이 고유하고 AD FS 서비스에 없는지 확인합니다.

에이전트 설치를 시작하려면 다운로드한 .exe 파일을 두 번 클릭합니다. 첫 번째 대화 상자에서 설치를 선택합니다.

Microsoft Entra Connect Health AD FS 에이전트의 설치 창을 보여 주는 스크린샷

메시지가 표시되면 에이전트를 등록할 권한이 있는 Microsoft Entra 계정을 사용하여 로그인합니다. 기본적으로 하이브리드 ID 관리자 계정에는 권한이 있습니다.

Microsoft Entra Connect Health AD FS에 대한 로그인 창을 보여 주는 스크린샷

로그인하면 설치 프로세스가 완료되고 창을 닫을 수 있습니다.

Microsoft Entra Connect Health AD FS 에이전트 설치에 대한 확인 메시지를 보여 주는 스크린샷

이 시점에서 에이전트가 필요한 데이터를 클라우드 서비스에 안전하게 업로드할 수 있도록 에이전트 서비스가 자동으로 시작됩니다.

에이전트가 설치되었는지 확인하려면 서버에서 다음 서비스를 찾습니다. 구성을 완료했다면 해당 서비스가 실행 중이어야 합니다. 구성을 완료하지 않은 경우 구성이 완료될 때까지 해당 서비스가 중지됩니다.

  • Microsoft Entra Connect 에이전트 업데이터
  • Microsoft Entra Connect Health 에이전트

Microsoft Entra Connect Health AD FS 서비스를 보여 주는 스크린샷

AD FS 감사 사용

참고 항목

이 섹션은 AD FS 서버에만 해당됩니다. 웹 애플리케이션 프록시 서버에서는 이 단계를 완료할 필요가 없습니다.

사용량 현황 분석 기능을 통해 데이터를 수집하고 분석하려면 Microsoft Entra Connect Health Agent에 AD FS 감사 로그의 정보가 필요합니다. 해당 로그는 기본적으로 사용되지 않습니다. AD FS 서버에서 AD FS 감사를 사용하도록 설정하고 AD FS 감사 로그를 찾으려면 다음 절차에 따르세요.

AD FS에 대해 감사를 사용하도록 설정하려면

  1. 시작 화면에서 서버 관리자를 연 다음 로컬 보안 정책을 엽니다. 또는 작업 표시줄에서 서버 관리자를 연 다음, 도구/로컬 보안 정책을 선택합니다.

  2. Security Settings\Local Policies\User Rights Assignment 폴더로 이동합니다. 보안 감사 생성을 두 번 클릭합니다.

  3. 로컬 보안 설정 탭에서 AD FS 서비스 계정이 나열되어 있는지 확인합니다. 나열되지 않으면 사용자 또는 그룹 추가를 선택하여 AD FS 서비스 계정을 목록에 추가합니다. 그런 다음 확인을 선택합니다.

  4. 감사를 사용하도록 설정하려면 관리자 권한으로 명령 프롬프트 창을 열고 다음 명령을 실행합니다. auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable

  5. 로컬 보안 정책을 닫습니다.

    Important

    나머지 단계는 기본 AD FS 서버에만 필요합니다.

AD FS 서버에서 감사 속성 사용

  1. AD FS 관리 스냅인을 엽니다. (서버 관리자에서 도구>AD FS 관리를 선택합니다.)
  2. 작업 창에서 페더레이션 서비스 속성 편집을 선택합니다.
  3. 페더레이션 서비스 속성 대화 상자에서 이벤트 탭을 선택합니다.
  4. 성공 감사실패 감사 확인란을 선택한 다음, 확인을 선택합니다. 성공 감사 및 실패 감사는 기본적으로 사용하도록 설정되어야 합니다.

AD FS 서버에서 감사 속성 사용

Important

이 단계는 기본 AD FS 서버에만 필요합니다.

  1. PowerShell 창을 열고 다음 명령을 실행합니다.

    Set-AdfsProperties -AuditLevel Verbose

기본적으로 “기본” 감사 수준이 사용됩니다. 자세한 내용은 Windows Server 2016의 AD FS 감사 기능 향상을 참조하세요.

자세한 정보 로깅 확인

자세한 정보 로깅이 사용하도록 설정되어 있는지 확인하려면 다음을 수행합니다.

  1. PowerShell 창을 열고 다음 명령을 실행합니다.

    Get-AdfsProperties

  2. Auditlevel이 자세한 정보 표시로 설정되어 있는지 확인

AD FS 서비스 계정 감사 설정 확인

  1. Security Settings\Local Policies\User Rights Assignment 폴더로 이동합니다. 보안 감사 생성을 두 번 클릭합니다.
  2. 로컬 보안 설정 탭에서 AD FS 서비스 계정이 나열되어 있는지 확인합니다. 나열되지 않으면 사용자 또는 그룹 추가를 선택하여 AD FS 서비스 계정을 목록에 추가합니다. 그런 다음 확인을 선택합니다.
  3. 로컬 보안 정책을 닫습니다.

AD FS 감사 로그 검토

AD FS 감사 로그를 사용하도록 설정한 후에는 이벤트 뷰어를 사용하여 AD FS 감사 로그를 확인할 수 있어야 합니다.

  1. 이벤트 뷰어를 엽니다.
  2. Windows 로그로 이동한 다음 보안을 선택합니다.
  3. 오른쪽 창에서 현재 로그 필터링을 선택합니다.
  4. 이벤트 원본AD FS 감사를 선택합니다.
  5. 여기에서 AD FS 이벤트의 전체 목록을 가져올 수 있습니다.

감사 로그에 대한 자세한 내용은 작업 질문을 참조하세요.

AD FS 감사가 선택된 현재 로그 필터링 창을 보여 주는 스크린샷.

Warning

그룹 정책은 AD FS 감사를 사용하지 않도록 설정할 수 있습니다. AD FS 감사를 사용할 수 없는 경우 로그인 활동에 대한 사용 현황 분석을 사용할 수 없습니다. AD FS 감사를 사용하지 않는 그룹 정책이 없는지 확인해야 합니다.

다음 표에서는 감사 수준 이벤트에 해당하는 일반적인 이벤트 목록을 제공합니다.

기본 감사 수준 이벤트
ID 이벤트 이름 이벤트 설명
1200 AppTokenSuccessAudit 페더레이션 서비스에서 유효한 토큰을 발급했습니다.
1201 AppTokenFailureAudit 페더레이션 서비스에서 유효한 토큰을 발급하지 못했습니다.
1202 FreshCredentialSuccessAudit 페더레이션 서비스에서 새 자격 증명의 유효성을 검사했습니다.
1203 FreshCredentialFailureAudit 페더레이션 서비스에서 새 자격 증명의 유효성을 검사하지 못했습니다.

자세한 내용은 여기에서 AD FS 이벤트의 전체 목록을 참조하세요.

자세한 감사 수준 이벤트
ID 이벤트 이름 이벤트 설명
299 TokenIssuanceSuccessAudit 신뢰 당사자에 대한 토큰이 발급되었습니다.
403 RequestReceivedSuccessAudit HTTP 요청이 수신되었습니다. 헤더는 인스턴스 ID가 동일한 감사 510을 참조하세요.
410 RequestContextHeadersSuccessAudit 다음 요청 컨텍스트 헤더가 있습니다.
411 SecurityTokenValidationFailureAudit 토큰 유효성 검사가 실패했습니다. 자세한 내용은 내부 예외를 참조하세요.
412 AuthenticationSuccessAudit 신뢰 당사자 '%4'에 대한 형식 '%3'의 토큰이 인증되었습니다. 발신자 ID는 인스턴스 ID가 동일한 감사 510을 참조하세요.
500 IssuedIdentityClaims 인스턴스 ID가 %1인 이벤트 항목에 대한 자세한 정보입니다. 더 많은 정보가 포함된 동일한 인스턴스 ID를 가진 더 많은 이벤트가 있을 수 있습니다.
501 CallerIdentityClaims 인스턴스 ID가 %1인 이벤트 항목에 대한 자세한 정보입니다. 더 많은 정보가 포함된 동일한 인스턴스 ID를 가진 더 많은 이벤트가 있을 수 있습니다.

자세한 내용은 여기에서 AD FS 이벤트의 전체 목록을 참조하세요.

Microsoft Entra Connect Health 서비스에 대한 연결 테스트

Microsoft Entra Connect Health 에이전트로 인해 Microsoft Entra Connect Health 서비스와의 연결이 끊어집니다. 연결 손실의 원인에는 네트워크 문제, 권한 문제 및 기타 여러 가지 문제가 있을 수 있습니다.

에이전트에서 2시간 넘게 Microsoft Entra Connect Health 서비스에 데이터를 보낼 수 없으면 상태 서비스 데이터가 최신 상태가 아닙니다라는 경고가 포털에 표시됩니다.

다음 PowerShell 명령을 실행하면 영향을 받는 Microsoft Entra Connect Health Agent가 Microsoft Entra Connect Health 서비스에 데이터를 업로드할 수 있는지 확인할 수 있습니다.

Test-AzureADConnectHealthConnectivity -Role ADFS

Role 매개 변수가 현재 다음 값을 사용합니다.

  • ADFS
  • Sync
  • ADDS

참고 항목

연결 도구를 사용하려면 먼저 에이전트를 등록해야 합니다. 에이전트 등록을 완료할 수 없는 경우 Microsoft Entra Connect Health에 대한 요구 사항을 모두 충족했는지 확인합니다. 기본적으로 연결은 에이전트를 등록하는 과정에서 테스트됩니다.

Microsoft Entra Connect Health를 사용하여 AD FS 모니터링

AD FS의 경고

Microsoft Entra Connect Health 경고 섹션은 활성 경고 목록을 제공합니다. 각 경고에는 관련 정보, 해결 단계 및 관련된 설명서 링크가 포함됩니다.

활성 또는 해결된 경고를 두 번 클릭하면 추가 정보, 경고를 해결하기 위해 취할 수 있는 단계와 적절한 설명서 링크가 포함된 새 블레이드가 표시됩니다. 과거에 해결된 경고에 대한 기록 데이터도 볼 수 있습니다.

경고가 선택된 Microsoft Entra Connect Health

AD FS의 사용량 분석

Microsoft Entra Connect Health Usage Analytics는 페더레이션 서버의 인증 트래픽을 분석합니다. 사용량 현황 분석 상자를 두 번 클릭하면, 몇 가지 메트릭 및 그룹화를 보여주는 사용량 현황 분석 블레이드가 열립니다.

참고 항목

AD FS와 사용량 현황 분석을 사용하려면 AD FS 감사가 사용하도록 설정되어 있어야 합니다. 자세한 내용은 AD FS 감사 사용을 참조하십시오.

Microsoft Entra Connect Health

추가 메트릭을 선택하거나, 시간 범위를 지정하거나, 그룹화를 변경하려면 사용량 현황 분석 차트를 마우스 오른쪽 단추로 클릭하고 차트 편집을 선택합니다. 그런 다음 시간 범위를 지정하고 다른 메트릭을 선택하고 그룹화를 변경할 수 있습니다. 다음 섹션에 설명된 다양한 “메트릭”을 기반으로 인증 트래픽 분산을 살펴보고 적절한 “그룹화 기준” 매개 변수를 사용하여 각 메트릭을 그룹화할 수 있습니다.

메트릭: 총 요청 수 - AD FS 서버에서 처리한 총 요청 수.

그룹화 기준 그룹화의 의미 및 그룹화가 유용한 이유
모두 모든 AD FS 서버에서 처리한 총 요청 수를 보여 줍니다.
애플리케이션 대상 신뢰 당사자를 기반으로 전체 요청을 그룹화합니다. 이 그룹화는 전체 트래픽 중 애플리케이션이 수신하는 트래픽의 비율을 이해하는 데 유용합니다.
Server 요청을 처리한 서버를 기반으로 전체 요청을 그룹화합니다. 이 그룹화는 전체 트래픽의 부하 분포를 이해하는 데 유용합니다.
작업 공간 연결 작업 공간이 연결된(알려진) 디바이스의 요청인지 여부를 기반으로 전체 요청을 그룹화합니다. 이 그룹화는 ID 인프라에 알려지지 않은 디바이스를 사용하여 리소스에 액세스하는 경우를 이해하는 데 유용합니다.
인증 방법 인증에 사용된 인증 방법을 기반으로 전체 요청을 그룹화합니다. 이 그룹화는 인증에 사용되는 일반적인 인증 방법을 이해하는 데 유용합니다. 다음은 가능한 인증 방법입니다.
  1. Windows 통합 인증(Windows)
  2. 폼 기반 인증(양식)
  3. SSO(Single Sign On)
  4. X509 인증서 인증(인증서)

  5. 페더레이션 서버가 SSO 쿠키를 사용하 여 요청을 수신하는 경우 해당 요청은 SSO(Single Sign On)로 계산됩니다. 이 경우 쿠키가 유효하면 사용자는 자격 증명을 입력할 필요 없이 효율적으로 애플리케이션에 액세스할 수 있습니다. 페더레이션 서버에서 여러 신뢰 당사자를 보호하는 경우 일반적으로 사용되는 동작입니다.
네트워크 위치 사용자의 네트워크 위치를 기반으로 전체 요청을 그룹화합니다. 네트워크 위치는 인트라넷 또는 엑스트라넷이 될 수 있습니다. 이 그룹화는 인트라넷 트래픽과 엑스트라넷 트래픽의 비율을 파악하는 데 유용합니다.

메트릭: 실패한 총 요청 수 - 페더레이션 서비스에서 처리에 실패한 총 요청 수. (이 메트릭은 Windows Server 2012 R2용 AD FS에서만 사용할 수 있습니다.)

그룹화 기준 그룹화의 의미 및 그룹화가 유용한 이유
오류 유형 미리 정의된 오류 유형을 기반으로 오류의 수를 표시합니다. 이 그룹화는 오류의 일반적인 유형을 이해하는 데 유용합니다.
  • 잘못된 사용자 이름 또는 암호: 잘못된 사용자 이름 또는 암호로 인해 발생하는 오류입니다.
  • "엑스트라넷 잠금": 엑스트라넷에서 잠근 사용자로부터 받은 요청으로 인해 발생하는 오류입니다.
  • "암호 만료": 만료된 암호를 사용하여 로그인하는 사용자로 인해 발생하는 오류입니다.
  • "계정 사용 안 함": 비활성화된 계정으로 로그인하는 사용자로 인해 발생하는 오류입니다.
  • "디바이스 인증": 디바이스 인증을 사용하여 인증에 실패하는 사용자로 인해 발생하는 오류입니다.
  • "사용자 인증서 인증": 잘못된 인증서로 인해 인증에 실패할 사용자로 인해 발생하는 오류입니다.
  • "MFA": 다단계 인증을 사용하여 인증에 실패하는 사용자로 인해 발생하는 오류입니다.
  • "다른 자격 증명": "발급 권한 부여": 인증 실패로 인해 발생하는 오류입니다.
  • "발급 위임": 발급 위임 오류로 인해 발생하는 오류입니다.
  • "승인 토큰": 타사 ID 공급자로부터 토큰을 거부하는 ADFS로 인해 발생하는 오류입니다.
  • "Protocol": 프로토콜 오류로 인해 발생하는 오류입니다.
  • "알 수 없음": 모두 Catch합니다. 정의된 카테고리에 맞지 않는 다른 모든 오류입니다.
Server 서버를 기반으로 오류를 그룹화합니다. 이 그룹화는 서버 전반의 오류 분포를 파악하는 데 유용합니다. 분포가 균일하지 않으면 특정 서버에 문제가 있음을 나타낼 수 있습니다.
네트워크 위치 요청의 네트워크 위치(인트라넷 및 엑스트라넷)를 기반으로 오류를 그룹화합니다. 이 그룹화는 실패하는 요청의 유형을 파악하는 데 유용합니다.
애플리케이션 대상 애플리케이션(신뢰 당사자)을 기반으로 오류를 그룹화합니다. 이 그룹화는 가장 많은 수의 오류가 발생하는 대상 애플리케이션을 파악하는 데 유용합니다.

메트릭: 사용자 수 - 적극적으로 AD FS를 사용하여 인증하는 평균 고유 사용자 수

그룹화 기준 그룹화의 의미 및 그룹화가 유용한 이유
모두 이 메트릭은 선택한 시간 조각에서 페더레이션 서비스를 사용하는 평균 사용자 수를 제공합니다. 사용자가 그룹화되지 않습니다.
평균은 선택한 시간 조각에 따라 달라집니다.
애플리케이션 대상 애플리케이션(신뢰 당사자)을 기반으로 평균 사용자 수를 그룹화합니다. 이 그룹화는 특정 애플리케이션을 사용하는 사용자의 수를 파악하는 데 유용합니다.

AD FS의 모니터링 성능

Microsoft Entra Connect Health 성능 모니터링은 메트릭에 대한 모니터링 정보를 제공합니다. 모니터링 상자를 선택하면 메트릭에 대한 자세한 정보가 포함된 새 블레이드가 열립니다.

Microsoft Entra Connect Health 성능

블레이드 맨 위의 옵션을 선택하여 서버별로 필터링하면 개별 서버의 메트릭을 확인할 수 있습니다. 메트릭을 변경하려면 모니터링 블레이드에서 모니터링 차트를 마우스 오른쪽 단추로 클릭하고 차트 편집을 선택합니다(또는 차트 편집 단추를 선택). 그런 다음 열리는 새 블레이드의 드롭다운에서 추가 메트릭을 선택하여 성능 데이터를 볼 시간 범위를 지정할 수 있습니다.

사용자 이름/암호 로그인이 실패한 상위 사용자 50명

AD FS 서버에서 인증 요청이 실패하는 일반적인 이유 중 하나는 잘못된 자격 증명, 다시 말해서 사용자 이름 또는 암호가 올바르지 않은 것입니다. 일반적으로 복잡한 암호, 잊어버린 암호 또는 오타로 인해 사용자에게 발생합니다.

하지만, 애플리케이션이 사용자 자격 증명을 캐시했는데 자격 증명이 만료되었거나 일련의 잘 알려진 암호를 사용하여 계정에 로그인을 시도하는 악의적인 사용자와 같은 다른 이유로 인해 AD FS 서버에서 처리되는 예상치 못한 요청 수가 발생할 수 있습니다. 이러한 두 가지 예는 요청의 급증을 유발할 수 있는 유효한 원인입니다.

ADFS용 Microsoft Entra Connect Health는 잘못된 사용자 이름 또는 암호로 인해 로그인 시도에 실패한 상위 50명의 사용자에 대한 보고서를 제공합니다. 이 보고서는 팜의 모든 AD FS 서버에서 생성된 감사 이벤트를 처리하여 얻을 수 있습니다.

지난 30일 동안의 잘못된 암호 시도 횟수가 표시된 “보고서” 섹션 스크린샷

이 보고서 내에서 다음 정보에 간편하게 액세스할 수 있습니다.

  • 지난 30일 동안 잘못된 사용자 이름/암호를 사용하여 실패한 요청 수
  • 잘못된 사용자 이름/암호로 로그인하여 실패한 일별 평균 사용자 수

이 부분을 클릭하면 추가 세부 정보를 제공하는 주 보고서 블레이드로 이동합니다. 이 블레이드는 잘못된 사용자 이름이나 암호를 사용하는 요청에 대한 기준을 설정하는 데 도움이 되는 추세 정보가 있는 그래프를 포함합니다. 또한 지난 한 주 동안 실패한 시도 횟수가 포함된 상위 50명의 사용자 목록을 제공합니다. 지난 주 상위 50명의 사용자가 잘못된 암호 스파이크를 식별하는 데 도움이 될 수 있습니다.

이 그래프는 다음 정보를 제공합니다.

  • 잘못된 사용자 이름/암호로 인해 실패한 일별 총 로그인 수
  • 로그인에 실패한 일별 총 고유 사용자 수
  • 마지막 요청에 대한 클라이언트 IP 주소

Microsoft Entra Connect Health 포털

보고서는 다음과 같은 정보를 제공합니다.

보고서 항목 설명
사용자 ID 사용된 사용자 ID를 표시합니다. 이것은 사용자가 입력한 값이며, 잘못된 사용자 ID가 사용되는 경우도 있습니다.
실패한 시도 특정 사용자 ID에 대한 총 실패 횟수를 보여 줍니다. 테이블은 가장 높은 실패 횟수부터 내림차순으로 정렬됩니다.
마지막 실패 마지막 실패가 발생한 타임 스탬프를 보여 줍니다.
마지막 실패 IP 최신 잘못된 요청에서 클라이언트 IP 주소를 표시합니다. 이 값에 둘 이상의 IP 주소가 표시되면 사용자의 마지막 시도 요청 IP와 함께 포워드 클라이언트 IP가 포함될 수 있습니다.

참고 항목

이 보고서는 12시간마다 자동으로 업데이트되어 해당 시간 내에 수집된 새 정보가 포함됩니다. 따라서 마지막 12시간 내에 발생하는 로그인 시도가 보고서에 포함되지 않을 수 있습니다.