다음을 통해 공유


오류 AADSTS50020 - ID 공급자의 사용자 계정이 테넌트에서 존재하지 않음

이 문서는 IdP(ID 공급자)의 게스트 사용자가 Microsoft Entra ID 리소스 테넌트에서 로그인할 수 없는 경우 반환되는 오류 코드를 AADSTS50020 해결하는 데 도움이 됩니다.

증상

게스트 사용자가 리소스 테넌트에서 애플리케이션 또는 리소스에 액세스하려고 하면 로그인이 실패하고 다음 오류 메시지가 표시됩니다.

AADSTS50020: ID 공급자 {IdentityProviderURL}의 사용자 계정 'user@domain.com'이(가) 테넌트 {ResourceTenantName}에 없습니다.

관리자가 홈 테넌트에서 로그인 로그를 검토하면 "90072" 오류 코드 항목은 로그인 실패를 나타냅니다. 오류 메시지는 다음과 같이 표시됩니다.

ID 공급자 {idp}의 사용자 계정 {email}이(가) 테넌트 {tenant}에 없으며 해당 테넌트에서 애플리케이션 {appId}({appName})에 액세스할 수 없습니다. 먼저 테넌트에서 외부 사용자로 계정을 추가해야 합니다. 다른 Microsoft Entra 사용자 계정으로 로그아웃하고 다시 로그인합니다.

원인 1: 사용자가 개인 Microsoft 계정을 사용하여 Microsoft Entra 관리 센터 로그인

개인 Microsoft 계정(Outlook, Hotmail 또는 OneDrive)을 사용하여 Microsoft Entra 관리 센터 로그인하려고 하면 기본적으로 Microsoft 서비스 테넌트에서 연결됩니다. 기본 테넌트 내에는 작업을 수행하기 위한 연결된 디렉터리가 없습니다. 이 동작은 예상한 것입니다.

이전 환경에서 디렉터리(예: UserNamehotmail735.onmicrosoft.com)가 만들어지고 개인 계정 연결되며 디렉터리에서 사용자 계정 만들기와 같은 작업을 수행할 수 있습니다. 이제 동작이 변경되었습니다.

솔루션: 새 테넌트를 사용하여 Azure 계정 Create

디렉터리를 만드는 것을 목표로 하는 경우 Azure 계정 및 새 테넌트를 만들어야 합니다.

  1. 로 이동한 https://azure.microsoft.com/en-us/free/다음 , 무료 시작을 선택합니다.
  2. 지침에 따라 Azure 계정을 만듭니다.
  3. 테넌트는 Azure 계정과 함께 생성되며 자동으로 전역 관리자로 지정됩니다. 이렇게 하면 이 테넌트 내의 모든 옵션에 대한 모든 액세스 권한이 부여됩니다.

원인 2: 지원되지 않는 계정 유형 사용(다중 테넌트 및 개인 계정)

앱 등록이 단일 테넌트 계정 유형으로 설정된 경우 다른 디렉터리 또는 ID 공급자의 사용자는 해당 애플리케이션에 로그인할 수 없습니다.

해결 방법: 앱 등록 매니페스트에서 로그인 대상 그룹 설정 변경

앱 등록이 단일 테넌트 계정 유형이 아닌지 확인하려면 다음 단계를 수행합니다.

  1. Azure Portal앱 등록 검색하여 선택합니다.

  2. 앱 등록의 이름을 선택합니다.

  3. 사이드바에서 매니페스트를 선택합니다.

  4. JSON 코드에서 signInAudience 설정을 찾습니다.

  5. 설정에 다음 값 중 하나가 포함되어 있는지 확인합니다.

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    signInAudience 설정에 이러한 값 중 하나가 없는 경우 올바른 계정 유형을 선택하여 앱 등록을 다시 만듭니다. 현재 매니페스트에서 signInAudience 를 변경할 수 없습니다.

애플리케이션을 등록하는 방법에 대한 자세한 내용은 빠른 시작: Microsoft ID 플랫폼 애플리케이션 등록을 참조하세요.

원인 3: 잘못된 엔드포인트(개인 및 organization 계정)를 사용했습니다.

앱 등록의 지원되는 계정 유형이 다음 값 중 하나로 설정된 경우 인증 호출은 선택 항목과 일치하는 URL을 대상으로 해야 합니다.

  • 모든 조직 디렉터리의 계정(모든 Microsoft Entra 디렉터리 - 다중 테넌트)

  • 모든 조직 디렉터리(모든 Microsoft Entra 디렉터리 - 다중 테넌트) 및 개인 Microsoft 계정(예: Skype, Xbox)의 계정

  • 개인 Microsoft 계정만

를 사용하는 https://login.microsoftonline.com/<YourTenantNameOrID>경우 다른 조직의 사용자는 애플리케이션에 액세스할 수 없습니다. 요청에 지정된 테넌트에서 이러한 사용자를 게스트로 추가해야 합니다. 이 경우 인증은 테넌트에서만 실행되어야 합니다. 이 시나리오에서는 사용자가 다른 테넌트 또는 ID 공급자와의 페더레이션을 사용하여 로그인해야 하는 경우 로그인 오류가 발생합니다.

해결 방법: 올바른 로그인 URL 사용

다음 표에 나열된 대로 특정 애플리케이션 유형에 해당하는 로그인 URL을 사용합니다.

애플리케이션 유형 로그인 URL
다중 테넌트 애플리케이션 https://login.microsoftonline.com/organizations
다중 테넌트 및 개인 계정 https://login.microsoftonline.com/common
개인 계정만 https://login.microsoftonline.com/consumers

애플리케이션 코드에서 설정에 이 URL 값을 적용합니다 Authority . 에 대한 Authority자세한 내용은 애플리케이션 구성 옵션 Microsoft ID 플랫폼 참조하세요.

원인 4: 잘못된 테넌트 로그인

사용자가 애플리케이션에 액세스하려고 하면 애플리케이션에 대한 직접 링크를 보내거나 를 통해 https://myapps.microsoft.com액세스 권한을 얻으려고 시도합니다. 두 경우 모두 사용자는 애플리케이션에 로그인하도록 리디렉션됩니다. 경우에 따라 사용자에게 사용하려는 세션과 다른 개인 계정 사용하는 활성 세션이 이미 있을 수 있습니다. 또는 개인 게스트 계정을 사용하거나 그 반대의 경우도 마찬가지이지만 organization 계정을 사용하는 세션이 있습니다.

이 시나리오가 문제인지 확인하려면 오류 메시지에서 User accountIdentity provider 값을 찾습니다. 이러한 값이 예상 조합과 일치하는가요? 예를 들어 사용자가 organization 계정을 사용하여 홈 테넌트 대신 테넌트로 로그인했나요? 또는 사용자가 이미 초대된 개인 계정 다른 개인 계정 사용하여 ID 공급자에 로그인 live.com 했습니까?

해결 방법: 로그아웃한 다음, 다른 브라우저 또는 프라이빗 브라우저 세션에서 다시 로그인합니다.

사용자에게 새 프라이빗 브라우저 세션을 열거나 사용자가 다른 브라우저에서 액세스하도록 지시합니다. 이 경우 사용자는 활성 세션에서 로그아웃한 다음 다시 로그인해야 합니다.

원인 5: 게스트 사용자가 초대되지 않음

로그인을 시도한 게스트 사용자가 테넌트에게 초대되지 않았습니다.

해결 방법: 게스트 사용자 초대

빠른 시작: Azure Portal 디렉터리에 게스트 사용자를 추가하여 게스트 사용자를 초대하는 단계를 수행해야 합니다.

원인 6: 앱에 사용자 할당 필요

애플리케이션이 사용자 할당이 필요한 엔터프라이즈 애플리케이션인 경우 사용자가 애플리케이션에 대한 액세스 권한이 할당된 허용된 사용자 목록에 없는 경우 오류가 AADSTS50020 발생합니다. 엔터프라이즈 애플리케이션에 사용자 할당이 필요한지 여부를 검사:

  1. Azure Portal엔터프라이즈 애플리케이션을 검색하여 선택합니다.

  2. 엔터프라이즈 애플리케이션을 선택합니다.

  3. 사이드바에서 속성을 선택합니다.

  4. 할당 필요 옵션이 예로 설정되어 있는지 확인합니다.

해결 방법: 개별적으로 또는 그룹의 일부로 사용자에게 액세스 권한 할당

다음 옵션 중 하나를 사용하여 사용자에게 액세스 권한을 할당합니다.

원인 7: 개인 계정에 리소스 소유자 암호 자격 증명 흐름을 사용하려고 했습니다.

사용자가 개인 계정에 ROPC(리소스 소유자 암호 자격 증명) 흐름을 사용하려고 하면 오류가 AADSTS50020 발생합니다. Microsoft ID 플랫폼 개인 계정이 아닌 Microsoft Entra 테넌트 내에서만 ROPC를 지원합니다.

해결 방법: 테넌트 또는 organization 관련된 엔드포인트 사용

테넌트별 엔드포인트(https://login.microsoftonline.com/<TenantIDOrName>) 또는 organization 엔드포인트를 사용합니다. Microsoft Entra 테넌트에서 초대된 개인 계정은 ROPC를 사용할 수 없습니다. 자세한 내용은 Microsoft ID 플랫폼 및 OAuth 2.0 리소스 소유자 암호 자격 증명을 참조하세요.

원인 8: 홈 테넌트 관리자가 이전에 삭제한 사용자 이름을 다시 만들었습니다.

리소스 테넌트에서 삭제된 게스트 사용자의 이름이 홈 테넌트 관리자에 의해 다시 만들어지면 오류가 AADSTS50020 발생할 수 있습니다. 리소스 테넌트의 게스트 사용자 계정이 홈 테넌트의 사용자 계정과 연결되어 있지 않은지 확인하려면 다음 옵션 중 하나를 사용합니다.

확인 옵션 1: 리소스 테넌트의 게스트 사용자가 홈 테넌트의 사용자 계정보다 오래된지 확인

첫 번째 확인 옵션은 리소스 테넌트의 게스트 사용자의 기간을 홈 테넌트의 사용자 계정과 비교하는 것입니다. Microsoft Graph 또는 MSOnline PowerShell을 사용하여 이 확인을 수행할 수 있습니다.

Microsoft Graph

다음과 같이 MS Graph API 요청을 실행하여 사용자 만들기 날짜를 검토합니다.

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

그런 다음, 리소스 테넌트에서 게스트 사용자의 생성 날짜를 홈 테넌트의 사용자 계정 생성 날짜와 검사. 홈 테넌트의 사용자 계정을 만들기 전에 게스트 사용자가 만들어졌는지 시나리오가 확인됩니다.

MSOnline PowerShell

참고

MSOnline PowerShell 모듈은 더 이상 사용되지 않음으로 설정됩니다. PowerShell Core와도 호환되지 않으므로 다음 명령을 실행할 수 있도록 호환되는 PowerShell 버전을 사용하고 있는지 확인합니다.

Get-MsolUser PowerShell cmdlet을 실행하여 다음과 같이 사용자 만들기 날짜를 검토합니다.

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

그런 다음, 리소스 테넌트에서 게스트 사용자의 생성 날짜를 홈 테넌트의 사용자 계정 생성 날짜와 검사. 홈 테넌트의 사용자 계정을 만들기 전에 게스트 사용자가 만들어졌는지 시나리오가 확인됩니다.

참고

Azure AD 및 MSOnline PowerShell 모듈은 2024년 3월 30일부터 더 이상 사용되지 않습니다. 자세한 내용은 사용 중단 업데이트를 참조하세요. 이 날짜 이후에는 이러한 모듈에 대한 지원이 Microsoft Graph PowerShell SDK 및 보안 수정에 대한 마이그레이션 지원으로 제한됩니다. 사용되지 않는 모듈은 2025년 3월 30일까지 계속 작동합니다.

Microsoft Entra ID(이전의 Azure AD)와 상호 작용하려면 Microsoft Graph PowerShell로 마이그레이션하는 것이 좋습니다. 일반적인 마이그레이션 질문은 마이그레이션 FAQ를 참조하세요. 참고: MSOnline 버전 1.0.x는 2024년 6월 30일 이후에 중단이 발생할 수 있습니다.

확인 옵션 2: 리소스 테넌트의 게스트 대체 보안 ID가 홈 테넌트의 사용자 순 ID와 다른지 확인

참고

MSOnline PowerShell 모듈은 더 이상 사용되지 않음으로 설정됩니다. PowerShell Core와도 호환되지 않으므로 다음 명령을 실행할 수 있도록 호환되는 PowerShell 버전을 사용하고 있는지 확인합니다.

게스트 사용자가 초대를 수락하면 사용자의 특성(사용자의 LiveID 고유 로그인 ID)이 특성 내에 AlternativeSecurityIdskey 저장됩니다. 사용자 계정이 삭제되고 홈 테넌트에서 생성되었으므로 홈 테넌트 NetID 에서 사용자에 대한 계정 값이 변경됩니다. NetID 다음과 같이 홈 테넌트의 사용자 계정 값을 리소스 테넌트의 게스트 계정 내에 AlternativeSecurityIds 저장된 키 값과 비교합니다.

  1. 홈 테넌트에서 PowerShell cmdlet을 LiveIDGet-MsolUser 사용하여 특성 값을 검색합니다.

    Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID
    
  2. 리소스 테넌트에서 내 AlternativeSecurityIds 특성의 key 값을 base64로 인코딩된 문자열로 변환합니다.

    [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
           ).AlternativeSecurityIds.key)
    
  3. 온라인 변환기(예: base64.guru)를 사용하여 base64로 인코딩된 문자열을 16진수 값으로 변환합니다.

  4. 1단계와 3단계의 값을 비교하여 서로 다른지 확인합니다. NetID 계정을 삭제하고 다시 만들 때 홈 테넌트에서 사용자 계정의 가 변경되었습니다.

해결 방법: 게스트 사용자 계정의 상환 상태 다시 설정

리소스 테넌트에서 게스트 사용자 계정의 상환 상태 다시 설정합니다. 그런 다음 게스트 사용자 개체를 삭제하지 않고도 유지한 다음 게스트 계정을 다시 만들 수 있습니다. Azure Portal, Azure PowerShell 또는 Microsoft Graph API 사용하여 상환 상태 다시 설정할 수 있습니다. 자세한 내용은 게스트 사용자에 대한 상환 상태 다시 설정을 참조하세요.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.