파트너 테넌트 사용자를 대상으로 MFA(다단계 인증) 의무화
적절한 역할: 관리 에이전트 | 판매 에이전트 | 기술 지원팀 에이전트 | 청구 관리자 | 보안 관리자
더 나은 보안, 지속적인 보안 및 개인 정보 보호는 우리의 최우선 과제 중 하나이며, 우리는 파트너가 고객과 테넌트 보호에 계속 도움을 줍니다.
파트너가 ID 도용 및 무단 액세스로부터 비즈니스와 고객을 보호할 수 있도록 파트너 테넌트에 대한 더 많은 보안 보호 장치를 활성화했습니다. 이러한 보호 장치는 MFA를 의무화하고 확인합니다. MFA를 의무화하면 파트너가 자격 증명 손상에 대해 고객 리소스에 대한 액세스를 보호할 수 있습니다.
이 문서에서는 파트너 센터에서 MFA(다단계 인증)를 의무화하는 방법에 대한 자세한 예제와 지침을 제공합니다.
CSP(클라우드 솔루션 공급자) 프로그램, 제어판 공급업체(CV) 및 Advisor에 참여하는 파트너는 규정을 준수하기 위해 파트너 보안 요구 사항을 구현해야 합니다.
파트너는 게스트 사용자를 포함한 파트너 테넌트의 모든 사용자 계정에 MFA를 적용해야 합니다. 사용자는 다음 영역에 대한 MFA 확인을 완료해야 합니다.
파트너 센터
파트너 센터의 일부 페이지는 다음을 포함하여 MFA로 보호됩니다.
- 고객 탭 아래의 모든 페이지(즉, URL로 시작하는
https://partner.microsoft.com/commerce/*모든 페이지) - 고객 지원>요청 탭 아래의 모든 페이지(예: URL
https://partner.microsoft.com/dashboard/v2/support/customers/*로 액세스하는 모든 페이지) - 청구 탭의 모든 페이지
개요 페이지 및 서비스 상태 확인 페이지와 같은 파트너 센터의 다른 페이지는 MFA가 필요하지 않습니다.
다음 표에서는 이러한 MFA로 보호된 페이지에 액세스할 수 있는 권한이 있는 사용자 유형을 보여 줍니다(이 기능의 영향을 받습니다).
| MFA로 보호된 페이지 | 관리 담당자 | 영업 담당자 | 기술 지원팀 담당자 | 보안 관리자 | 청구 관리자 |
|---|---|---|---|---|---|
| 고객 탭 아래의 모든 페이지 | x | x | x | ||
| 고객 지원 > 요청 탭 아래의 모든 페이지 | x | x | |||
| 청구 페이지 | x | x | x | ||
| 보안 작업 영역 | x | x |
이러한 페이지에 액세스하려면 먼저 MFA 확인을 완료해야 합니다.
지원되는 MFA 옵션
- Microsoft를 사용하는 파트너는 Microsoft Entra 다단계 인증을 지원했습니다. 자세한 내용은 Microsoft Entra 다단계 인증을 사용하도록 설정하는 여러 가지 방법(MFA 지원)을 참조하세요.
- 통합 MFA 페더레이션 인증을 구현한 파트너입니다. 이러한 파트너 사용자는 파트너 센터에 액세스하고 GDAP를 사용하여 고객을 관리할 수 있습니다. AD FS: AD FS에 대한 메서드 구성에서 사용할 수 있는 MFA 제품과 통합된 MFA 공급자를 참조하세요.
Important
파트너는 Microsoft Entra ID의 통합 MFA 클레임과 호환되는 인증 공급자를 사용해야 합니다. 통합 클레임은 인증 중에 제공되는 실제 자격 증명 유형을 나타냅니다. 파트너는 GDAP를 사용하여 고객 테넌트 관리를 위해 통합 MFA를 사용해야 합니다.
파트너 센터 및 APIs
다음 파트너 센터 API의 경우 App+사용자 액세스 및 Microsoft Entra ID 지원 MFA가 필요합니다.
- 검색(가격/카탈로그/프로모션)
- 거래 및 관리
- 청구 및 조정
- 위임된 액세스/AOBO를 사용하여 고객 관리
- 사용자 및 라이선스 할당(DAP만 해당)
- 사용자 및 라이선스 할당(GDAP 사용)
- 세분화된 관리자 관계 요청 및 액세스 할당
파트너가 사용할 수 있는 옵션은 다음과 같습니다.
- MFA 요구 사항을 충족하려면 Microsoft 기본 제공 인증 방법을 사용합니다.
- 페더레이션 ID 공급자 를 사용하는 경우 페더레이션이 페더레이션된 MFA를 수락하도록 구성되어 있는지 확인합니다.
- ADFS를 사용하여 외부 두 번째 요소를 구성하려면 AD FS에서 사용할 수 있는 MFA 제품이 있는 타사 공급자를 참조하세요. AD FS에 대한 인증 방법 구성
- MFA 구현: 보안 기본값 지침에 따라 보안 기본값 또는 조건부 액세스를 통해 MFA를 즉시 사용하도록 설정합니다.
확인 예제
파트너 센터에서 확인이 작동하는 방식을 보여 주려면 다음 예제를 고려하세요.
예제 1: 파트너가 Microsoft Entra 다단계 인증을 구현했습니다.
Alejandra는 Contoso라는 CSP에서 작동합니다. Contoso는 Microsoft Entra 다단계 인증을 사용하여 Contoso 파트너 테넌트의 모든 사용자에 대해 MFA를 구현했습니다.
Alejandra는 새 브라우저 세션을 시작하고 파트너 센터 개요 페이지(MFA로 보호되지 않음)로 이동합니다. 파트너 센터는 Alejandra를 Microsoft Entra ID로 리디렉션하여 로그인합니다.
Contoso의 기존 Microsoft Entra 다단계 인증 설정으로 인해 MFA 확인을 완료하려면 Alejandra가 필요합니다. 로그인 및 MFA 확인이 성공하면 Alejandra는 파트너 센터 개요 페이지로 다시 리디렉션됩니다.
Alejandra는 파트너 센터에서 MFA로 보호되는 페이지 중 하나에 액세스하려고 합니다. Alejandra는 이전에 로그인하는 동안 MFA 확인을 완료했으므로 Alejandra는 MFA 확인을 다시 거치지 않고도 MFA 보호 페이지에 액세스할 수 있습니다.
예제 2: 파트너가 ID 페더레이션을 사용하여 비 Microsoft MFA를 구현했습니다.
Prashob은 Wingtip이라는 CSP에서 작동합니다. Wingtip은 ID 페더레이션을 통해 Microsoft Entra ID와 통합되는 비 Microsoft MFA를 사용하여 Wingtip 파트너 테넌트의 모든 사용자에 대해 MFA를 구현했습니다.
Prashob은 새 브라우저 세션을 시작하고 파트너 센터 개요 페이지(MFA로 보호되지 않음)로 이동합니다. 파트너 센터는 Prashob을 Microsoft Entra ID로 리디렉션하여 로그인합니다.
Wingtip에는 설정 ID 페더레이션이 있으므로 Microsoft Entra ID는 Prashob을 페더레이션 ID 공급자로 리디렉션하여 로그인 및 MFA 확인을 완료합니다. 로그인 및 MFA 확인이 성공하면 Prashob은 Microsoft Entra ID로 다시 리디렉션된 다음 파트너 센터 개요 페이지로 리디렉션됩니다.
Prashob은 파트너 센터에서 MFA로 보호되는 페이지 중 하나에 액세스하려고 합니다. Prashob은 이전에 로그인하는 동안 MFA 확인을 이미 완료했으므로 MFA 확인을 다시 거치지 않고도 MFA 보호 페이지에 액세스할 수 있습니다.
그런 다음 Prashob은 서비스 관리 페이지로 이동하여 Contoso의 Microsoft Entra ID에 사용자를 추가합니다. Prashob은 강력한 인증으로 Entra 호환 인증 공급자를 사용했기 때문에 문제 없이 고객 테넌트에 액세스할 수 있습니다.
이 예제에서 Prashob에 대한 권장 사항은 고객의 테넌트를 성공적으로 관리할 수 있도록 Microsoft Entra 다단계 인증 솔루션 또는 Entra 호환 인증 공급자를 사용하는 것입니다.
예제 3: 파트너가 MFA를 구현하지 않았습니다.
Fabrikam이라는 CSP 파트너는 아직 MFA를 구현하지 않았습니다. Microsoft는 Microsoft Entra ID 지원 MFA 솔루션을 구현하는 것이 좋습니다.
존은 파브리캄에서 일한다. Fabrikam은 Fabrikam 파트너 테넌트의 모든 사용자에 대해 MFA를 구현하지 않았습니다.
John은 새 브라우저 세션을 시작하고 파트너 센터 개요 페이지(MFA로 보호되지 않음)로 이동합니다. 파트너 센터는 John을 Microsoft Entra ID로 리디렉션하여 로그인합니다.
성공적으로 로그인한 후 John은 MFA 확인을 완료하지 않았기 때문에 파트너 센터 개요 페이지로 다시 리디렉션됩니다.
John이 파트너 센터에서 MFA로 보호되는 페이지 중 하나에 액세스하려고 합니다. John이 MFA 확인을 완료하지 않았기 때문에 파트너 센터는 John을 Microsoft Entra ID로 리디렉션하여 MFA 확인을 완료합니다. John이 MFA를 완료해야 하는 것은 이번이 처음이므로 John은 MFA 등록도 요청합니다. MFA 등록 및 MFA 확인에 성공하면 John은 MFA로 보호되는 페이지에 액세스할 수 있습니다.
또 다른 날, Fabrikam이 모든 사용자에 대해 MFA를 구현하기 전에 John은 새 브라우저 세션을 시작하고 파트너 센터 개요 페이지(MFA로 보호되지 않음)로 이동합니다. 파트너 센터는 MFA 프롬프트 없이 로그인하도록 John을 Microsoft Entra ID로 리디렉션합니다.
John이 파트너 센터에서 MFA로 보호되는 페이지 중 하나에 액세스하려고 합니다. John이 MFA 확인을 완료하지 않았기 때문에 파트너 센터는 John을 Microsoft Entra ID로 리디렉션하여 MFA 확인을 완료합니다. John이 MFA를 등록했기 때문에 이번에는 MFA 확인을 완료하라는 요청만 표시됩니다.
예제 4: 파트너가 Microsoft Entra와 호환되지 않는 타사 MFA를 구현했습니다.
Trent는 Wingtip이라는 CSP에서 작동합니다. Wingtip은 조건부 액세스가 있는 클라우드 환경에서 비 Microsoft MFA를 사용하여 Wingtip 파트너 테넌트의 모든 사용자에 대해 MFA를 구현했습니다.
Trent는 새 브라우저 세션을 시작하고 파트너 센터 개요 페이지(MFA로 보호되지 않음)로 이동합니다. 파트너 센터에서는 Trent를 Microsoft Entra ID로 리디렉션하여 로그인합니다.
Wingtip은 Microsoft Entra ID와 호환되지 않고 강력한 인증이 없는 타사 MFA 통합을 사용했기 때문에 Trent는 파트너 센터 내에서 모든 MFA 보호 페이지 및 API에 액세스하지 못하도록 차단됩니다.
Trent는 MFA로 보호되는 페이지에 액세스하기 때문에 MFA로 보호되는 페이지에 액세스하려면 강력한 인증을 사용하여 MFA를 제공해야 합니다.
파트너는 인증 중에 제공된 실제 자격 증명 유형을 반영하여 자격 증명 메서드 클레임(액세스 토큰 클레임 참조의 "amr 클레임")을 지원하는 Microsoft Entra ID와 호환되는 인증 공급자를 사용해야 Microsoft ID 플랫폼.
CSP 파트너는 테넌트 보안 기준을 높이기 위해 Microsoft Entra ID와 호환되는 MFA를 즉시 구현하는 것이 좋습니다.
파트너 센터 API
파트너 센터 API는 앱 전용 인증과 애플리케이션 및 사용자(App+User) 인증을 모두 지원합니다.
App+User 인증을 사용하는 경우 파트너 센터에 MFA 확인이 필요합니다. 더 구체적으로, 파트너 애플리케이션이 파트너 센터에 API 요청을 보낼 때 요청의 권한 부여 헤더에 액세스 토큰을 포함해야 합니다.
참고 항목
보안 애플리케이션 모델은 파트너 센터 API를 호출할 때 Microsoft Azure MFA 아키텍처를 통해 CSP 파트너 및 CPV를 인증하기 위한 확장 가능한 프레임워크입니다. 서비스 자동화에서 MFA를 사용하는 경우 이 프레임워크를 구현해야 합니다.
파트너 센터에서 App+User 인증을 사용하여 가져온 액세스 토큰이 있는 API 요청을 받으면 파트너 센터 API는 AMR(인증 방법 참조) 클레임에 MFA 값이 있는지 확인합니다. JWT 디코더를 사용하여 예상 AMR(인증 방법 참조) 값이 액세스 토큰에 포함되어 있는지 여부를 확인할 수 있습니다.
{
"aud": "https://api.partnercenter.microsoft.com",
"iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
"iat": 1549088552,
"nbf": 1549088552,
"exp": 1549092452,
"acr": "1",
"amr": [
"pwd",
"mfa"
],
"appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
"appidacr": "0",
"family_name": "Adminagent",
"given_name": "CSP",
"ipaddr": "127.0.0.1",
"name": "Adminagent CSP",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"scp": "user_impersonation",
"tenant_region_scope": "NA",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
"unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
"upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
"ver": "1.0"
}
값이 있는 경우 파트너 센터에서 MFA 확인이 완료된 것으로 결정하여 API 요청을 처리합니다.
값이 없으면 파트너 센터 API는 다음 응답을 사용하여 요청을 거부합니다.
HTTP/1.1 401 Unauthorized - MFA required Transfer-Encoding: chunked Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555 WWW-Authenticate: Bearer error="invalid_token" Date: Thu, 14 Feb 2019 21:54:58 GMT
파트너 센터 API를 호출할 때 앱 전용 액세스 토큰은 고객 테넌트에서 GDAP 역할 할당이 필요하지 않은 작업에 대해서만 지원됩니다.
더 많은 모범 사례를 알아보려면 API 인증 및 권한 부여 - 개요를 참조하세요.
파트너에게 위임된 관리
파트너 테넌트는 GDAP(세분화된 위임 관리자 권한)를 사용하여 Microsoft Online Services 포털(portal.azure.com 또는 admin.microsoft.com), CLI(명령줄 인터페이스) 및 API(App+User 인증 사용)를 통해 고객 리소스를 관리해야 합니다. 자세한 내용은 지원되는 MFA 옵션을 참조 하세요.
서비스 포털 사용
CSP 파트너는 서비스 관리 인터페이스를 통해 파트너 센터 포털 에서 고객을 관리할 수 있습니다. 파트너는 고객으로 이동하여 서비스 관리를 선택하여 고객에 대한 특정 서비스를 관리할 수 있습니다. 파트너는 GDAP 역할 지침을 따라 고객을 관리하는 적절한 최소 권한 GDAP 역할을 가져와야 합니다.
파트너 위임 관리자 권한(Admin-On-Behalf-Of)을 사용하여 Microsoft Online Services 포털에 액세스하여 고객 리소스를 관리하는 경우 이러한 포털의 대부분은 고객 Microsoft Entra 테넌트가 인증 컨텍스트로 설정된 상태에서 파트너 계정이 대화형으로 인증되어야 합니다. 파트너 계정은 고객 테넌트에 로그인하는 데 필요합니다.
MFA를 요구하는 정책이 있는 경우 Microsoft Entra ID 인증을 사용하려면 사용자가 MFA 확인을 완료해야 합니다. 파트너 계정이 관리 ID인지, 아니면 페더레이션 ID인지에 따라 다음과 같은 두 가지 사용자 환경을 사용할 수 있습니다.
파트너 계정이 관리 ID인 경우 Microsoft Entra ID는 사용자에게 MFA 확인을 완료하라는 메시지를 직접 표시합니다. 파트너 계정이 이전에 Microsoft Entra ID를 사용하여 MFA에 등록되지 않은 경우 먼저 MFA 등록을 완료하라는 메시지가 표시됩니다.
파트너 계정이 페더레이션 ID인 경우 환경은 파트너 관리자가 Microsoft Entra ID에서 페더레이션을 구성하는 방법에 따라 달라집니다. Microsoft Entra ID에서 페더레이션을 설정할 때 파트너 관리자는 페더레이션 ID 공급자가 MFA를 지원하는지 여부를 Microsoft Entra ID에 나타낼 수 있습니다.
- 이 경우 Microsoft Entra ID는 사용자를 페더레이션 ID 공급자로 리디렉션하여 MFA 확인을 완료합니다.
- 그렇지 않은 경우 Microsoft Entra ID는 사용자에게 MFA 확인을 완료하라는 메시지를 직접 표시합니다. 파트너 계정이 이전에 Microsoft Entra ID를 사용하여 MFA에 등록되지 않은 경우 먼저 MFA 등록을 완료하라는 메시지가 표시됩니다.
전체 환경은 최종 고객 테넌트가 관리자를 위해 MFA를 구현한 시나리오와 같습니다. 예를 들어 고객 테넌트는 Microsoft Entra 보안 기본값을 사용하도록 설정했습니다. 이 기본값을 사용하려면 관리자 권한이 있는 모든 계정이 관리 에이전트 및 기술 지원팀 에이전트를 포함하여 MFA 확인을 사용하여 고객 테넌트에 로그인해야 합니다.
테스트를 위해 파트너는 고객 테넌트에서 Microsoft Entra 보안 기본값을 사용하도록 설정한 다음, GDAP(파트너 세부 위임 관리 권한)를 사용하여 고객 테넌트에 액세스할 수 있습니다.
참고 항목
모든 Microsoft Online Service 포털에서 GDAP를 사용하여 고객 리소스에 액세스할 때 파트너 계정이 고객 테넌트에 로그인하도록 요구하는 것은 아닙니다. 대신 파트너 계정만 파트너 테넌트에 로그인해야 합니다. 예를 들어 Exchange 관리 센터가 있습니다. 시간이 지남에 따라 이러한 포털은 GDAP를 사용할 때 파트너 계정이 고객 테넌트에 로그인하도록 요구할 것으로 예상합니다.
MFA 등록 환경
MFA 확인 중에 파트너 계정이 이전에 MFA에 등록되지 않은 경우 Microsoft Entra ID는 사용자에게 MFA 등록을 먼저 완료하라는 메시지를 표시합니다.
Microsoft Authenticator 메서드에 대한 자세한 내용을 검토합니다.
사용자가 다음을 선택하면 확인 방법 목록에서 선택하라는 메시지가 표시됩니다.
등록에 성공하면 사용자가 선택한 확인 방법을 사용하여 MFA 확인을 완료해야 합니다.
일반적인 문제
요청이 유효한지 여부를 이해하려면 다른 파트너가 보고한 일반적인 문제 목록을 검토합니다.
문제 1: 파트너 에이전트에 대한 MFA를 구현하는 데 더 많은 시간이 필요한 파트너
파트너가 파트너에게 위임된 관리 권한을 사용하여 고객 리소스를 관리하기 위해 Microsoft Online Services 포털에 액세스해야 하는 파트너 에이전트에 대해 MFA 구현을 시작하지 않았거나 아직 진행 중입니다. 파트너가 MFA 구현을 완료하는 데 더 많은 시간이 필요합니다. 이 문제는 기술 예외에 대한 타당한 이유인가요?
답변: 아니요. 파트너는 중단을 방지하기 위해 사용자가 MFA를 구현하도록 계획해야 합니다.
참고 항목
파트너가 파트너 에이전트에 대해 MFA를 구현하지 않았더라도 파트너 에이전트는 고객 테넌트에 로그인하는 동안 메시지가 표시될 때 MFA 등록 및 MFA 확인을 완료할 수 있는 경우 파트너 위임 관리 권한을 사용하여 Microsoft Online Services 포털에 계속 액세스할 수 있습니다. MFA 등록을 완료하더라도 사용자가 MFA를 사용하도록 자동으로 설정되지 않습니다.
문제 2: 파트너는 고객을 관리하기 위해 액세스할 필요가 없으므로 MFA를 구현하지 않았습니다.
파트너에는 파트너 위임 관리 권한을 사용하여 고객 리소스를 관리하기 위해 Microsoft Online Services 포털에 액세스할 필요가 없는 일부 사용자가 파트너 테넌트에 있습니다. 파트너는 이러한 사용자에 대해 MFA를 구현하고 있으며, 완료하는 데 더 많은 시간이 필요합니다. 이 문제는 기술 예외에 대한 타당한 이유인가요?
답변: 아니요. 이러한 사용자 계정은 파트너 위임 관리 권한을 사용하여 고객 리소스를 관리하지 않으므로 고객 테넌트에 로그인할 필요가 없습니다. 고객 테넌트에 로그인하는 동안 MFA 확인이 필요한 Microsoft Entra ID의 영향을 받지 않습니다. 모든 사용자는 고객 리소스를 관리하기 위해 파트너 센터 또는 고객 워크로드에 액세스하는 MFA가 있어야 합니다.
문제 3: 파트너가 사용자 서비스 계정에 대한 MFA를 구현하지 않았습니다.
파트너에는 파트너 테넌트의 일부 사용자 계정이 있으며, 이러한 계정은 디바이스에서 서비스 계정으로 사용됩니다. 이러한 낮은 권한의 계정은 파트너 위임 관리 권한을 사용하여 고객 리소스를 관리하기 위해 파트너 센터 또는 Microsoft 온라인 서비스 포털에 액세스할 필요가 없습니다. 이것이 기술 예외의 유효한 이유인가요?
답변: 아니요. 이러한 사용자 계정은 파트너 위임 관리 권한을 사용하여 고객 리소스를 관리하지 않으므로 고객 테넌트에 로그인할 필요가 없습니다. 고객 테넌트에 로그인하는 동안 MFA 확인이 필요한 Microsoft Entra ID의 영향을 받지 않습니다. API 또는 포털에 앱+사용자 인증이 필요한 경우 모든 사용자가 인증에 MFA를 사용해야 합니다.
문제 4: 파트너가 Microsoft Authenticator 앱을 사용하여 MFA를 구현할 수 없습니다.
파트너는 직원이 개인 모바일 장치를 작업 영역으로 가져오는 것을 허용하지 않는 "클린 데스크" 정책을 가지고 있습니다. 개인 모바일 디바이스에 액세스할 수 없으면 직원은 Microsoft Entra 보안 기본값에서 지원하는 유일한 MFA 인증인 Microsoft Authenticator 앱을 설치할 수 없습니다. 이 문제는 기술 예외에 대한 타당한 이유인가요?
답변: 아니요. 파트너는 직원이 파트너 센터에 액세스할 때 MFA 확인을 계속 완료할 수 있도록 다음 대안을 고려해야 합니다.
- 파트너는 Microsoft Entra ID P1 또는 P2에 등록하거나 더 많은 확인 방법을 제공할 수 있는 Microsoft Entra ID와 호환되는 비 Microsoft MFA 솔루션을 사용할 수도 있습니다. 자세한 내용은 지원되는 인증 방법을 참조하세요.
문제 5: 레거시 인증 프로토콜 사용으로 인해 파트너가 MFA를 구현할 수 없습니다.
파트너에는 아직도 MFA와 호환되지 않는 레거시 인증 프로토콜을 사용하는 일부 파트너 에이전트가 있습니다. 예를 들어 사용자는 레거시 인증 프로토콜을 기반으로 하는 Outlook 2010을 여전히 사용하고 있습니다. 이러한 파트너 에이전트에 대해 MFA를 사용하도록 설정하면 레거시 인증 프로토콜의 사용이 중단됩니다. 이 문제는 기술 예외에 대한 타당한 이유인가요?
답변: 아니요. 파트너는 잠재적인 보안 영향으로 인해 레거시 인증 프로토콜을 사용하지 않는 것이 좋습니다. 이러한 프로토콜은 MFA 확인으로 보호할 수 없고 자격 증명 손상에 훨씬 취약하기 때문입니다. 레거시 인증을 더 이상 사용하지 말고 보안 기본값 또는 조건부 액세스를 사용하는 것이 좋습니다. 레거시 인증에서 벗어날 준비를 하려면 레거시 인증 통합 문서를 사용하여 로그인 및 레거시 인증을 차단하는 방법에 대한 지침을 검토합니다.
Outlook에 대한 레거시 인증을 지원하기 위한 최신 계획을 이해하려면 기본 인증 및 Exchange Online에 대한 게시물을 읽고 Exchange 팀 블로그에 따라 예정된 뉴스를 확인하세요.
문제 6: 파트너가 Microsoft Entra ID로 인식되지 않는 타사 MFA를 구현했습니다.
파트너는 Microsoft MFA가 아닌 솔루션을 사용하여 사용자를 위해 MFA를 구현했습니다. 그러나 파트너는 사용자 인증 중에 MFA 확인이 완료되었음을 Microsoft Entra ID로 릴레이하도록 타사 MFA 솔루션을 올바르게 구성할 수 없습니다. 이 문제는 기술 예외에 대한 타당한 이유인가요?
답변: 아니요, 파트너는 인증 중에 제공된 실제 자격 증명 유형을 반영하여 자격 증명 메서드 클레임("AMR"), 액세스 토큰 클레임 참조를 지원하는 Microsoft Entra ID와 호환되는 인증 공급자를 사용해야 Microsoft ID 플랫폼.
테넌트 보안 기준을 높이기 위해 Microsoft Entra ID와 호환되는 MFA를 즉시 구현하는 것이 좋습니다.