AADSTS50020, Потребителски акаунт от доставчик на самоличност не съществува в клиента

В тази статия ще обсъдим възможни корекции за разрешаване на AADSTS50020, Потребителски акаунт от доставчик на самоличност не съществува в клиент грешка. Тази грешка обикновено възниква, когато потребител гост от доставчик на идентичност (IdP) не може да влезе в наемател на ресурси в Azure Active Directory (Azure AD). Може да видите тази грешка в различни ситуации. Всяка ситуация изисква различен начин за отстраняване на проблема.

Пълното съобщение за грешка, което потребителят гост вижда, когато се опитва да получи достъп до приложение или ресурс в наемателя на ресурса, е:

AADSTS50020: Потребителски акаунт „ [имейл защитен] ’ от доставчик на идентичност {IdentityProviderURL} не съществува в клиент {ResourceTenantName}.

При преглед на регистрационните файлове на домашния наемател администраторът ще види следното съобщение за грешка:

слайдшоу на windows 10

Потребителски акаунт {email} от доставчик на идентичност {idp} не съществува в клиент {tenant} и няма достъп до приложението {appId}({appName}) в този клиент. Акаунтът първо трябва да бъде добавен като външен потребител в клиента. Излезте и влезте отново с различен потребителски акаунт в Azure Active Directory.

AADSTS50020, Потребителски акаунт от доставчик на самоличност не съществува в клиента

Решенията по-долу ще ви помогнат да коригирате AADSTS50020, Потребителски акаунт от доставчик на самоличност не съществува в клиент грешка.

1. Променете настройката на аудиторията за влизане в манифеста за регистрация на приложението
2. Използвайте правилния URL адрес за вход
3. Излезте, след което влезте отново от различен браузър или частна сесия на браузъра
4. Поканете потребителя гост
5. Задайте достъп на потребителите (ако е приложимо)
6. Използвайте крайна точка, която е специфична за клиента или организацията
7. Нулирайте състоянието на изкупуване на потребителския акаунт на гост

Нека да видим всички тези поправки в детайли.

1] Променете настройката на аудиторията за влизане в манифеста за регистрация на приложението

Една възможна причина за тази грешка е, когато наемател използва неподдържан тип акаунт. Например, ако за регистрацията на вашето приложение е зададен тип акаунт с един клиент, потребител от друг идентифициран доставчик не може да влезе в приложението.

За да коригирате грешката AADSTS50020 , променете настройката на аудиторията за влизане в манифеста за регистрация на приложението, както следва:

1. Отидете на Портал на Azure .
2. Изберете Регистрации на приложения .
3. Изберете името на регистрацията на вашето приложение.
4. Изберете Манифест , от страничната лента.
5. В JSON код , намерете настройката signInAudience.
6. Проверете настройката от една от следните стойности:

• • AzureAD и личен акаунт в Microsoft
  • AzureADMultipleOrgs
  • Личен акаунт в Microsoft

SignInAudience трябва да съдържа една от горепосочените стойности. Ако не намерите нито една от тези стойности в настройката SignInAudience, трябва да създадете регистрацията на приложението отново.

2] Използвайте правилния URL адрес за влизане

Друга причина за тази грешка е използването на неправилен URL адрес за влизане. Например, ако използвате https://login.Microsoftonline.com/<YourTenantNameOrID> URL, удостоверяването се очаква да се изпълнява само на вашия клиент. Ето защо потребителите в други организации нямат достъп до приложението. Когато други потребители се опитат да направят това, те ще получат грешка при влизане.

За да разрешите този проблем, трябва да добавите тези потребители като гости в клиента, посочен в заявката. Можете да използвате съответния URL адрес за вход за конкретен тип приложение. Някои примери са посочени по-долу:

За типа Multitenant приложения можете да използвате следния URL адрес за влизане.

https://login.microsoftonline.com/organizations

Ако използвате Multitenant и лични акаунти, можете да използвате следния URL адрес за вход.

https://login.microsoftonline.com/common

Само за лични акаунти използвайте този URL адрес за влизане.

https://login.microsoftonline.com/consumers

3] Излезте, след което влезте отново от различен браузър или частна сесия на браузъра

Понякога тази грешка възниква, когато потребителят влезе в грешен клиент. Например, когато потребител вече има активна сесия в своя уеб браузър и той/тя се опитва да осъществи достъп до вашето приложение, като щракне върху съответната връзка или въведе необходимия URL адрес в нов раздел.

В тази ситуация помолете потребителя гост да направи едно от следните неща:

• Излезте от акаунта, който вече е отворен в неговия/нейния уеб браузър. Това ще прекрати вече активната сесия. Сега той/тя може да влезе, като използва правилната връзка и идентификационни данни.
• Влезте с друг уеб браузър.
• Влезте в прозореца Лично или Инкогнито в същия уеб браузър.

4] Поканете потребителя гост

Тази грешка се появява и когато потребителят гост не е поканен. Решението на тази ситуация е просто. Поканете потребителя гост.

5] Задайте достъп на потребителите (ако е приложимо)

Ако вашето приложение е корпоративно приложение, което изисква присвояване на потребител и потребителят не е в списъка с разрешени потребители, на които е назначен достъп до приложението, тогава ще възникне тази грешка.

Можете да проверите дали вашето корпоративно приложение изисква присвояване на потребител или не, като следвате стъпките, дадени по-долу:

1. Отидете на портала на Azure.
2. Изберете Корпоративно приложение(я) .
3. Изберете вашето корпоративно приложение.
4. Изберете Имоти .
5. Проверете дали Изисква се задание опцията е зададена на да . Ако е зададено на Да, това приложение изисква присвояване на потребител.

В тази ситуация задайте достъп на потребители поотделно или като част от група.

6] Използвайте крайна точка, която е специфична за наемателя или организацията

Кодът на грешката AADSTS50020 може също да възникне, когато потребител се опита да използва потока за идентификационни данни на собственика на ресурса (ROPC) за неговия/нейния личен акаунт(и). Платформата за идентичност на Microsoft поддържа само ROPC в рамките на наематели на Azure AD, а не лични акаунти.

В тази ситуация потребителят трябва да използва крайната точка, която е специфична за клиента или организацията. Обърнете внимание, че личните акаунти не могат да използват ROPC, дори ако са поканени на клиент на Azure AD.

7] Нулирайте състоянието на изкупуване на потребителския акаунт на гост

Ако администраторът е изтрил потребителското име на потребителя гост в клиента на ресурса и го е създал отново в домашния клиент, потребителят гост ще срещне тази грешка. Администраторът трябва също така да провери дали потребителският акаунт на гост в наемателя на ресурса не е свързан с потребителския акаунт на гост в домашния наемател.

За да коригирате грешката в тази ситуация, нулирайте състоянието на изкупуване на потребителския акаунт на гост в наемателя на ресурса.

Това е. Надявам се това да помогне.

Какъв идентификатор на наемател се използва в Azure?

ИД на клиента в Azure е уникален идентификатор за клиент на Azure Active Directory (Azure AD). Нарича се още ИД на клиента на Office 365. Има различни начини да получите вашия ИД на клиент на Azure.

Кой е администратор на наемател?

Администратор на клиент е потребител, който има най-високото ниво на разрешения в клиент на Azure Active Directory (Azure AD). Той/тя може да управлява всички аспекти на клиента, включително потребители, групи, разрешения и настройки.

Прочетете следващия : Грешка AADSTS90100, параметърът за влизане е празен или невалиден .

• | Повече ▼