Microsoft Azure AD에서 AADSTS50034 오류 해결 방법: 사용자가 존재하지 않음

By Mirko Peters · 2026-04-21

Microsoft Azure AD의 AADSTS50034 오류는 간단히 말해 “사용자가 존재하지 않음”을 뜻합니다. Microsoft 365, Azure 또는 관련 클라우드 서비스에 로그인하려는 사용자가 이 코드를 받으면, Azure Active Directory가 입력한 사용자 이름과 일치하는 계정을 찾지 못한 것입니다. 이 메시지는 사용자가 퇴사하거나 계정이 삭제된 뒤, 또는 로그인이나 계정 동기화 과정에서 오타나 실수가 있을 때 자주 나타납니다…

Automatically translated with AI from the original post. Read the English original

Cover: Fix Azure Governance Before Your Next Cloud Audit

Microsoft Azure AD에서 AADSTS50034 오류는 간단히 말해 “사용자가 존재하지 않음”을 뜻합니다. Microsoft 365, Azure 또는 관련 클라우드 서비스에 로그인하려는 사용자가 이 코드를 받으면, Azure Active Directory가 입력된 사용자 이름과 일치하는 계정을 찾지 못한 것입니다. 이 메시지는 사용자가 퇴사하거나 계정이 삭제된 뒤, 또는 로그인이나 계정 동기화 과정에서 오타나 실수가 있을 때 자주 나타납니다.

이 오류를 해결하는 것은 단순히 거슬리는 메시지를 없애는 일이 아닙니다. 원활한 클라우드 액세스, 사용자 생산성, 그리고 강력한 보안을 위해 매우 중요합니다. AADSTS50034는 정상적인 사용자가 업무를 수행하지 못하게 할 수 있으며, 계정 수명 주기, 디렉터리 구성 또는 테넌트 액세스에 더 깊은 문제가 있다는 신호일 수 있습니다. 이 가이드에서는 이 오류가 발생하는 정확한 이유, 유사한 문제와의 관계, 그리고 이를 해결하거나 더 중요하게는 향후 Microsoft 환경에서 AADSTS 관련 문제가 생기지 않도록 예방하는 단계를 자세히 설명합니다.

AADSTS50034 및 관련 Azure AD 인증 오류 이해하기

AADSTS50034는 Azure Active Directory의 사용자 조회 과정의 핵심에 있습니다. “사용자가 존재하지 않음” 메시지가 표시되면, 실제로는 Azure AD가 사용자 이름이나 자격 증명을 디렉터리와 대조했지만 일치하는 항목을 찾지 못한 상황입니다. 이는 사용자가 처음부터 존재하지 않았거나, 삭제되었거나, 애초에 동기화 또는 프로비저닝되지 않았음을 의미할 수 있습니다.

하지만 Microsoft 클라우드의 인증은 좀처럼 단순하지 않으며, 여러 오류 코드가 한꺼번에 나타나 명확함보다 혼란을 더하기도 합니다. 관리자는 AADSTS50034 외에도 AADSTS50020, AADSTS50126 같은 다른 로그인 오류를 자주 마주칩니다. 이 오류들은 모두 사용자 존재 여부와 ID를 중심으로 하지만, 각각 미묘하게 다른 의미를 가지고 있습니다. 그 결과 문제 해결은 범인을 찾는 추리극처럼 변하고, 각 오류는 테넌트 불일치, 암호 문제, 누락된 사용자 개체 등 서로 다른 단서를 가리키게 됩니다.

Microsoft 365나 Azure를 지원하는 모든 담당자에게 이 코드들을 이해하는 것은 필수입니다. 사용자 누락, 잘못된 암호, 잘못된 테넌트 사이의 경계는 모호하며, 이를 구분할 수 있으면 문제를 더 빠르고 자신 있게 해결할 수 있습니다. 기술적인 해결 방법으로 들어가기 전에, Azure AD가 ID를 확인하고 오류를 해석하며 이 코드들이 안전하고 안정적인 액세스를 이루는 과정에서 어떻게 연결되는지 전체적인 그림을 보는 것이 중요합니다. 이제 AADSTS50034가 발생하는 원인과 다른 일반적인 사용자 로그인 오류와 어떻게 비교되는지 살펴보겠습니다.

Microsoft Azure에서 AADSTS50034 오류의 원인과 해결 방법

AADSTS50034 오류는 로그인 중 Azure AD가 일치하는 사용자 개체를 찾지 못할 때 나타납니다. 이름 그대로 단순합니다. 사용자가 디렉터리에 없으면 액세스가 거부됩니다. 다만 그 원인은 이메일 주소의 오타처럼 단순한 것부터 삭제, 동기화 실패, 테넌트 불일치처럼 더 숨어 있는 문제까지 다양합니다.

가장 흔한 원인은 사용자 이름 오타, 최근 삭제되었지만 여전히 로그인을 시도하는 사용자, 또는 온-프레미스 Active Directory에서 동기화되지 않은 계정입니다. 또 다른 원인은 사용자가 잘못된 테넌트에 액세스하려는 경우입니다. 여러 조직에 액세스 권한이 있거나 게스트 초대 프로비저닝이 끝나지 않았을 수 있습니다. 더 혼란스럽게도, B2B 사용자 생성이 지연되었거나 페더레이션 중 이메일과 UPN이 일치하지 않으면 AADSTS50034가 발생합니다.

이 오류를 해결하려면 먼저 사용자 이름에 오타가 없는지 다시 확인하세요. Azure Portal에서 대상 테넌트의 사용자 메뉴 아래에 해당 사용자가 있는지 확인하고, 사용자가 삭제되었다면 복원하거나 게스트 액세스의 경우 다시 초대해야 할 수 있습니다. 하이브리드 환경에서는 온-프레미스 계정이 활성 상태이고 Azure AD와 정상적으로 동기화되고 있는지 확인하세요. 마지막으로 로그인이 올바른 테넌트에서 시도되고 있는지, 그리고 사용자 유형(‘구성원’ 또는 ‘게스트’)이 계정의 역할과 일치하는지 항상 확인하세요. 이런 근본 원인을 해결하면 AADSTS50034가 해소되고 환경 전반의 ID 안정성도 향상됩니다.

Azure AD 사용자 오류 비교: AADSTS50020 대 AADSTS50126

AADSTS50020과 AADSTS50126은 종종 AADSTS50034와 혼동되지만, 조금씩 다른 로그인 문제를 나타냅니다. AADSTS50020은 사용자가 Azure AD 어딘가에는 존재하지만 접근하려는 테넌트에는 없다는 뜻입니다. 올바른 자격 증명을 가지고 잘못된 조직이나 테넌트에 로그인할 때 자주 발생합니다.

반면 AADSTS50126은 잘못된 자격 증명을 가리킵니다. 유효한 사용자 이름이지만 비밀번호가 틀린 경우입니다. AADSTS50034가 “당신은 누구입니까?”라고 묻는다면, 다른 코드들은 “여기에 없습니다”(50020) 또는 “그것은 당신의 비밀번호가 아닙니다”(50126)라고 말하는 셈입니다. 이러한 차이를 빠르게 진단하면 관리자가 문제가 로그인 정보, 테넌트, 디렉터리 설정 중 어디에 있는지 신속하게 좁혀 나갈 수 있습니다.

Azure AD 액세스 문제를 해결하기 위한 테넌트 및 디렉터리 문제 해결

Azure AD 액세스 문제 대부분은 테넌트 선택, 디렉터리 구성 또는 정책 적용으로 귀결됩니다. 특히 여러 Azure 테넌트나 B2B(Business-to-Business) 구성을 사용하는 엔터프라이즈 환경에서는 사용자가 잘못된 위치에서 잘못된 시점에 작업하고 있다는 이유만으로 오류가 발생하는 경우가 많습니다. 사용자가 실수로 다른 테넌트에 로그인하거나, 정상적인 로그인이 정책에 의해 차단되는 것도 드문 일이 아닙니다.

Azure AD의 테넌트 및 디렉터리 구조는 보안 경계 역할을 합니다. 사용자 액세스, 앱 등록, 리소스 권한은 모두 현재 테넌트의 컨텍스트에 연결되어 있습니다. 사용자나 게스트가 잘못된 경로로 로그인을 시도하면 시스템이 까다롭게 구는 것이 아니라, 실제로는 해당 사용자를 찾거나 승인할 방법이 없습니다. 이런 경우 AADSTS50034, AADSTS50105 또는 AADSTS53003과 같은 오류가 발생합니다.

이런 상황을 해결하려면 사용자가 테넌트 간에 어떻게 라우팅되는지, 멤버인지 게스트인지, 디렉터리 불일치가 있는지를 면밀히 살펴봐야 합니다. 복잡한 조건부 액세스나 엄격하게 잠긴 테넌트를 운영하는 조직에서는 설정이 올바르게 되어 있어 보여도 관리자 정책 때문에 액세스가 거부될 수 있습니다. 거버넌스와 정책이 액세스를 좌우할 수 있는 방법에 대해 더 알고 싶다면 Azure 엔터프라이즈 거버넌스 자료를 참고하세요. 계속 쌓이는 “왜 이 사용자를 찾을 수 없습니까?” 오류를 다루기 전에, 디렉터리와 테넌트 경계를 이해하는 것이 무엇보다 중요합니다.

Azure AD에서 올바른 테넌트에 액세스하고 있는지 확인하는 방법

테넌트 컨텍스트 확인: Azure 또는 Microsoft 365 포털에 표시된 테넌트를 항상 확인하세요. 오른쪽 상단의 표시 이름이 현재 활성 조직을 나타냅니다.
디렉터리 전환: 둘 이상의 테넌트에 속해 있다면, 로그인을 다시 시도하기 전에 포털의 디렉터리 전환기를 사용해 조직 간에 이동하세요.
게스트/멤버 상태 확인: 액세스하려는 조직에서 멤버로 등록되어 있는지 게스트로 등록되어 있는지 확인하세요. 역할이 잘못되어 있으면 액세스가 차단되는 경우가 많습니다.
초대 검토: 게스트 사용자의 경우 초대가 수락되었는지, 그리고 게스트 계정이 올바른 Azure AD 디렉터리에 프로비전되었는지 확인하세요.

AADSTS50105 및 AADSTS53003 오류 해결: 디렉터리 액세스 차단 또는 거부

정책 또는 액세스 차단(AADSTS50105): 관리자가 특정 사용자의 리소스 액세스를 막는 액세스 정책, 그룹 또는 제한을 설정했을 수 있습니다. 관리 센터에서 그룹 할당과 역할 자격을 확인하세요.
조건부 액세스 또는 외부 사용자 제한(AADSTS53003): 디바이스 규정 준수, 위치 또는 위험 정책이 적용되면 로그인이 차단될 수 있습니다. Microsoft Entra ID에서 모든 조건부 액세스 정책을 검토하고, 디바이스 등록과 보안 요구 사항이 충족되었는지 확인하세요.
게스트 만료 또는 액세스 검토: 게스트나 외부 사용자는 액세스 검토 또는 자동 만료 후 액세스 권한을 잃을 수 있습니다. 예기치 않은 거부를 관리하고 최소화하려면 정기적으로 게스트 계정 감사와 수명 주기 검토를 수행하세요.
관리자 개입: 더 광범위한 차단이 의심된다면 관리자에게 연락해 제한을 해제하거나 액세스를 다시 프로비전하도록 요청하세요. 이때 게스트 수명 주기 거버넌스 가이드에 나온 모범 사례를 따르세요.

AADSTS50034를 방지하기 위한 온-프레미스 AD 동기화 및 계정 유형 확인

하이브리드 ID 환경을 운영하는 조직은 동기화 및 계정 분류 문제 때문에 종종 AADSTS50034 오류에 빠집니다. 온-프레미스 Active Directory가 Azure AD와 연결되어 있을 때 사용자 계정 동기화에 문제가 생기면, 계정이 로컬에 존재하는 것처럼 보여도 사용자가 로그인하지 못할 수 있습니다.

주요 원인 중 하나는 온-프레미스 AD와 Azure AD 사이에서 사용자가 제대로 동기화되지 않는 것입니다. 동기화 프로세스가 실패했거나, 사용자 개체가 사용 안 함 상태이거나, 변경 내용이 아직 클라우드에 복제되지 않았을 수 있습니다. 이런 문제는 사용자가 로그인을 시도하여 "user does not exist" 메시지를 보기 전까지는 드러나지 않는 경우가 많습니다.

사용자가 잘못 분류된 경우에는 상황이 더 복잡해집니다. "멤버"여야 할 사용자가 "게스트"로 분류되거나, 그 반대인 경우입니다. Microsoft Entra ID(이전 명칭 Azure AD)는 인증 중에 이 상태를 확인합니다. 외부 게스트가 잘못 구성되었거나 동기화된 멤버 사용자가 게스트로 표시되면, Azure AD가 어디에서 계정을 찾아야 할지 알 수 없게 되어 AADSTS50034 오류가 발생합니다. 하이브리드, 멀티 클라우드 또는 게스트가 많은 환경을 관리하는 관리자라면 이러한 세부 사항을 반드시 이해해야 합니다. 다음으로, Microsoft의 클라우드 디렉터리에서 동기화를 올바르게 유지하고 계정 유형을 정확히 설정하는 실습 방법을 살펴보겠습니다.

디렉터리 동기화 문제를 피하기 위해 온-프레미스 AD를 Azure AD와 동기화하기

동기화 상태 확인: Azure AD Connect 대시보드에서 마지막 동기화 시간과 오류 보고서를 검토하십시오. 실패가 보이면 다음 단계로 진행하기 전에 먼저 해결하십시오.
클라우드에서 사용자 확인: Azure AD 포털을 사용하여 사용자가 존재하는지, 그리고 온-프레미스 디렉터리의 정보와 일치하는지 확인하십시오.
동기화 오류 해결: 디렉터리 동기화를 막는 중복 프록시, 사용자 개체 충돌, 잘못 구성된 특성 같은 일반적인 문제를 해결하십시오.
수동 동기화 실행: 사용자를 방금 만들었거나 수정했다면 수동 동기화를 실행하여 온-프레미스 디렉터리와 클라우드 디렉터리 간 업데이트를 강제로 적용하십시오.

계정 유형 확인 및 멤버와 게스트의 AADSTS50034 오류 수정

사용자 유형 검토: Microsoft Entra ID에서 사용자가 "멤버"로 표시되어 있는지 "게스트"로 표시되어 있는지 확인하십시오. 유형이 잘못되면 테넌트 리소스에 대한 로그인이 차단됩니다.
잘못된 분류 수정: Azure AD 사용자 관리 도구를 사용하여 잘못 등록된 게스트를 멤버로(또는 그 반대로) 변환하십시오.
UPN 및 이메일 확인: 사용자 계정 이름(UPN)이 의도한 계정과 일치하는지, 충돌을 일으키는 이메일 별칭 불일치가 없는지 확인하십시오.
외부 ID 감사: B2B 및 하이브리드 사용자의 경우 초대와 조직 간 관계가 올바르게 설정되어 있고 활성 상태인지 확인하십시오.

Microsoft 365에서 서비스 및 앱 인증이 AADSTS 오류를 일으킬 때

AADSTS 오류는 일반 사용자 로그인에만 나타나는 것이 아닙니다. 앱과 서비스가 Microsoft 365에 연결할 때도 나타납니다. 때로는 서비스 자체가 문제입니다. 앱 등록이 잘못 작동하거나, 클라이언트 비밀이 만료되거나, 등록이 삭제되기도 합니다. Exchange Online, SharePoint, 그리고 수많은 타사 통합 기능은 Azure AD의 올바른 구성에 의존하므로, 작은 변경 하나로도 모든 것이 차단될 수 있습니다.

애플리케이션 등록은 클라이언트의 인증 설정과 일치해야 합니다. 누락되었거나 취소된 비밀, 잘못된 앱 ID, 사용 안 함 상태의 앱, 일치하지 않는 리디렉션 URI 등 어떤 차이라도 AADSTS700016("app not found") 또는 AADSTS7000218("invalid client secret") 같은 오류를 일으킬 수 있습니다. 이런 문제는 테넌트 마이그레이션, PowerShell 자동화, 또는 새 앱을 빠르게 구성할 때 IT 관리자를 자주 곤란하게 합니다.

게다가 엄격한 조건부 액세스 정책과 강력한 테넌트 제한은 인증 정보가 올바른 것처럼 보여도 앱을 차단할 수 있습니다. 이러한 오류를 해석하고, 앱 설정, 동의 부여, OAuth 취약점 중 무엇이 원인인지 추적하는 방법을 아는 것은 업무 중단을 피하는 데 필수적입니다. OAuth 동의나 앱 기반 보안 공백이 걱정된다면 Entra ID OAuth 동의에서 동의 공격을 예방하는 방법을 확인해 보십시오.

AADSTS700016 및 AADSTS7000218 수정: 애플리케이션을 찾을 수 없음 및 잘못된 클라이언트 오류

앱 등록 확인: 애플리케이션이 Azure AD 테넌트에 등록되어 있는지 확인하십시오. 인증 요청의 클라이언트/앱 ID를 등록된 값과 비교하십시오.
클라이언트 비밀 또는 인증서 검토: 기밀 클라이언트의 경우 비밀 또는 인증서가 유효하고 활성 상태이며 앱 등록 설정과 일치하는지 확인하십시오.
리디렉션 URI 검증: 응답은 앱 등록에 나열된 리디렉션 URI를 사용해야 합니다. 일치하지 않으면 로그인이 실패합니다.
테넌트와 권한 확인: 앱은 올바른 테넌트에서 사용하도록 설정되어 있어야 하며, 위임된 권한 또는 앱 전용 권한이 사용 사례와 맞아야 합니다.

Microsoft 365 서비스에서 AADSTS90002 및 AADSTS900144 해결

테넌트를 찾을 수 없음(AADSTS90002): 대상 테넌트가 없거나 삭제되었을 때 주로 발생합니다. 로그인 또는 앱 연결 문자열의 도메인 이름을 다시 확인하고 테넌트가 활성 상태인지 확인하십시오.
정책 또는 디렉터리 위반(AADSTS900144): 조건부 액세스나 테넌트 전체 정책이 더 엄격한 제어를 적용하고 있을 수 있습니다. 안정성을 위해 포괄적인 적용 범위를 우선하고 임시 예외를 최소화하도록 정책을 검토하고 조정하십시오. 최적의 정책 설계에 대해서는 이 조건부 액세스 모범 사례 가이드를 참조하십시오.
위임된 액세스 문제: 만료된 OAuth 동의나 앱 등록에 누락된 권한이 있으면 로그인 흐름이 중단될 수 있으므로, 동의 권한 부여와 만료 날짜를 정기적으로 검토하십시오.
서비스 또는 사용자 삭제: 필요한 서비스 주체와 사용자가 올바른 테넌트에 있는지 확인하십시오. 최근에 삭제되었다면 필요에 따라 복원하거나 다시 등록하십시오.

다단계 인증 요구 사항과 조건부 액세스 정책

사용자가 올바른 계정과 자격 증명을 가지고 있더라도 보안 정책이 충족되지 않으면 Azure AD는 여전히 액세스를 차단할 수 있습니다. 이때 다단계 인증(MFA)과 디바이스 규정 준수 요구 사항이 큰 역할을 합니다. 조직은 이를 사용해 위험을 줄입니다. 로그인을 완료하기 전에 추가 확인이나 디바이스 상태 검사를 요구하는 방식입니다.

사용자가 MFA를 건너뛰거나 관리되지 않는 디바이스 또는 규정을 준수하지 않는 디바이스에서 로그인을 시도하면 AADSTS50076 및 AADSTS50079와 같은 오류가 발생합니다. 특히 정책이 최근에 변경되었거나 사용자가 처음으로 새 디바이스를 사용하는 경우 이러한 오류가 당황스러울 수 있습니다. 새로운 조건이 적용되고 있다는 사실은 Azure AD가 연결을 거부하기 전까지는 미리 알기 어려운 경우가 많습니다.

관리자에게 조건부 액세스의 구성과 유지 관리는 한 번 설정하고 끝나는 작업이 아니라 지속적으로 반복해야 하는 과정입니다. 사용자가 우회 방법을 찾고, 정책이 수정되고, 디바이스가 교체되면서 설정이 점차 어긋나게 됩니다. 확장 가능하고 실제로 적용되는 ID 보안을 深이 있게 이해하고 싶다면, 이 조건부 액세스 거버넌스 팟캐스트에서 불편을 최소화하면서 통제를 강하게 유지하는 방법을 다룹니다. 다음으로는 일반적인 MFA 및 규정 준수 관련 로그인 차단을 해결하기 위한 실제 문제 해결 단계를 살펴보겠습니다.

AADSTS50076 및 AADSTS50079 해결: 다단계 인증 및 디바이스 규정 준수 필요

MFA 설정: 메시지가 표시되면 MFA가 사용 설정되어 구성되어 있는지 확인하십시오. 조직의 설정에 따라 모바일 앱, 전화 통화 또는 SMS를 사용합니다.
디바이스 등록: 디바이스 규정 준수를 위해 디바이스가 Intune 또는 Endpoint Manager와 같이 조직에서 사용하는 디바이스 관리 솔루션에 등록되어 있는지 확인하십시오.
정책 검토: 조건부 액세스 정책의 할당과 범위를 확인하십시오. 정당한 사용자가 지나치게 제한적인 규칙 때문에 차단되고 있다면 조정하십시오.
관리자에게 문의: 설정이 올바른데도 오류가 계속되면 관리자에게 디바이스 또는 세션 규정 준수 상태를 확인하고 최근 변경 사항에 대한 정책 로그를 검토해 달라고 요청하십시오.

전문가 팁: Microsoft Entra B2B 환경에서 "User does not exist" 오류 방지

“user does not exist” 오류를 해결하는 것도 중요하지만, 이를 미리 방지하는 것은 또 다른 문제입니다. 특히 Microsoft Entra B2B 및 교차 테넌트 환경에서는 더욱 그렇습니다. 조직 간 협업이 늘어나면서 사용자 프로비저닝 지연, 실체가 없는 게스트 계정, 사용자 속성 불일치 등으로 인해 AADSTS50034가 발생할 가능성이 높아집니다. 게스트 사용자 생성, 계정 제거, 하이브리드 ID 동기화 과정은 항상 즉시 완료되거나 완벽하게 안정적이지는 않습니다.

수명 주기 관리를 철저히 하는 것이 중요합니다. 초대 지연, 외부 동기화 실패, 이메일 별칭 불일치는 온보딩이 끝난 것처럼 보여도 게스트 사용자에게 AADSTS50034를 유발할 수 있습니다. 비활성, 규정 준수, 또는 관리자의 수동 정리로 삭제된 계정은 일시 삭제 상태로 남아 로그인이나 테넌트 마이그레이션 중에 문제를 일으킬 수 있습니다. 이러한 함정을 피하려면 이 상세한 게스트 관리 가이드에서 설명하는 것처럼 정기적인 액세스 검토와 체계적인 수명 주기 규칙을 적용하는 것이 매우 중요합니다.

서비스 주체(service principal) 인증으로 앱이나 서비스를 옮기는 관리자는 나름의 복잡한 문제를 겪습니다. 사용자 컨텍스트가 없거나 권한이 잘못 구성되면 AADSTS50034 오류가 나타나는데, 실제로 근본 원인은 사용자가 없어서인 경우가 드뭅니다. B2B 프로비저닝, 메일/UPN 일치, 앱 마이그레이션 설정을 미리 점검해 두면 교차 테넌트 프로젝트와 복잡한 자동화 흐름에 필요한 디렉터리 안정성을 확보할 수 있습니다. 지속적으로 나타나는 AADSTS50034 상황을 모니터링하고, 진단하고, 예방하는 구체적인 방법을 살펴보겠습니다.

게스트 사용자 프로비저닝, 계정 삭제, 그리고 AADSTS50034를 유발하는 UPN 불일치

프로비저닝 지연: 게스트가 초대를 수락한 후 계정이 Azure AD에 완전히 나타나기까지 지연이 있을 수 있습니다. 문제를 더 파고들기 전에 로그인 로그를 모니터링하고 계정 생성 시점을 확인하십시오.
자동 또는 수동 삭제: 게스트 및 외부 사용자는 비활성 상태로 인해 자동 삭제되거나 관리자가 수동으로 제거할 수 있습니다. 일시 삭제된(soft-deleted) 계정은 인증할 수 없으며 AADSTS50034를 발생시킵니다. 이 수명 주기 관리 가이드에 설명된 대로 수명 주기 정책을 자주 검토하십시오.
이메일/UPN 불일치: 이메일 별칭이나 일치하지 않는 사용자 프린시펄 이름(UPN)으로 로그인하는 사용자는 Azure AD에서 찾지 못할 수 있습니다. UPN과 기본 메일 주소가 디렉터리에 등록된 값과 일치하도록 하여 해결하십시오.
SMTP 일치 충돌: 테넌트 간에 중복된 이메일 주소가 있으면 ID 확인이 실패합니다. 조회 오류를 피하려면 명시적 초대를 사용하고, 각 테넌트 안에서 이메일 주소가 고유한지 확인하십시오.

서비스 주체 및 앱 전용 인증: 마이그레이션에서 오해를 부르는 AADSTS50034 오류 피하기

앱 전용 인증 컨텍스트: 서비스 주체를 사용하는 마이그레이션 도구나 자동화 스크립트는 앱 권한이 잘못 구성되었거나 스크립트가 없는 사용자 개체를 참조하는 경우 AADSTS50034를 받을 수 있습니다. 인증 과정에 사용자가 관여하지 않더라도 발생할 수 있습니다. 마이그레이션을 실행하기 전에 항상 포털에서 역할과 앱 범위를 검증하십시오.
위임된 범위와 만료된 동의: 위임된 권한이 필요한데 동의가 만료되었거나 없으면 도구가 AADSTS50034를 잘못 보고할 수 있습니다. 특히 테넌트 마이그레이션이나 앱 재승인 주기 이후에는 동의를 다시 부여하거나 검토하십시오.
UPN 및 개체 ID 정확성: 스크립트를 작성할 때는 참조 실패를 피하기 위해 테넌트에서 활성 상태인 사용자 또는 서비스 주체와 일치하는 정확하고 최신의 UPN과 개체 ID를 사용하십시오.
오류 진단: 사용자가 없는지만 확인하지 말고, Graph API 또는 PowerShell 로그에서 권한 및 개체 참조 오류를 확인하여 인증 실패의 실제 원인을 찾아내십시오.