오류 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 계정 만들기

디렉터리를 만들려는 경우 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: 잘못된 엔드포인트 사용(개인 및 조직 계정)

앱 등록의 지원되는 계정 유형이 다음 값 중 하나로 설정된 경우 인증 호출은 선택 항목과 일치하는 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합니다. 두 경우 모두 사용자가 애플리케이션에 로그인하도록 리디렉션됩니다. 경우에 따라 사용자가 사용하려는 세션과 다른 개인 계정 사용하는 활성 세션이 이미 있을 수 있습니다. 또는 개인 게스트 계정을 사용하려고 했지만(또는 그 반대의 경우도 마찬가지임) 조직 계정을 사용하는 세션이 있습니다.

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

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

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

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

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

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

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

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

애플리케이션이 사용자 할당이 필요한 엔터프라이즈 애플리케이션인 경우 사용자가 애플리케이션에 대한 액세스 권한이 할당된 허용된 사용자 목록에 없는 경우 오류가 AADSTS50020 발생합니다. 엔터프라이즈 애플리케이션에 사용자 할당이 필요한지 확인하려면 다음을 수행합니다.

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

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

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

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

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

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

• 애플리케이션에 대한 사용자 액세스를 개별적으로 할당하려면 엔터프라이즈 애플리케이션에 사용자 계정 할당을 참조하세요.

• 할당된 그룹 또는 동적 그룹의 구성원인 경우 사용자를 할당하려면 애플리케이션에 대한 액세스 관리를 참조하세요.

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

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

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

테넌트별 엔드포인트(https://login.microsoftonline.com/<TenantIDOrName>) 또는 조직의 엔드포인트를 사용합니다. 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 Graph PowerShell로 마이그레이션하여 Microsoft Entra ID(이전의 Azure AD)와 상호 작용하는 것이 좋습니다. 일반적인 마이그레이션 관련 질문은 마이그레이션 FAQ를 참조하세요. 참고 항목: MSOnline 버전 1.0.x는 2024년 6월 30일 이후 중단될 수 있습니다.

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

참고 항목

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

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

1. 홈 테넌트에서 PowerShell cmdlet을 LiveID Get-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 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.