AD FS(Active Directory Federation Services)와 관련된 SSO 문제 해결

이 문서에서는 AD FS(Active Directory Federation Services)와 관련된 SSO(Single Sign-On) 문제를 해결하는 데 도움이 됩니다.

발생한 문제 유형에 따라 다음 섹션 중 하나를 선택합니다.

적용 대상:   Active Directory Federation Services 원래 KB 번호:   4034932

NTLM 또는 양식 기반 인증 프롬프트

AD FS(Active Directory Federation Services)와 관련된 SSO(Single Sign-On) 문제를 해결하는 동안 사용자가 예기치 않은 NTLM 또는 양식 기반 인증 프롬프트를 받은 경우 이 문서의 단계에 따라 이 문제를 해결합니다.

Windows 통합 인증 설정 확인

이 문제를 해결하려면 클라이언트 브라우저에서 Windows 통합 인증 설정, AD FS 설정 및 인증 요청 매개 변수를 확인합니다.

사용자의 클라이언트 브라우저 확인

인터넷 옵션에서 다음 설정을 확인합니다.

  • 고급 탭에서 Windows 통합 인증 사용 설정이 사용하도록 설정되어 있는지 확인합니다.
  • 보안 > 로컬 인트라넷 > 사이트 > 고급 에 따라 AD FS URL이 웹 사이트 목록에 있는지 확인합니다.
  • 보안 > 로컬 인트라넷 > 사용자 지정 수준에 따라 인트라넷 영역 설정에서만 자동 로그온 이 선택되어 있는지 확인합니다.

Firefox, Chrome 또는 Safari를 사용하는 경우 이러한 브라우저에서 동일한 설정을 사용하도록 설정해야 합니다.

AD FS 설정 확인

WindowsIntegratedFallback 설정 확인
  1. 관리자 권한으로 실행 옵션을 사용하여 Windows PowerShell 엽니다.

  2. 다음 명령을 실행하여 전역 인증 정책을 가져옵니다.

    Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled
    
  3. WindowsIntegratedFallbackEnabled 특성의 값을 검사합니다.

값이 True 이면 양식 기반 인증이 필요합니다. 즉, 인증 요청은 Windows 통합 인증을 지원하지 않는 브라우저에서 제공됩니다. 브라우저를 지원하는 방법에 대한 다음 섹션을 참조하세요.

값이 False 이면 Windows 통합 인증이 필요합니다.

WIASupportedUsersAgents 설정 확인
  1. 다음 명령을 실행하여 지원되는 사용자 에이전트 목록을 가져옵니다.

    Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  2. 명령이 반환하는 사용자 에이전트 문자열 목록을 검사합니다.

브라우저의 사용자 에이전트 문자열이 목록에 있는지 확인합니다. 그렇지 않은 경우 아래 단계에 따라 사용자 에이전트 문자열을 추가합니다.

  1. 브라우저의 http://useragentstring.com/ 사용자 에이전트 문자열을 검색하고 표시하도록 이동합니다.

  2. 다음 명령을 실행하여 지원되는 사용자 에이전트 목록을 가져옵니다.

    $wiaStrings = Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents
    
  3. 다음 명령을 실행하여 브라우저의 사용자 에이전트 문자열을 추가합니다.

    $wiaStrings = $wiaStrings+"NewUAString"
    

    예:

    $wiaStrings = $wiaStrings+" =~Windows\s*NT.*Edge"+"Mozilla/5.0"
    
  4. 다음 명령을 실행하여 WIASupportedUserAgents 설정을 업데이트합니다.

    Set-ADFSProperties -WIASupportedUserAgents $wiaStrings
    

인증 요청 매개 변수 확인

인증 요청이 인증 방법으로 양식 기반 인증을 지정하는지 확인합니다.
  1. 인증 요청이 WS-Federation 요청인 경우 요청에 wauth= urn:oasis:names:tc:SAML:1.0:am:password 가 포함되어 있는지 확인합니다.
  2. 인증 요청이 SAML 요청인 경우 요청에 urn:oasis:names:tc:SAML:2.0:ac:classes:Password 값이 있는 samlp:AuthnContextClassRef 요소가 포함되어 있는지 확인합니다.

자세한 내용은 AD FS 로그인 페이지의 인증 처리기 개요를 참조하세요.

애플리케이션이 Office 365 Microsoft Online Services인지 확인합니다.

액세스하려는 애플리케이션이 Microsoft Online Services가 아닌 경우 들어오는 인증 요청에 의해 예상 및 제어됩니다. 애플리케이션 소유자와 협력하여 동작을 변경합니다.

애플리케이션이 Microsoft Online Services인 경우 사용자 환경은 신뢰할 수 있는 영역 개체의 PromptLoginBehavior 설정에 의해 제어될 수 있습니다. 이 설정은 Azure AD 테넌트가 prompt=login을 AD FS에 보낼지 여부를 제어합니다. PromptLoginBehavior 설정을 설정하려면 다음 단계를 수행합니다.

  1. "관리자 권한으로 실행" 옵션을 사용하여 Windows PowerShell 엽니다.

  2. 다음 명령을 실행하여 기존 도메인 페더레이션 설정을 가져옵니다.

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  3. 다음 명령을 실행하여 PromptLoginBehavior 설정을 지정합니다.

    Set-MSOLDomainFederationSettings -DomainName DomainName -PromptLoginBehavior <TranslateToFreshPasswordAuth|NativeSupport|Disabled> -SupportsMFA <$TRUE|$FALSE> -PreferredAuthenticationProtocol <WsFed|SAMLP>
    

    PromptLoginBehavior 매개 변수의 값은 다음과 같습니다.

    1. TranslateToFreshPasswordAuth: Azure AD prompt=login 대신 wauth 및 wfresh를 AD FS로 보냅니다. 이렇게 하면 양식 기반 인증을 사용하는 인증 요청이 발생합니다.
    2. NativeSupport: prompt=login 매개 변수는 AD FS에 있는 그대로 전송됩니다.
    3. 사용 안 함: AD FS에 아무 것도 전송되지 않습니다.

Set-MSOLDomainFederationSettings 명령에 대한 자세한 내용은 Active Directory Federation Services prompt=login 매개 변수 지원을 참조하세요.

Azure Active Directory(Azure AD) 시나리오

Azure AD 전송된 인증 요청에 prompt=login 매개 변수가 포함된 경우 다음 명령을 실행하여 prompt=login 기능을 사용하지 않도록 설정합니다.

Set-MsolDomainFederationSettings –DomainName DomainName -PromptLoginBehavior Disabled

이 명령을 실행한 후 Office 365 애플리케이션은 각 인증 요청에 prompt=login 매개 변수를 포함하지 않습니다.

비 Azure AD 시나리오

인증 요청 의 WAUTHRequestedAuthNContext 와 같은 요청 매개 변수에는 인증 방법이 지정되어 있을 수 있습니다. 예기치 않은 인증 프롬프트를 적용하는 다른 요청 매개 변수인지 확인합니다. 이 경우 필요한 인증 방법을 사용하도록 요청 매개 변수를 수정합니다.

SSO를 사용할 수 없는지 확인

SSO를 사용하지 않도록 설정한 경우 SSO를 사용하도록 설정하고 문제가 해결되었는지 테스트합니다.

다단계 인증 프롬프트

이 문제를 해결하려면 신뢰 당사자의 클레임 규칙이 다단계 인증에 대해 올바르게 설정되어 있는지 확인합니다.

다단계 인증은 AD FS 서버, 신뢰 당사자 또는 인증 요청 매개 변수에 지정할 수 있습니다. 구성이 올바르게 설정되었는지 확인합니다. 다단계 인증이 필요하지만 이를 요구하는 메시지가 반복적으로 표시되는 경우 신뢰 당사자 발급 규칙을 확인하여 다단계 인증 클레임이 애플리케이션에 전달되는지 확인합니다.

AD FS의 다단계 인증에 대한 자세한 내용은 다음 문서를 참조하세요.

AD FS 서버 및 신뢰 당사자의 구성 확인

AD FS 서버에서 구성을 확인하려면 전역 추가 인증 규칙의 유효성을 검사합니다. 신뢰 당사자에 대한 구성을 확인하려면 신뢰 당사자 트러스트에 대한 추가 인증 규칙의 유효성을 검사합니다.

  1. AD FS 서버에서 구성을 확인하려면 Windows PowerShell 창에서 다음 명령을 실행합니다.

    Get-ADFSAdditionalAuthenticationRule
    

    신뢰 당사자에 대한 구성을 확인하려면 다음 명령을 실행합니다.

    Get-ADFSRelyingPartyTrust -TargetName RelyingParty | Select -ExpandProperty AdditionalAuthenticationRules
    

    참고

    명령이 아무 것도 반환하지 않으면 추가 인증 규칙이 구성되지 않습니다. 이 섹션을 건너뜁니다.

  2. 구성된 클레임 규칙 집합을 관찰합니다.

클레임 규칙 집합에서 다단계 인증을 사용할 수 있는지 확인

클레임 규칙 집합은 다음 섹션으로 구성됩니다.

  • 조건문: C:[Type=``…,Value=…]
  • 문제 문: => issue (Type=``…,Value=…)

문제 문에 다음 클레임이 포함된 경우 다단계 인증이 지정됩니다.
Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"

다음은 업무 외 조인 디바이스 및 엑스트라넷 액세스에 각각 다단계 인증을 사용해야 하는 예제입니다.

  • c:[Type == "http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")
  • c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn")

신뢰 당사자 발급 규칙 확인

사용자가 첫 번째 인증을 수행한 후 다단계 인증 프롬프트를 반복적으로 수신하는 경우 회신 당사자가 다단계 인증 클레임을 애플리케이션에 전달하지 않을 수 있습니다. 인증 클레임이 통과되었는지 확인하려면 다음 단계를 수행합니다.

  1. Windows PowerShell에서 다음 명령을 실행합니다.

    Get-ADFSRelyingPartyTrust -TargetName ClaimApp
    
  2. IssuanceAuthorizationRules 또는 IssuanceAuthorizationRulesFile 특성에 정의된 규칙 집합을 관찰합니다.

규칙 집합에는 다단계 인증 클레임을 통과하는 다음 발급 규칙이 포함되어야 합니다.
C:[Type==http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod, Value==” http://schemas.microsoft.com/claims/multipleauthn”]=>issue(claim = c)

인증 요청 매개 변수 확인

인증 요청이 다단계 인증을 인증 방법으로 지정하는지 확인합니다.

  • 인증 요청이 WS-Federation 요청인 경우 요청에 포함되는지 확인합니다 wauth= http://schemas.microsoft.com/claims/multipleauthn.
  • 인증 요청이 SAML 요청인 경우 요청에 값http://schemas.microsoft.com/claims/multipleauthn이 있는 samlp:AuthnContextClassRef 요소가 포함되어 있는지 확인합니다.

자세한 내용은 AD FS 로그인 페이지의 인증 처리기 개요를 참조하세요.

애플리케이션이 Office 365 Microsoft Online Services인지 확인합니다.

액세스하려는 애플리케이션이 Office 365 Microsoft Online Services인 경우 SupportsMFA 도메인 페더레이션 설정을 확인합니다.

  1. 다음 명령을 실행하여 현재 SupportsMFA 도메인 페더레이션 설정을 가져옵니다.

    Get-MSOLDomainFederationSettings -DomainName DomainName | FL *
    
  2. SupportsMFA 설정이 FALSE이면 다음 명령을 실행하여 TRUE로 설정합니다.

    Set-MSOLDomainFederationSettings -DomainName DomainName -SupportsMFA $TRUE
    

SSO를 사용할 수 없는지 확인

SSO를 사용하지 않도록 설정한 경우 SSO를 사용하도록 설정하고 문제가 해결되었는지 테스트합니다.

사용자는 대상 사이트 또는 서비스에 로그인할 수 없습니다.

이 문제는 AD FS 로그인 페이지 또는 애플리케이션 쪽에서 발생할 수 있습니다.

AD FS 로그인 페이지에서 문제가 발생하면 "오류가 발생했습니다", "HTTP 503 서비스를 사용할 수 없음" 또는 기타 오류 메시지가 표시됩니다. 오류 페이지의 URL에는 AD FS 서비스 이름(예: .) fs.contoso.com이 표시됩니다.

애플리케이션 쪽에서 문제가 발생하면 오류 페이지의 URL에 대상 서비스의 IP 주소 또는 사이트 이름이 표시됩니다.

이 문제가 발생하는 위치에 따라 다음 섹션의 단계를 수행합니다.

이 문제는 AD FS 로그인 페이지에서 발생합니다.

이 문제를 해결하려면 모든 사용자가 문제의 영향을 받는지, 사용자가 모든 신뢰 당사자에 액세스할 수 있는지 확인합니다.

모든 사용자는 문제의 영향을 받으며 사용자는 신뢰 당사자에 액세스할 수 없습니다.

IdpInitiatedSignOn을 사용하여 내부 로그인 기능을 확인해 보겠습니다. 이렇게 하려면 IdpInititatedSignOn 페이지를 사용하여 AD FS 서비스가 실행 중이고 인증 기능이 올바르게 작동하는지 확인합니다. IdpInitiatedSignOn 페이지를 열려면 다음 단계를 수행합니다.

  1. AD FS 서버에서 다음 명령을 실행하여 IdpInitiatedSignOn 페이지를 사용하도록 설정합니다.

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. 네트워크 내에 있는 컴퓨터에서 다음 페이지를 방문합니다.
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. 로그인 페이지에서 유효한 사용자의 올바른 자격 증명을 입력합니다.

로그인에 성공했습니다.

로그인에 성공하면 AD FS 서비스 상태가 실행 중인지 확인합니다.

  1. AD FS 서버에서 서버 관리자 엽니다.
  2. 서버 관리자 도구 > 서비스를 클릭합니다.
  3. Active Directory Federation Services 상태가 실행 중 인지 확인합니다.

그런 다음, IdpInitiatedSignOn을 사용하여 외부 로그인 기능을 확인합니다. IdpInititatedSignOn 페이지를 사용하여 AD FS 서비스가 실행 중이고 인증 기능이 올바르게 작동하는지 빠르게 확인합니다. IdpInitiatedSignOn 페이지를 열려면 다음 단계를 수행합니다.

  1. AD FS 서버에서 다음 명령을 실행하여 IdpInitiatedSignOn 페이지를 사용하도록 설정합니다.

    Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
    
  2. 네트워크 외부에 있는 컴퓨터에서 다음 페이지를 방문합니다.
    https://<FederationInstance>/adfs/ls/idpinitiatedsignon.aspx

  3. 로그인 페이지에서 유효한 사용자의 올바른 자격 증명을 입력합니다.

로그인에 실패한 경우 AD FS 관련 구성 요소 및 서비스 확인 및 프록시 신뢰 관계 확인을 참조하세요.

로그인에 성공하면 모든 사용자가 문제의 영향을 받는 단계를 사용하여 문제 해결을 계속 하면 사용자가 일부 신뢰 당사자에 액세스할 수 있습니다.

로그인에 실패했습니다.

로그인에 실패한 경우 AD FS 관련 구성 요소 및 서비스를 확인합니다.

AD FS 서비스 상태가 실행 중인지 확인합니다.

  1. AD FS 서버에서 서버 관리자 엽니다.
  2. 서버 관리자 도구 > 서비스를 클릭합니다.
  3. Active Directory Federation Services 상태가 실행 중 인지 확인합니다.

엔드포인트를 사용할 수 있는지 확인합니다. AD FS는 다양한 기능 및 시나리오에 대한 다양한 엔드포인트를 제공합니다. 모든 엔드포인트가 기본적으로 사용하도록 설정되는 것은 아닙니다. 엔드포인트의 상태를 확인하려면 다음 단계를 수행합니다.

  1. AD FS 서버에서 AD FS 관리 콘솔을 엽니다.

  2. 서비스 > 엔드포인트를 확장합니다.

  3. 엔드포인트를 찾고 사용 열에서 상태를 사용할 수 있는지 확인합니다.

    모든 AD F S 엔드포인트가 사용하도록 설정된 상태를 다시 확인합니다.

그런 다음 Azure AD Connect가 설치되어 있는지 확인합니다. SSL 인증서 관리를 더 쉽게 만드는 Azure AD Connect를 사용하는 것이 좋습니다.

Azure AD Connect가 설치된 경우 SSL 인증서를 관리하고 업데이트하는 데 사용해야 합니다.

Azure AD Connect가 설치되지 않은 경우 SSL 인증서가 다음 AD FS 요구 사항을 충족하는지 확인합니다.

  • 인증서는 신뢰할 수 있는 루트 인증 기관에서 온 것입니다.

    AD FS를 사용하려면 SSL 인증서가 신뢰할 수 있는 루트 인증 기관에서 온 것입니다. 도메인에 가입되지 않은 컴퓨터에서 AD FS에 액세스하는 경우 DigiCert, VeriSign 등과 같은 신뢰할 수 있는 타사 루트 인증 기관의 SSL 인증서를 사용하는 것이 좋습니다. SSL 인증서가 신뢰할 수 있는 루트 인증 기관에서 온 것이 아니면 SSL 통신이 중단될 수 있습니다.

  • 인증서의 주체 이름이 유효합니다.

    주체 이름은 AD FS 서버 이름이나 다른 이름이 아닌 페더레이션 서비스 이름과 일치해야 합니다. 페더레이션 서비스 이름을 얻으려면 기본 AD FS 서버에서 다음 명령을 실행합니다.
    Get-AdfsProperties | select hostname

  • 인증서가 해지되지 않았습니다.

    인증서 해지를 확인합니다. 인증서가 해지되면 SSL 연결을 신뢰할 수 없으며 클라이언트에 의해 차단됩니다.

SSL 인증서가 이러한 요구 사항을 충족하지 않는 경우 SSL 통신에 대한 정규화된 인증서를 가져옵니다. SSL 인증서 관리를 더 쉽게 만드는 Azure AD Connect를 사용하는 것이 좋습니다. AD FS(Active Directory Federation Services) 팜에 대한 TLS/SSL 인증서 업데이트를 참조하세요.

SSL 인증서가 이러한 요구 사항을 충족하는 경우 SSL 인증서의 다음 구성을 확인합니다.

SSL 인증서가 제대로 설치되었는지 확인

팜의 각 페더레이션 서버에서 로컬 컴퓨터의 개인 저장소에 SSL 인증서를 설치해야 합니다. 인증서를 설치하려면 .를 두 번 클릭합니다. 인증서의 PFX 파일 및 마법사를 따릅니다.

인증서가 올바른 위치에 설치되어 있는지 확인하려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행하여 로컬 컴퓨터의 개인 저장소에 있는 인증서를 나열합니다.
    dir Cert:\LocalMachine\My
  2. 인증서가 목록에 있는지 확인합니다.
올바른 SSL 인증서가 사용 중인지 확인

SSL 통신에 사용 중인 인증서의 지문을 가져오고 지문이 예상된 인증서 지문과 일치하는지 확인합니다.

사용 중인 인증서의 지문을 가져오려면 Windows PowerShell 다음 명령을 실행합니다.

Get-AdfsSslCertificate

잘못된 인증서를 사용하는 경우 다음 명령을 실행하여 올바른 인증서를 설정합니다.

Set-AdfsSslCertificate –Thumbprint CorrectThumprint
SSL 인증서가 서비스 통신 인증서로 설정되어 있는지 확인합니다.

SSL 인증서는 AD FS 팜에서 서비스 통신 인증서로 설정해야 합니다. 이 작업은 자동으로 발생하지 않습니다. 올바른 인증서가 설정되어 있는지 확인하려면 다음 단계를 수행합니다.

  1. AD FS 관리 콘솔에서 서비스 > 인증서를 확장합니다.
  2. 서비스 통신 아래에 나열된 인증서가 필요한 인증서인지 확인합니다.

잘못된 인증서가 나열된 경우 올바른 인증서를 설정한 다음 AD FS 서비스에 인증서에 대한 읽기 권한을 부여합니다. 이렇게 하려면 다음과 같이 하십시오.

  1. 올바른 인증서를 설정합니다.

    1. 인증서를 마우스 오른쪽 단추로 클릭한 다음 서비스 통신 인증서 설정을 클릭합니다.
    2. 올바른 인증서를 선택합니다.
  2. AD FS 서비스에 인증서에 대한 읽기 권한이 있는지 확인합니다.

    1. 로컬 컴퓨터 계정에 대한 인증서 스냅인을 MMC(Microsoft Management Console)에 추가합니다.
    2. 인증서(로컬 컴퓨터) > 개인 > 인증서 를 확장합니다.
    3. SSL 인증서를 마우스 오른쪽 단추로 클릭하고 모든 작업 > 관리 프라이빗 키를 클릭합니다.
    4. adfssrv읽기 권한이 있는 그룹 및 사용자 이름 아래에 나열되어 있는지 확인합니다.
  3. adfssrv가 나열되지 않은 경우 AD FS 서비스에 인증서에 대한 읽기 권한을 부여합니다.

    1. 추가, 위치, 서버를 차례로 클릭한 다음 [확인]을 클릭합니다.
    2. 선택할 개체 이름 입력 에서 nt service\adfssrv 를 입력하고 이름 확인을 클릭한 다음 확인을 클릭합니다.
      DRS(디바이스 등록 서비스)에서 AD FS를 사용하는 경우 대신 nt service\drs를 입력합니다 .
    3. 읽기 권한을 부여한 다음 확인을 클릭합니다.
DRS(디바이스 등록 서비스)가 AD FS에 구성되어 있는지 확인합니다.

DRS를 사용하여 AD FS를 구성한 경우 SSL 인증서도 RDS에 대해 올바르게 구성되었는지 확인합니다. 예를 들어 두 개의 UPN 접미사가 contoso.com 있고 인증서에 SAN(주체 대체 이름)이 있어야 합니다 enterpriseregistration.contoso.com enterpriseregistration.fabrikma.com.fabrikam.com

SSL 인증서에 올바른 SAN이 있는지 확인하려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행하여 조직에서 사용되는 모든 UPN 접미사를 나열합니다.

    Get-AdfsDeviceRegistratrionUpnSuffix
    
  2. SSL 인증서에 필요한 SAN이 구성되어 있는지 확인합니다.

  3. SSL 인증서에 올바른 DRS 이름이 SAN으로 없는 경우 DRS에 대한 올바른 SAN이 있는 새 SSL 인증서를 가져와서 AD FS에 대한 SSL 인증서로 사용합니다.

그런 다음 WAP 서버 및 대체 바인딩에서 인증서 구성을 확인합니다.

  • 모든 WAP 서버에서 올바른 SSL 인증서가 설정되어 있는지 확인합니다.

    1. 각 WAP 서버의 로컬 컴퓨터에 대한 개인 저장소에 SSL 인증서가 설치되어 있는지 확인합니다.

    2. 다음 명령을 실행하여 WAP에서 사용하는 SSL 인증서를 가져옵니다.

      Get-WebApplicationProxySslCertificate
      
    3. SSL 인증서가 잘못된 경우 다음 명령을 실행하여 올바른 SSL 인증서를 설정합니다.

      Set-WebApplicationProxySslCertificate -Thumbprint Thumbprint
      
  • 인증서 바인딩을 확인하고 필요한 경우 업데이트합니다.

    비 SNI 사례를 지원하기 위해 관리자는 대체 바인딩을 지정할 수 있습니다. 표준 federationservicename:443 바인딩 이외의 다음 애플리케이션 ID에서 대체 바인딩을 찾습니다.

    • {5d89a20c-beab-4389-9447-324788eb944a}: AD FS의 애플리케이션 ID입니다.
    • {f955c070-e044-456c-ac00-e9e4275b3f04}: 웹 애플리케이션 프록시 대한 애플리케이션 ID입니다.

    예를 들어 0.0.0.0.0:443과 같은 대체 바인딩에 대해 SSL 인증서가 지정된 경우 SSL 인증서가 업데이트될 때 바인딩이 적절하게 업데이트되는지 확인합니다.

모든 사용자는 문제의 영향을 받으며 사용자는 일부 신뢰 당사자에 액세스할 수 있습니다.

먼저 신뢰 당사자 및 OAuth 클라이언트 정보를 살펴보겠습니다. 기존 신뢰 당사자를 사용하는 경우 다음 단계를 수행합니다.

  1. 기본 AD FS 서버에서 관리자 권한으로 실행 옵션을 사용하여 Windows PowerShell 엽니다.

  2. 다음 명령을 실행하여 Windows PowerShell AD FS 2.0 구성 요소를 추가합니다.

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. 다음 명령을 실행하여 신뢰 당사자 정보를 가져옵니다.

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. 다음 명령을 실행하여 OAuth 클라이언트 정보를 가져옵니다.

    $client = Get-AdfsClient ClientName
    

Windows Server 2016 애플리케이션 그룹 기능을 사용하는 경우 아래 단계를 수행합니다.

  1. 기본 AD FS 서버에서 관리자 권한으로 실행 옵션을 사용하여 Windows PowerShell 엽니다.

  2. 다음 명령을 실행하여 신뢰 당사자 정보를 가져옵니다.
    $rp = Get-AdfsWebApiApplication ResourceID

  3. OAuth 클라이언트가 공용인 경우 다음 명령을 실행하여 클라이언트 정보를 가져옵니다.

    $client = Get-AdfsNativeClientApplication ClientName
    

    클라이언트가 기밀인 경우 다음 명령을 실행하여 클라이언트 정보를 가져옵니다.

    $client = Get-AdfsServerApplication ClientName
    

이제 다음 문제 해결 방법을 계속 진행합니다.

신뢰 당사자 및 클라이언트의 설정 확인

신뢰 당사자 식별자, 클라이언트 ID 및 리디렉션 URI는 애플리케이션 소유자와 클라이언트에서 제공해야 합니다. 그러나 소유자가 제공하는 내용과 AD FS에서 구성된 항목이 여전히 일치하지 않을 수 있습니다. 예를 들어 오타로 인해 불일치가 발생할 수 있습니다. 소유자가 제공한 설정이 AD FS에 구성된 설정과 일치하는지 확인합니다. 이전 페이지의 단계에서는 PowerShell을 통해 AD FS에 구성된 설정을 가져옵니다.

소유자가 제공한 설정 AD FS에 구성된 설정
신뢰 당사자 ID $rp. 식별자
신뢰 당사자 리디렉션 URI 접두사 또는 와일드카드 일치
  • $rp. WS-Fed 신뢰 당사자에 대한 WSFedEndpoint
  • $rp. SAML 신뢰 당사자를 위한 SamlEndpoints
클라이언트 ID $client. Clientid
클라이언트 리디렉션 URI $client 접두사 일치입니다. RedirectUri

테이블의 항목이 일치하는 경우 AD FS로 전송된 인증 요청에 표시되는 항목과 AD FS에 구성된 항목 간에 이러한 설정이 일치하는지 추가로 확인합니다. 애플리케이션에서 AD FS로 보낸 인증 요청에서 Fiddler 추적을 캡처하는 동안 발생하는 문제를 재현해 보세요. 요청 매개 변수를 검사하여 요청 유형에 따라 다음 검사를 수행합니다.

OAuth 요청

OAuth 요청은 다음과 같습니다.

https://sts.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=ClientID&redirect_uri=https://www.TestApp.com&resource=https://www.TestApp.com

요청 매개 변수가 AD FS에 구성된 설정과 일치하는지 확인합니다.

요청 매개 변수 AD FS에 구성된 설정
client_id $client. Clientid
redirect_uri 접두사 일치 @client_RedirectUri

"resource" 매개 변수는 AD FS에서 유효한 신뢰 당사자를 나타내야 합니다. 다음 명령 중 하나를 실행하여 신뢰 당사자 정보를 가져옵니다.

  • 기존 신뢰 당사자를 사용하는 경우 다음 명령을 실행합니다.
    Get-AdfsRelyingPartyTrust -Identifier "ValueOfTheResourceParameter"
  • Windows Server 2016 애플리케이션 그룹 기능을 사용하는 경우 다음 명령을 실행합니다.
    Get-AdfsWebApiApplication "ValueOfTheResourceParameter"
WS-Fed 요청

WS-Fed 요청은 다음과 같습니다.

https://fs.contoso.com/adfs/ls/?wa=wsignin1.0&wtrealm=https://claimsweb.contoso.com&wctx=rm=0&id=passive&ru=/&wct=2014-10-21T22:15:42Z

요청 매개 변수가 AD FS에 구성된 설정과 일치하는지 확인합니다.

요청 매개 변수 AD FS에 구성된 설정
wtrealm $rp. 식별자
Wreply $rp 접두사 일치 또는 와일드카드 일치입니다. WSFedEndpoint
SAML 요청

SAML 요청은 다음과 같습니다.

https://sts.contoso.com/adfs/ls/?SAMLRequest=EncodedValue&RelayState=cookie:29002348&SigAlg=http://www.w3.org/2000/09/Fxmldsig#rsa-sha1&Signature=Signature

Fiddler 텍스트 마법사에서 "DeflatedSAML에서" 옵션을 사용하여 SAMLRequest 매개 변수의 값을 디코딩합니다. 디코딩된 값은 다음과 같습니다.

<samlp:AuthnRequest ID="ID" Version="2.0" IssueInstant="2017-04-28T01:02:22.664Z" Destination="https://TestClaimProvider-Samlp-Only/adfs/ls" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" ForceAuthn="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://fs.contoso.com/adfs/services/trust</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>

디코딩된 값 내에서 다음 검사를 수행합니다.

  • 대상 값의 호스트 이름이 AD FS 호스트 이름과 일치하는지 확인합니다.
  • 발급자의 값이 일치하는 $rp.Identifier지 확인합니다.

SAML에 대한 추가 참고 사항:

  • $rp. SamlEndpoints: 모든 유형의 SAML 엔드포인트를 표시합니다. AD FS의 응답은 엔드포인트에 구성된 해당 URL로 전송됩니다. SAML 엔드포인트는 메시지 전송에 리디렉션, 게시 또는 아티팩트 바인딩을 사용할 수 있습니다. 이러한 모든 URL은 AD FS에서 구성할 수 있습니다.
  • $rp. SignedSamlRequestsRequired: 값이 설정되면 신뢰 당사자로부터 보낸 SAML 요청에 서명해야 합니다. 요청에 "SigAlg" 및 "Signature" 매개 변수가 있어야 합니다.
  • $rp. RequestSigningCertificate: SAML 요청에 서명을 생성하는 데 사용되는 서명 인증서입니다. 인증서가 유효한지 확인하고 애플리케이션 소유자에게 인증서와 일치하도록 요청합니다.
암호화 인증서 확인

Enabled를 반환하면 $rp.EncryptClaims 신뢰 당사자 암호화가 사용됩니다. AD FS는 암호화 인증서를 사용하여 클레임을 암호화합니다. 다음 검사를 수행합니다.

  • $rp. EncryptionCertificate: 이 명령을 사용하여 인증서를 가져와서 유효한지 확인합니다.
  • $rp. EncryptionCertificateRevocationCheck: 이 명령을 사용하여 인증서가 해지 검사 요구 사항을 충족하는지 확인합니다.
이전 두 메서드가 작동하지 않음

문제 해결을 계속하려면 덤프 토큰 앱 사용을 참조하세요.

모든 사용자가 문제의 영향을 받는 것은 아니며 사용자는 신뢰 당사자에 액세스할 수 없습니다.

이 시나리오에서는 다음 검사를 수행합니다.

사용자가 사용하지 않도록 설정되어 있는지 확인

Windows PowerShell 또는 UI에서 사용자 상태를 확인합니다. 사용자가 비활성화된 경우 사용자를 사용하도록 설정합니다.

Windows PowerShell 사용하여 사용자 상태 확인
  1. 도메인 컨트롤러에 로그인합니다.

  2. Windows PowerShell을 엽니다.

  3. 다음 명령을 실행하여 사용자 상태를 확인합니다.

    Get-ADUser -Identity <samaccountname of the user> | Select Enabled
    

    Get-ADUser 명령을 사용하여 사용자 사용 상태를 확인합니다.

UI에서 사용자 상태 확인
  1. 도메인 컨트롤러에 로그인합니다.

  2. Active Directory 사용자 및 컴퓨터 관리 콘솔을 엽니다.

  3. 사용자 노드를 클릭하고 오른쪽 창에서 사용자를 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

  4. 계정 탭을 클릭합니다.

  5. 계정 옵션 에서 계정을 사용할 수 없는지 확인합니다.

    계정 사용 안 함 옵션이 선택되어 있는지 다시 확인합니다.

  6. 옵션을 선택한 경우 선택 취소합니다.

사용자 속성이 최근에 업데이트되었는지 확인

Active Directory에서 사용자의 속성이 업데이트되면 사용자 개체의 메타데이터가 변경됩니다. 사용자 메타데이터 개체를 확인하여 최근에 업데이트된 속성을 확인합니다. 변경 내용이 발견되면 관련 서비스에서 해당 변경 내용을 선택해야 합니다. 사용자에게 속성이 변경되었는지 확인하려면 다음 단계를 수행합니다.

  1. 도메인 컨트롤러에 로그인합니다.

  2. Windows PowerShell을 엽니다.

  3. 다음 명령을 실행하여 사용자 개체의 메타데이터를 가져옵니다.
    repadmin /showobjmeta <destination DC> "user DN"

    명령의 예는 다음과 같습니다.
    repadmin /showobjmeta localhost "CN=test user,CN=Users,DC=fabidentity,DC=com"

  4. 메타데이터에서 각 특성의 시간/날짜 열을 검사하여 변경에 대한 단서를 확인합니다. 다음 예제에서 userPrincipleName 특성은 사용자 개체 메타데이터의 변경 사항을 나타내는 다른 특성보다 최신 날짜를 사용합니다.

    repadmin showobjmeta 명령의 출력입니다.

사용자가 다른 포리스트에 속해 있는지 포리스트 트러스트 확인

다중 포리스트 AD FS 환경에서는 AD FS가 배포된 포리스트와 인증을 위해 AD FS 배포를 활용하는 다른 포리스트 간에 양방향 포리스트 트러스트가 필요합니다. 포리스트 간의 신뢰가 예상대로 작동하는지 확인하려면 다음 단계를 수행합니다.

  1. AD FS가 배포된 포리스트의 도메인 컨트롤러에 로그인합니다.

  2. Active Directory 도메인 및 트러스트 관리 콘솔을 엽니다.

  3. 관리 콘솔에서 확인하려는 트러스트가 포함된 도메인을 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

  4. 트러스트 탭 클릭합니다.

  5. 이 도메인(나가는 트러스트) 또는 이 도메인을 신뢰****하는 도메인(들어오는 트러스트) 에서 확인할 트러스트를 클릭한 다음 속성을 클릭합니다.

  6. 유효성 검사를 클릭합니다.
    Active Directory Domain Services 대화 상자에서 옵션 중 하나를 선택합니다.

    • 아니요 를 선택하는 경우 상호 도메인에 대해 동일한 절차를 반복하는 것이 좋습니다.

    • 예를 선택하면 상호 도메인에 대한 관리 사용자 자격 증명을 제공합니다. 상호 도메인에 대해 동일한 절차를 수행할 필요가 없습니다.

      Active Directory Domain Services 대화 상자에서 들어오는 트러스트의 유효성을 검사합니다.

이러한 단계가 문제를 해결하는 데 도움이 되지 않는 경우 모든 사용자가 문제의 영향을 받지 않으며 사용자가 일부 신뢰 당사자 섹션에 액세스할 수 있는 단계와 함께 문제 해결을 계속합니다 .

모든 사용자가 문제의 영향을 받는 것은 아니며 사용자는 일부 신뢰 당사자에 액세스할 수 있습니다.

이 시나리오에서는 이 문제가 Azure AD 시나리오에서 발생하는지 확인합니다. 이 경우 이러한 검사를 수행하여 이 문제를 해결합니다. 그렇지 않은 경우 덤프 토큰 앱 사용을 참조하여 이 문제를 해결합니다.

사용자가 Azure AD 동기화되었는지 확인합니다.

사용자가 Azure AD 로그인하려는 경우 페더레이션된 도메인에 대한 인증을 위해 AD FS로 리디렉션됩니다. 로그인에 실패한 이유 중 하나는 사용자가 아직 Azure AD 동기화되지 않았기 때문입니다. AD FS에서 첫 번째 인증을 시도한 후 Azure AD AD FS로의 루프가 표시될 수 있습니다. 사용자가 Azure AD 동기화되는지 여부를 확인하려면 다음 단계를 수행합니다.

  1. Windows PowerShell Azure AD PowerShell 모듈을 다운로드하여 설치합니다.
  2. "관리자 권한으로 실행" 옵션을 사용하여 Windows PowerShell 엽니다.
  3. 다음 명령을 실행하여 Azure AD 대한 연결을 시작합니다.
    Connect-MsolService
  4. 연결에 대한 전역 관리자 자격 증명을 제공합니다.
  5. 다음 명령을 실행하여 Azure AD 사용자 목록을 가져옵니다.
    Get-MsolUser
  6. 사용자가 목록에 있는지 확인합니다.

사용자가 목록에 없는 경우 사용자를 Azure AD 동기화합니다.

발급 클레임 규칙에서 immutableID 및 UPN 확인

Azure AD 사용자를 인증하려면 immutableID 및 사용자의 UPN이 필요합니다.

참고

immutableID는 다음 도구에서 sourceAnchor라고도 합니다.

  • Azure AD Sync
  • Azure Active Directory 동기화(DirSync)

관리자는 Azure AD Connect를 사용하여 Azure AD AD FS 트러스트를 자동으로 관리할 수 있습니다. Azure AD Connect를 통해 트러스트를 관리하지 않는 경우 Azure AD Connect Azure AD Connect를 다운로드하여 동기화 설정에 따라 자동 클레임 규칙 관리를 사용하도록 설정하는 것이 좋습니다.

AD FS의 immutableID 및 UPN에 대한 클레임 규칙이 Azure AD 사용하는 것과 일치하는지 확인하려면 다음 단계를 수행합니다.

  1. Azure AD Connect에서 sourceAnchor 및 UPN을 가져옵니다.

    1. Azure AD Connect를 엽니다.

    2. 현재 구성 보기를 클릭합니다.

      Azure AD Connect 추가 작업 페이지에서 현재 구성 보기를 선택합니다.

    3. 솔루션 검토 페이지에서 SOURCE ANCHOR사용자 계정 이름의 값을 기록해 둡다.

      Azure AD Connect 페이지에서 SOURCE ANCHOR 및 사용자 계정 이름의 값을 가져옵니다.

  2. AD FS 서버에 구성된 해당 클레임 규칙에서 immutableID(sourceAnchor) 및 UPN 값을 확인합니다.

    1. AD FS 서버에서 AD FS 관리 콘솔을 엽니다.

    2. 신뢰 당사자 트러스트를 클릭합니다.

    3. Azure AD 신뢰 당사자 트러스트를 마우스 오른쪽 단추로 클릭한 다음 클레임 발급 정책 편집 을 클릭합니다.

    4. 변경할 수 없는 ID 및 UPN에 대한 클레임 규칙을 엽니다.

    5. immutableID 및 UPN 값을 쿼리한 변수가 Azure AD Connect에 표시되는 변수와 동일한지 확인합니다.

      A D F S 서버에 구성된 해당 클레임 규칙에서 immutableID 및 UPN 값을 확인합니다.

  3. 차이가 있는 경우 아래 방법 중 하나를 사용합니다.

    • Azure AD Connect에서 AD FS를 관리하는 경우 Azure AD Connect를 사용하여 신뢰 당사자 트러스트를 다시 설정합니다.
    • AD FS가 Azure AD Connect에서 관리되지 않는 경우 올바른 특성으로 클레임을 수정합니다.

이러한 검사가 문제를 해결하는 데 도움이 되지 않는 경우 덤프 토큰 앱 사용을 참조하여 이 문제를 해결하세요.

이 문제는 애플리케이션 쪽에서 발생합니다.

AD FS에서 최근에 토큰 서명 인증서를 갱신한 경우 페더레이션 파트너가 새 인증서를 선택했는지 확인합니다. AD FS가 최근에 갱신된 토큰 암호 해독 인증서를 사용하는 경우에도 동일한 검사를 수행합니다. AD FS의 현재 AD FS 토큰 서명 인증서가 페더레이션 파트너의 인증서와 일치하는지 확인하려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행하여 AD FS에서 현재 토큰 서명 인증서를 가져옵니다.

    Get-ADFSCertificate -CertificateType token-signing
    
  2. 반환된 인증서 목록에서 IsPrimary = TRUE 가 있는 인증서를 찾아 지문을 적어 둡니다.

  3. 페더레이션 파트너에서 현재 토큰 서명 인증서의 지문을 가져옵니다. 애플리케이션 소유자는 이를 제공해야 합니다.

  4. 두 인증서의 지문을 비교합니다.

AD FS에서 토큰 암호 해독 인증서를 가져오는 명령은 다음과 같다는 점을 제외하고 AD FS에서 갱신된 토큰 암호 해독 인증서를 사용하는지 동일한 검사를 수행합니다.

Get-ADFSCertificate -CertificateType token-decrypting

두 인증서의 지문이 일치합니다.

지문이 일치하는 경우 파트너가 새 AD FS 인증서를 사용하고 있는지 확인합니다.

인증서 불일치가 있는 경우 파트너가 새 인증서를 사용하고 있는지 확인합니다. 인증서는 AD FS 서버에서 게시한 페더레이션 메타데이터에 포함됩니다.

참고

파트너는 신뢰 당사자 트러스트 및 클레임 공급자 트러스트를 사용하여 AD FS에 표시되는 모든 리소스 조직 또는 계정 조직 파트너를 참조합니다.

  • 파트너는 페더레이션 메타데이터에 액세스할 수 있습니다.

    파트너가 페더레이션 메타데이터에 액세스할 수 있는 경우 파트너에게 새 인증서를 사용하도록 요청합니다.

  • 파트너가 페더레이션 메타데이터에 액세스할 수 없습니다.

    이 경우 파트너에게 새 인증서의 공개 키를 수동으로 보내야 합니다. 이렇게 하려면 다음과 같이 하십시오.

    1. 전체 인증서 체인을 포함하도록 공개 키를 .cert 파일 또는 .p7b 파일로 내보냅니다.
    2. 파트너에게 공개 키를 보냅니다.
    3. 파트너에게 새 인증서를 사용하도록 요청합니다.

두 인증서의 지문이 일치하지 않음

그런 다음 토큰 서명 알고리즘이 일치하지 않는지 확인합니다. 이렇게 하려면 다음과 같이 하십시오.

  1. 다음 명령을 실행하여 신뢰 당사자가 사용하는 알고리즘을 확인합니다.

    Get-ADFSRelyingPartyTrust -Name RPName | FL SignatureAlgorithm
    

    가능한 값은 SHA1 또는 SHA256입니다.

  2. 애플리케이션 쪽에서 사용되는 알고리즘은 애플리케이션 소유자에게 확인합니다.

  3. 두 알고리즘이 일치하는지 확인합니다.

두 알고리즘이 일치하는 경우 이름 ID 형식이 애플리케이션에 필요한 형식과 일치하는지 확인합니다.

  1. AD FS 서버에서 다음 명령을 실행하여 발급 변환 규칙을 덤프합니다.

    (Get-AdfsRelyingPartyTrust -Name RPName).IssuanceTransformRules
    
  2. NameIdentifier 클레임을 발급하는 규칙을 찾습니다. 이러한 규칙이 없으면 이 단계를 건너뜁니다.

    규칙의 예는 다음과 같습니다.

    c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

    다음 구문에서 NameIdentifier 형식을 확인합니다.

    Properties["Property-type-URI"] = "ValueURI"

    가능한 형식은 다음과 같습니다. 첫 번째 형식은 기본값입니다.

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifie.
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
  3. 애플리케이션 소유자에게 애플리케이션에 필요한 NameIdentifier 형식을 요청합니다.

  4. 두 NameIdentifier 형식이 일치하는지 확인합니다.

  5. 형식이 일치하지 않는 경우 애플리케이션에 필요한 형식을 사용하도록 NameIdentifier 클레임을 구성합니다. 이렇게 하려면 다음과 같이 하십시오.

    1. AD FS관리 콘솔을 엽니다.
    2. 신뢰 당사자 트러스트를 클릭하고 적절한 페더레이션 파트너를 선택한 다음 작업 창에서 클레임 발급 정책 편집 을 클릭합니다.
    3. NameIdentifier 클레임을 발급하는 규칙이 없는 경우 새 규칙을 추가하거나 기존 규칙을 업데이트합니다. 들어오는 클레임 형식이름 ID 를 선택한 다음 애플리케이션에 필요한 형식을 지정합니다.

    NameIdentifier 클레임을 발급하는 규칙이 없는 경우 변환 클레임 규칙을 추가하거나 기존 규칙을 업데이트합니다.

두 알고리즘이 일치하지 않는 경우 신뢰 당사자 트러스트에서 사용하는 서명 알고리즘을 업데이트합니다.

  1. AD FS관리 콘솔을 엽니다.

  2. 신뢰 당사자 트러스트를 마우스 오른쪽 단추로 클릭한 다음 속성을 클릭합니다.

  3. 고급 탭에서 애플리케이션에 필요한 것과 일치하는 알고리즘을 선택합니다.

    속성 설정 대화 상자의 고급 탭에서 애플리케이션에 필요한 것과 일치하도록 알고리즘을 선택합니다.

인증서 자동 갱신 정보

토큰 서명 인증서 또는 토큰 암호 해독 인증서가 자체 서명된 경우 AutoCertificateRollover는 기본적으로 이러한 인증서에서 사용하도록 설정되며 AD FS는 만료에 가까워지면 인증서의 자동 갱신을 관리합니다.

자체 서명된 인증서를 사용하는지 확인하려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행합니다.

    Get-ADFSCerticate -CertificateType "token-signing"
    

    Get-ADFSCerticate cmdlet, 인증서 유형 토큰 서명을 실행합니다.

  2. 인증서 특성을 검사합니다.

    Subject 및 Issuer 특성이 모두 "CN=ADFS 서명..."으로 시작하는 경우 인증서는 자체 서명되고 AutoCertRollover에서 관리됩니다.

인증서가 자동으로 갱신되는지 확인하려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행합니다.

    Get-ADFSProperties | FL AutoCertificateRollover
    

    Get-ADFSProperties cmdlet을 실행하여 인증서가 자동으로 갱신되는지 확인합니다.

  2. AutoCertificateRollover 특성을 검사합니다.

    • AutoCertificateRollover = TRUE 이면 AD FS는 새 인증서(기본적으로 만료 30일 전)를 자동으로 생성하고 기본 인증서(만료 25일 전)로 설정합니다.
    • AutoCertificateRollover = FALSE 인 경우 인증서를 수동으로 바꿔야 합니다.

이 문서에서는 ADFS 관련 구성 요소 및 서비스를 확인하는 방법을 소개합니다. 이러한 단계는 ADFS(Active Directory Federation Services)와 관련된 SSO(로그온) 문제를 해결할 때 도움이 될 수 있습니다.

DNS 확인

ADFS에 액세스하는 것은 WAP(웹 애플리케이션 프록시) 서버 또는 WAP 서버 앞의 부하 분산 장치 중 하나를 직접 가리킵니다. 다음 검사를 수행합니다.

  • 페더레이션 서비스 이름(예: fs.contoso.com)을 Ping합니다. Ping이 확인하는 IP 주소가 WAP 서버 또는 WAP 서버의 부하 분산 장치 중 하나인지 확인합니다.
  • DNS 서버에 페더레이션 서비스에 대한 A 레코드가 있는지 확인합니다. A 레코드는 WAP 서버 중 하나 또는 WAP 서버의 부하 분산 장치를 가리킵니다.

외부 액세스 시나리오에서 WAP가 구현되지 않은 경우 ADFS 액세스가 ADFS 서버 또는 ADFS 서버 앞의 부하 분산 장치 중 하나를 직접 가리키는지 확인합니다.

  • 페더레이션 서비스 이름(예: fs.contoso.com)을 Ping합니다. 가져오는 IP 주소가 ADFS 서버 중 하나 또는 ADFS 서버의 부하 분산 장치로 확인되는지 확인합니다.
  • DNS 서버에 페더레이션 서비스에 대한 A 레코드가 있는지 확인합니다. A 레코드는 ADFS 서버 중 하나 또는 ADFS 서버의 부하 분산 장치를 가리킵니다.

부하 분산 장치가 사용되는지 확인합니다.

방화벽이 다음 사이의 트래픽을 차단하는지 확인합니다.

  • ADFS 서버 및 부하 분산 장치입니다.
  • WAP를 사용하는 경우 WAP(웹 애플리케이션 프록시) 서버 및 부하 분산 장치입니다.

부하 분산 장치에서 프로브를 사용하는 경우 다음을 확인합니다.

  • Windows Server 2012 R2를 실행하는 경우 2014년 8월 업데이트 롤업이 설치되어 있는지 확인합니다.
  • WAP 서버 및 ADFS 서버의 방화벽에서 포트 80이 사용하도록 설정되어 있는지 확인합니다.
  • 포트 80 및 엔드포인트 /adfs/프로브에 대해 프로브가 설정되어 있는지 확인합니다.

방화벽 설정 확인

TCP 포트 443을 통한 인바운드 트래픽이 다음에서 사용하도록 설정되어 있는지 확인합니다.

  • 웹 애플리케이션 프록시 서버와 페더레이션 서버 팜 간의 방화벽입니다.
  • 클라이언트와 웹 애플리케이션 프록시 서버 간의 방화벽입니다.

다음 조건이 충족되면 클라이언트와 웹 애플리케이션 프록시 서버 간의 방화벽에서 TCP 포트 49443을 통한 인바운드 트래픽이 사용하도록 설정되어 있는지 확인합니다.

  • X.509 인증서를 사용하는 TLS 클라이언트 인증이 사용됩니다.
  • Windows Server 2012 R2에서 ADFS를 사용하고 있습니다.

참고

웹 애플리케이션 프록시 서버와 페더레이션 서버 간의 방화벽에는 구성이 필요하지 않습니다.

프록시에서 엔드포인트를 사용할 수 있는지 확인합니다.

ADFS는 다양한 기능 및 시나리오에 대한 다양한 엔드포인트를 제공합니다. 모든 엔드포인트가 기본적으로 사용하도록 설정되는 것은 아닙니다. 프록시에서 엔드포인트를 사용할 수 있는지 여부를 확인하려면 다음 단계를 수행합니다.

  1. ADFS 서버에서 ADFS 관리 콘솔을 엽니다.

  2. 서비스 > 엔드포인트를 확장합니다.

  3. 엔드포인트를 찾아 프록시 사용 열에서 상태를 사용할 수 있는지 확인합니다.

    프록시 사용 열에 표시된 AD F S 엔드포인트 상태를 확인합니다.

프록시 트러스트 관계 확인

WAP(웹 애플리케이션 프록시)가 배포된 경우 WAP 서버와 AD FS 서버 간에 프록시 트러스트 관계를 설정해야 합니다. 프록시 트러스트 관계가 설정되었는지 또는 특정 시점에 실패하기 시작하는지 확인합니다.

참고

이 페이지의 정보는 AD FS 2012 R2 이상에 적용됩니다.

배경 정보

프록시 트러스트 관계는 클라이언트 인증서 기반입니다. 설치 후 웹 애플리케이션 프록시 마법사를 실행하면 마법사에서 지정한 자격 증명을 사용하여 자체 서명된 클라이언트 인증서를 생성합니다. 그런 다음 마법사는 인증서를 AD FS 구성 데이터베이스에 삽입하고 AD FS 서버의 AdfsTrustedDevices 인증서 저장소에 추가합니다.

모든 SSL 통신의 경우 http.sys 인증서와 일치하도록 SSL 인증서 바인딩에 대해 다음 우선 순위 순서를 사용합니다.

우선 순위 이름 매개 변수 설명
1 IP IP:port 정확한 IP 및 포트 일치
2 SNI 호스트 이름:포트 정확한 호스트 이름 일치(연결에서 SNI를 지정해야 합니다.)
3 CCS 포트 중앙 인증서 저장소 호출
4 IPv6 와일드카드 포트 IPv6 와일드카드 일치(연결은 IPv6여야 합니다.)
5 IP 와일드카드 포트 IP 와일드카드 일치(연결은 IPv4 또는 IPv6일 수 있음)

AD FS 2012 R2 이상은 IIS(인터넷 정보 서비스)와 독립적이며 http.sys 위에 있는 서비스로 실행됩니다. hostname:port SSL 인증서 바인딩은 AD FS에서 사용됩니다. 클라이언트 인증서 인증 중에 AD FS는 AdfsTrustedDevices 저장소의 인증서를 기반으로 CTL(인증서 신뢰 목록)을 보냅니다. AD FS 서버에 대한 SSL 인증서 바인딩이 IP:port를 사용하거나 CTL 저장소가 AdfsTrustedDevices가 아닌 경우 프록시 트러스트 관계가 설정되지 않을 수 있습니다.

AD FS에 대한 SSL 인증서 바인딩 가져오기

AD FS 서버의 Windows PowerShell 다음 명령을 실행합니다.
netsh http show sslcert

반환된 바인딩 목록에서 애플리케이션 ID가 5d89a20c-beab-4389-9447-324788eb944a인 바인딩을 찾습니다. 다음은 정상 바인딩의 예입니다. "Ctl Store 이름" 줄을 적어둡니다.

Hostname:port : adfs.contoso.com:443
Certificate Hash : 3638de9b03a488341dfe32fc3ae5c480ee687793
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)  
Ctl Store Name : AdfsTrustedDevices
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled

스크립트를 실행하여 문제 자동 검색

프록시 트러스트 관계의 문제를 자동으로 검색하려면 다음 스크립트를 실행합니다. 검색된 문제에 따라 그에 따라 작업을 수행합니다.

param
(
  [switch]$syncproxytrustcerts
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 – Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $false
While($i -lt $httpsslcertoutput.count)
{
        $ipport = $false
        $hostnameport = $false
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $true }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $true }
        ## Check for IP specific certificate bindings
        if ( ( $ipport -eq $true ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There is an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $true
            }
            $i = $i + 14
            continue
        }
        ## check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $true )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            If ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding does not have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $true
            }
        $i = $i + 14
        continue
        }
    $i++
}
If ( $certbindingissuedetected -eq $false ) { Write-Host "Check Passed: No certificate binding issues detected" }
}
function checkadfstrusteddevicesstore()
{
## check for CA issued (non-self signed) certs in the AdfsTrustedDevices cert store
Write-Host; Write-Host "2 – Checking AdfsTrustedDevices cert store for non-self signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
If ( $certlist.count -gt 0 )
{
    Write-Warning "The following non-self signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
Else { Write-Host "Check Passed: No non-self signed certs present in AdfsTrustedDevices cert store" }
}
function checkproxytrustcerts
{
    Param ([bool]$repair=$false)
    Write-Host; Write-Host("3 – Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $false
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $true
          Write-Warning "This cert is NOT in the CTL: $certThumbprint – $certSubject"
       if ($repair -eq $true)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
         }
        }
    }
    $store.Close()
    if ($atLeastOneMismatch -eq $false)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

문제 1: IP 특정 바인딩이 있습니다.

바인딩이 포트 443의 AD FS 인증서 바인딩과 충돌할 수 있습니다.

IP:포트 바인딩의 우선 순위가 가장 높습니다. IP:포트 바인딩이 AD FS SSL 인증서 바인딩에 있는 경우 http.sys 항상 SSL 통신에 대한 바인딩에 인증서를 사용합니다. 이 문제를 해결하려면 다음 메서드를 사용합니다.

  1. IP:포트 바인딩 제거

    IP:포트 바인딩을 제거한 후 다시 돌아올 수 있습니다. 예를 들어 이 IP:포트 바인딩으로 구성된 애플리케이션은 다음 서비스 시작 시 자동으로 다시 만들 수 있습니다.

  2. AD FS SSL 통신에 다른 IP 주소 사용

    IP:포트 바인딩이 필요한 경우 ADFS 서비스 FQDN을 바인딩에 사용되지 않는 다른 IP 주소로 확인합니다. 이렇게 하면 http.sys SSL 통신에 Hostname:port 바인딩을 사용합니다.

  3. AdfsTrustedDevices를 IP:port 바인딩에 대한 CTL 저장소로 설정

    위의 메서드를 사용할 수 없는 경우 이것이 최후의 수단입니다. 그러나 기본 CTL 저장소를 AdfsTrustedDevices로 변경하기 전에 다음 조건을 이해하는 것이 좋습니다.

    • IP:포트 바인딩이 있는 이유
    • 바인딩이 클라이언트 인증서 인증을 위해 기본 CTL 저장소를 사용하는 경우

문제 2: AD FS 인증서 바인딩에 CTL 저장소 이름이 AdfsTrustedDevices로 설정되어 있지 않습니다.

Azure AD Connect가 설치된 경우 AAD Connect를 사용하여 모든 AD FS 서버에서 SSL 인증서 바인딩에 대한 CTL 저장소 이름을 AdfsTrustedDevices로 설정합니다. Azure AD Connect가 설치되지 않은 경우 모든 AD FS 서버에서 다음 명령을 실행하여 AD FS 인증서 바인딩을 다시 생성합니다.

Set-AdfsSslCertificate -Thumbprint Thumbprint

문제 3: 자체 서명되지 않은 인증서가 AdfsTrustedDevices 인증서 저장소에 있음

CA에서 발급한 인증서가 자체 서명된 인증서만 있는 인증서 저장소에 있는 경우 저장소에서 생성된 CTL에는 CA 발급 인증서만 포함됩니다. AdfsTrustedDevices 인증서 저장소는 자체 서명된 인증서만 있어야 하는 저장소입니다. 이러한 인증서는 다음과 같습니다.

  • MS-Organization-Access: 회사 조인 인증서를 발급하는 데 사용되는 자체 서명된 인증서입니다.
  • ADFS 프록시 트러스트: 각 웹 애플리케이션 프록시 서버에 대한 인증서입니다.

각 웹 애플리케이션 프록시 서버에 대한 인증서입니다.

따라서 AdfsTrustedDevices 인증서 저장소에서 CA 발급 인증서를 삭제합니다.

문제 4: KB2964735 설치 또는 -syncproxytrustcerts를 사용하여 스크립트 다시 실행

AD FS 서버와 프록시 트러스트 관계가 설정되면 클라이언트 인증서가 AD FS 구성 데이터베이스에 기록되고 AD FS 서버의 AdfsTrustedDevices 인증서 저장소에 추가됩니다. AD FS 팜 배포의 경우 클라이언트 인증서가 다른 AD FS 서버와 동기화되어야 합니다. 어떤 이유로든 동기화가 수행되지 않는 경우 프록시 트러스트 관계는 트러스트가 설정된 AD FS 서버에 대해서만 작동하지만 다른 AD FS 서버에 대해서는 작동하지 않습니다.

이 문제를 해결하려면 다음 방법 중 하나를 사용합니다.

방법 1

모든 AD FS 서버에 KB 2964735 문서화된 업데이트를 설치합니다. 업데이트가 설치되면 클라이언트 인증서의 동기화가 자동으로 수행될 것으로 예상됩니다.

방법 2

  • syncproxytrustcerts 스위치를 사용하여 스크립트를 실행하여 AD FS 구성 데이터베이스의 클라이언트 인증서를 AdfsTrustedDevices 인증서 저장소로 수동으로 동기화합니다. 스크립트는 팜의 모든 AD FS 서버에서 실행되어야 합니다.

참고

클라이언트 인증서가 정기적으로 갱신되기 때문에 이는 영구적인 솔루션이 아닙니다.

문제 5: 모든 검사가 통과됩니다. 그러나 문제는 지속됩니다.

표준 시간대 또는 표준 시간대가 일치하지 않는지 확인합니다. 시간이 일치하지만 표준 시간대가 일치하지 않으면 프록시 트러스트 관계도 설정되지 않습니다.

AD FS 서버와 WAP 서버 간에 SSL 종료가 있는지 확인합니다.

AD FS 서버와 WAP 서버 간의 네트워크 디바이스에서 SSL 종료가 발생하는 경우 통신이 클라이언트 인증서를 기반으로 하므로 AD FS와 WAP 간의 통신이 중단됩니다.

AD FS와 WAP 서버 간의 네트워크 디바이스에서 SSL 종료를 사용하지 않도록 설정합니다.

덤프 토큰 앱 사용

덤프 토큰 앱은 페더레이션 서비스의 문제를 디버깅하고 사용자 지정 클레임 규칙의 유효성을 검사할 때 유용합니다. 공식 솔루션이 아니라 문제 해결을 위해 권장되는 좋은 독립적인 디버깅 솔루션입니다.

덤프 토큰 앱을 사용하기 전에

덤프 토큰 앱을 사용하기 전에 다음을 수행해야 합니다.

  1. 액세스하려는 애플리케이션에 대한 신뢰 당사자의 정보를 가져옵니다. OAuth 인증이 구현된 경우 OAuth 클라이언트 정보도 가져옵니다.
  2. 덤프 토큰 앱을 설정합니다.

신뢰 당사자 및 OAuth 클라이언트 정보 가져오기

기존 신뢰 당사자를 사용하는 경우 다음 단계를 수행합니다.

  1. AD FS 서버에서 관리자 권한으로 실행 옵션을 사용하여 Windows PowerShell 엽니다.

  2. 다음 명령을 실행하여 Windows PowerShell AD FS 2.0 구성 요소를 추가합니다.

    Add-PSSnapin Microsoft.Adfs.PowerShell
    
  3. 다음 명령을 실행하여 신뢰 당사자 정보를 가져옵니다.

    $rp = Get-AdfsRelyingPartyTrust RPName
    
  4. 다음 명령을 실행하여 OAuth 클라이언트 정보를 가져옵니다.

    $client = Get-AdfsClient ClientName
    

Windows Server 2016 애플리케이션 그룹 기능을 사용하는 경우 아래 단계를 수행합니다.

  1. AD FS 서버에서 관리자 권한으로 실행 옵션을 사용하여 Windows PowerShell 엽니다.

  2. 다음 명령을 실행하여 신뢰 당사자 정보를 가져옵니다.

    $rp = Get-AdfsWebApiApplication ResourceID
    
  3. OAuth 클라이언트가 공용인 경우 다음 명령을 실행하여 클라이언트 정보를 가져옵니다.

    $client = Get-AdfsNativeClientApplication ClientName
    

    OAuth 클라이언트가 기밀인 경우 다음 명령을 실행하여 클라이언트 정보를 가져옵니다.

    $client = Get-AdfsServerApplication ClientName
    

덤프 토큰 앱 설정

덤프 토큰 앱을 설정하려면 Windows PowerShell 창에서 다음 명령을 실행합니다.

$authzRules = "=>issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");"
$issuanceRules = "x:[]=>issue(claim=x);"
$redirectUrl = "https://dumptoken.azurewebsites.net/default.aspx"
$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl
Add-ADFSRelyingPartyTrust -Name "urn:dumptoken" -Identifier "urn:dumptoken" -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

이제 다음 문제 해결 방법을 계속 진행합니다. 각 메서드의 끝에서 문제가 해결되었는지 확인합니다. 그렇지 않은 경우 다른 메서드를 사용합니다.

문제 해결 방법

권한 부여 정책을 확인하여 사용자에게 영향을 주는지 확인합니다.

이 메서드에서는 먼저 정책 세부 정보를 가져오고 덤프 토큰 앱을 사용하여 정책을 진단하여 사용자에게 영향을 주는지 확인합니다.

정책 세부 정보 가져오기

$rp. IssuanceAuthorizationRules는 신뢰 당사자의 권한 부여 규칙을 보여줍니다.

Windows Server 2016 이상 버전에서는 $rp 사용할 수 있습니다. 인증 및 권한 부여 정책을 구성하는 AccessControlPolicyName입니다. $rp 경우. AccessControlPolicyName에는 값이 있으며, 권한 부여 정책을 제어하는 액세스 제어 정책이 있습니다. 이 경우 $rp. IssuanceAuthorizationRules가 비어 있습니다. $rp 사용합니다. ResultantPolicy를 사용하여 액세스 제어 정책에 대한 세부 정보를 확인합니다.

$rp 경우. ResultantPolicy에는 정책에 대한 세부 정보가 없으며 실제 클레임 규칙을 확인합니다. 클레임 규칙을 얻으려면 다음 단계를 수행합니다.

  1. 다음 명령을 실행하여 액세스 제어 정책을 $null 설정합니다.
    Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AccessControlPolicyName $null
  2. 다음 명령을 실행하여 신뢰 당사자 정보를 가져옵니다.
    $rp = Get-AdfsRelyingPartyTrust RPName
  3. 확인 $rp.IssuanceAuthorizationRules$rp. AdditionalAuthenticationRules.
덤프 토큰 앱을 사용하여 권한 부여 정책 진단
  1. 덤프 토큰 인증 정책을 실패한 신뢰 당사자와 동일하게 설정합니다.

  2. 사용자가 설정한 인증 정책에 따라 다음 링크 중 하나를 열게 합니다.

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • 다단계 인증 강제 적용: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  3. Sign-In 페이지에 로그인합니다.

사용자가 얻을 수 있는 것은 사용자의 클레임 집합입니다. 권한 부여 정책에 이러한 클레임을 기반으로 사용자를 명시적으로 거부하거나 허용하는 항목이 있는지 확인합니다.

누락되거나 예기치 않은 클레임으로 인해 리소스에 대한 액세스 거부가 발생하는지 확인합니다.

  1. 덤프 토큰 앱에서 클레임 규칙을 실패한 신뢰 당사자의 클레임 규칙과 동일하게 구성합니다.

  2. 덤프 토큰 인증 정책을 실패한 신뢰 당사자와 동일하게 구성합니다.

  3. 사용자가 설정한 인증 정책에 따라 다음 링크 중 하나를 열게 합니다.

    • WS-Fed: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken
    • SAML-P: https://FerderationInstance/adfs/ls/IdpInitiatedSignOn?LoginToRP=urn:dumptoken
    • 다단계 인증 강제 적용: https://FerderationInstance/adfs/ls?wa=wsignin1.0&wtrealm=urn:dumptoken&wauth=http://schemas.microsoft.com/claims/multipleauthn
  4. Sign-In 페이지에 로그인합니다.

신뢰 당사자가 사용자에 대해 가져올 클레임 집합입니다. 클레임이 누락되거나 예기치 않은 경우 발급 정책을 확인하여 이유를 확인합니다.

모든 클레임이 있는 경우 애플리케이션 소유자에게 확인하여 누락되거나 예기치 않은 클레임을 확인합니다.

디바이스 상태가 필요한지 확인

권한 부여 규칙이 디바이스 클레임을 확인하는 경우 덤프 토큰 앱에서 가져오는 클레임 목록에 이러한 디바이스 클레임이 누락되었는지 확인합니다. 누락된 클레임은 디바이스 인증을 차단할 수 있습니다. 덤프 토큰 앱에서 클레임을 가져오려면 덤프 토큰 앱 사용 의 단계에 따라 사용자에게 영향을 받은 경우 권한 부여 정책 확인에서 권한 부여 정책 섹션을 진단합니다.

다음은 디바이스 클레임입니다. 권한 부여 규칙은 그 중 일부를 사용할 수 있습니다.

  • http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/ismanaged
  • http://schemas.microsoft.com/2012/01/devicecontext/claims/isregistereduser
  • http://schemas.microsoft.com/2014/02/devicecontext/claims/isknown
  • http://schemas.microsoft.com/2014/02/deviceusagetime
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/iscompliant
  • http://schemas.microsoft.com/2014/09/devicecontext/claims/trusttype

클레임이 누락된 경우 등록된 디바이스를 사용하여 온-프레미스 조건부 액세스 구성 의 단계에 따라 환경이 디바이스 인증을 위해 설정되었는지 확인합니다.

모든 클레임이 있는 경우 덤프 토큰 앱의 클레임 값이 권한 부여 정책에 필요한 값과 일치하는지 확인합니다.