@amanmcse : Sorry, but you’re speaking a different language than I do («federated IDP», «ROPC», «Implicit or Code Grant flow», «ADAL» etc.). But that aside:
I think that you’re assuming a different situation. You seem to be presuming that I’m a domain admin («you would need to disable federated authentication»). I am talking from the perspective of a software developer that needs to authenticate their users, and uses OAuth2. It must work for all users, no matter the configuration. Neither we nor our users have admin rights on the domain. Things working for some users and not for others, depending on the domain config, is pure nightmare, for all parties involved.
The problem here is something else, and is simple: The Microsoft servers return the wrong error code and message. The error message and code are flat out wrong.
From the software side, we must unambiguously distinguish between a) an actually invalid password, where the user entered the wrong password, and b) some technical problem or incompatibility with the domain setup. The reason why it’s crucial to differentiate is because the error recovery is very different. In the first case a), I tell the user that his password is wrong and he needs to enter it again. In the second case b), I either do some fallback code or tell the user that I cannot support his account. If I pick the wrong case, because the error code I get is wrong — as in this case -, then I’ll keep asking the user to re-enter the passwords, which is completely useless, confusing, and might even lead him to enter other passwords, which is dangerous. In any case, it’s a really bad end user experience.
The documentation specifically says that this error code means that is an invalid password. The password is right, so the error message is flat out wrong. The error message is correct in most configurations, where it’s really returned only for wrong passwords, just not in this one.
The bug here is just that a MS developer was re-using the wrong error code, instead of creating a new error code as he should. This must be fixed in the Microsoft software. That’s the only place where it can be fixed. There’s no other way to fix this properly.
This leads to hurt and setup pains for end users. Please fix it.
- Remove From My Forums
Resource Owner Password Credential — invalid grant — AADSTS50126: Invalid username or password for a Native client
-
Question
-
Hi,
I am trying ROPC with a native application and my username and password are valid as am able to login using the credentials. Am trying from postman and always see the error. Went through lot of blogs and no where I can see a correct solution
so wanted to check here.Error as :
{
«error»:
«invalid_grant»,«error_description»:
«AADSTS50126: Invalid username or password.rnTrace ID: 02beaa81-58a6-43ba-b409-af20705a1500rnCorrelation ID: 140abe12-b367-4fd3-ba44-2f17a74c87ecrnTimestamp: 2019-10-25 02:32:15Z»,«error_codes»: [
50126
],
«timestamp»:
«2019-10-25 02:32:15Z»,«trace_id»:
«02beaa81-58a6-43ba-b409-af20705a1500»,«correlation_id»:
«140abe12-b367-4fd3-ba44-2f17a74c87ec»,«error_uri»:
«https://login.microsoftonline.com/error?code=50126»}
Unable to post image as it asks to verify account.
Thanks,
Ravi
Answers
-
Thanks Sourav for your reply but I was able to figure it myself. Our organization identity wasn’t allowing to verify the credentials directly, we need to get the assertion for the credentials by posting to federation active auth url and that assertion
has to be passed as part of ROPC call in the below format postData = «resource={resourceUrl}&client_id={clientId}&grant_type={grantType}&assertion={assertion}&scope=openid» . Hope this will be useful to others who might get struck with same issue.
———————————————————————— Apologies as am unable to post images couldn’t share the screenshots. Thanks, Ravikiran-
Marked as answer by
Friday, October 25, 2019 1:50 PM
-
Marked as answer by
#java #azure #oauth-2.0 #azure-active-directory #single-sign-on
#java #azure #oauth-2.0 #azure-active-directory #единый вход
Вопрос:
Я пытаюсь отправить запрос post https://login.microsoftonline.com/<My_Tenant_Id>/oauth2/token из моего Java-кода, но я получаю сообщение об ошибке «invalid_grant: AADSTS50126: ошибка проверки учетных данных из-за неверного имени пользователя или пароля». Я проверил учетные данные, и они верны (я могу войти на портал Azure и просмотреть свое приложение AWS для единого входа). Я даже пытался выполнить тот же запрос от postman, но затем также возникла та же проблема.
Параметры, которые я передал, следующие:
"grant_type", "password"
"requested_token_type","urn:ietf:params:oauth:token-type:saml2"
"username", username
"password", password
"client_secret", clientSecret
"client_id", clientId
"resource", clientId
Я даже проверил различные документы Microsoft, но я все еще не могу решить эту проблему.
Кто-нибудь может сказать, в чем может быть проблема. является ли вызов API неправильным или неправильная настройка сервера.
Пожалуйста, обратите внимание: изначально мой вызов API работал, но затем я получил сообщение об ошибке invalid_request: AADSTS80014, затем оно автоматически разрешилось, и я начал получать invalid_grant: AADSTS50126. Кто-нибудь сталкивался с этой проблемой или знает, как это исправить. Спасибо!
Комментарии:
1. Я использую тот же текст запроса, что и ваш. Но для меня это работает нормально. Не могли бы вы предоставить скриншот запроса (включая тело запроса и ответ) в Postman? Не забудьте удалить идентификатор клиента, идентификатор клиента, секрет клиента, имя пользователя и пароль на скриншоте.
2. Вам все еще нужна помощь по этому вопросу?
3. Привет, Аллен, я могу решить эту проблему сейчас. Я создал облачного пользователя только для потока предоставления пароля владельца ресурса, и он работал, как ожидалось. Спасибо!
4. Рад это знать. Не могли бы вы добавить ответ, чтобы помочь другим?
Ответ №1:
Я могу решить эту проблему, создав пользователя только для облака. Причина, по которой у федеративного пользователя не удается выполнить поток предоставления пароля владельца ресурса, заключается в том, что для федеративного пользователя Azure AD должен перенаправить пользователя на определенный сервер федерации, который принадлежит локальному домену пользователя, чтобы сервер ADFS мог выполнить аутентификацию с помощью локального контроллера домена. В потоке предоставления пароля владельца ресурса это перенаправление невозможно, следовательно, оно не может подтвердить имя пользователя и пароль и, следовательно, эту ошибку.
В качестве предложения мы можем создать нового пользователя cloud only, имя пользователя и пароль которого должны находиться в Azure AD, чтобы при использовании потока предоставления пароля владельца ресурса мы отправляли учетные данные пользователя, AAD мог аутентифицировать пользователя без каких-либо перенаправлений.
Этот пользователь может быть обычным пользователем в AAD, и соответствующие делегированные разрешения должны присутствовать при регистрации приложения. Теперь еще одна вещь, в которой нужно убедиться: если делегированное разрешение, которое мы предоставляем, требует согласия администратора, то перед тем, как пользователь войдет в приложение, администратор должен предоставить согласие администратора на это делегированное разрешение. Если мы хотим, чтобы пользователь предоставил свое собственное согласие (если для делегированного разрешения требуется согласие пользователя), тогда нам нужно было бы каким-то образом предоставить согласие пользователя, прежде чем переходить к потоку предоставления пароля владельца ресурса.
@ManuelMos Спасибо за отзыв. Мы будем исследовать и обновлять это дальше.
Привет @ManuelMos!
Я выполнил поток ROPC и могу получить токен. Не могли бы вы проверить значение своей области или попробовать выполнить с другим именем пользователя и паролем.
Для справки, пожалуйста, проверьте скриншот ниже:
Сообщите нам, если это поможет.
Спасибо.
Привет @ManuelMos!
Я надеюсь, что приведенная выше информация окажется полезной. Сейчас мы закроем эту проблему. Если у вас возникнут дополнительные вопросы, отметьте меня или
Спасибо.
Привет, @ MohitDhingra-MSFT @shashishailaj , я все еще получаю ту же ошибку. мы можем поговорить по электронной почте по этому вопросу?
@ MohitDhingra-MSFT @shashishailaj
Извините за поздний ответ.
По-прежнему возникает та же проблема:
Есть ли в Azure какие-либо настройки администратора, запрещающие использование потока ROPC?
Если я попытаюсь использоватьПочтовый адрес .onmicrosoft.com в качестве имени пользователя я мгновенно получаю:
AADSTS50034: учетная запись пользователя Microsoft.AzureAD.Telemetry.Diagnostics.PII не существует в каталоге stracloud.onmicrosoft.com.
Итак, я думаю, мне нужно использовать наш почтовый адрес по умолчанию, который мы также используем для входа со стандартным входом в лазурный.
Мы сталкиваемся с той же проблемой, пробовали использовать несколько учетных записей пользователей. Мне кажется, что какая-то информация отсутствует?
@ManuelMos Приносим извинения за поздний ответ. Не могли бы вы написать нам по адресу azcommunity [at] microsoft [dot] com, указав свой идентификатор подписки Azure, и мы поможем вам с альтернативными вариантами поддержки.
Спасибо.
Даже у меня такая же ошибка. Это для клиента VMware
@ManuelMos Вы прошли через это? если да, опубликуйте предоставленные шаги решения.
Все данные моей учетной записи верны, по-прежнему возникает та же ошибка. благодаря
@shashishailaj
Я зарегистрировал собственное приложение (для операции Power BI push) и добавил необходимые разрешения API.
Глобальный администратор дал согласие. Но метод токена доступа не работает.
эквивалентный сценарий PS, используемый для получения токена доступа
$authUrl = "https://login.windows.net/common/oauth2/token"
$body = @{
"resource" = “https://analysis.windows.net/powerbi/api";
"client_id" = "myclientid";
"grant_type" = "password";
"username" = "myuser";
"password" = "mypass";
"scope" = "openid"
}
$authResponse = Invoke-RestMethod -Uri $authUrl –Method POST -Body $body
$authResponse.access_token
Но получаю ту же ошибку:
Invoke-RestMethod: {«error»: «invalid_grant», «error_description»: «AADSTS50126: неверное имя пользователя или пароль.
Используемая главная учетная запись синхронизируется с Azure AD с сервера Active Directory Windows.
Заблокировано вокруг этой проблемы на время. Любая быстрая помощь приветствуется. Заранее спасибо.
@ajiljins @ MohitDhingra-MSFT @shashishailaj По-прежнему
Я предполагаю, что это настройка арендатора или что-то в этом роде. В настоящее время жду ответа от почты azcommunity.
@ MohitDhingra-MSFT
Этот билет следует открыть повторно, поскольку проблема все еще существует.
@ManuelMos Мои искренние извинения за задержку. Каким-то образом спам-фильтры поймали это письмо. Я ответил вам в цепочке писем о следующих действиях.
@ajiljins Мы работаем над этим внутри и обновим результаты в этой теме.
Получение такой же ошибки. Использование запроса ROPC из коллекции почтальонов. Этот поток работает?
так это было «решено» за нас. Мы упустили из виду, что ROPC не поддерживается в гибридных установках. На случай, если кто-то еще застрял по той же причине.
Я попытался выполнить поток ROPC с помощью почтальона, и мне удалось получить токен. Ниже скриншот.
Надеюсь, на этот раз приведенная выше информация окажется полезной. Сейчас мы закроем эту проблему. Если у вас возникнут дополнительные вопросы, отметьте меня тегом своего ответа, и мы с радостью продолжим разговор.
Спасибо.
Надеюсь, на этот раз приведенная выше информация окажется полезной. Сейчас мы закроем эту проблему. Если у вас возникнут дополнительные вопросы, отметьте меня тегом своего ответа, и мы с радостью продолжим разговор.
Спасибо.
Нашел проблему. Необходимо перейти на вкладку аутентификации приложения, прокрутить вниз и выбрать Yes в Default client type section
Привет,
Я получаю ту же ошибку: «AADSTS50126: Неверное имя пользователя или пароль. RnTrace ID: rnИдентификатор корреляции: rnTimestamp: 2019-09-30 10: 31: 04Z «.
Запрос:
ЗАПИСАТЬ https://login.microsoftonline.com/tenant-id/oauth2/v2.0/token
grant_type: пароль
client_id: идентификатор клиента из регистрации приложения
client_secret: секретный ключ из сертификатов и секрет
имя пользователя: имя пользователя
пароль: пароль
область: https://graph.microsoft.com/.default
Я изменил «Тип клиента по умолчанию» на ДА, чтобы активировать поток ROPC.
Почтальон:
Я получаю ошибку:
@ MohitDhingra-MSFT, не могли бы вы ответить?
Заранее спасибо.
@ MohitDhingra-MSFT: у меня та же проблема, что и у @vskgit в предыдущем комментарии. Наш клиент всегда был «Тип клиента по умолчанию» = Да. Тем не менее, мы получаем код ошибки 50126 «Неверный пароль».
@ MohitDhingra-MSFT: у меня та же проблема, что и у @vskgit в предыдущем комментарии. Наш клиент всегда был «Тип клиента по умолчанию» = Да. Тем не менее, мы получаем код ошибки 50126 «Неверный пароль».
Я все еще сталкиваюсь с этой проблемой. это решено?
Здравствуйте,
Я тоже столкнулся с той же проблемой.
Кто-нибудь может нам помочь?
Кстати: я пытаюсь получить доступ к этому API:
https://login.microsoftonline.com/ [Tenant_ID] /oauth2/v2.0/token
@ MohitDhingra-MSFT Я столкнулся с той же проблемой. Не могли бы вы помочь?
Это проект документации MS, но похоже, что это ошибка программного обеспечения, поскольку возвращается неправильный код ошибки. Есть ли у кого-нибудь способ сообщить об ошибках в Microsoft таким образом, чтобы MS их слушала и исправляла?
Всем привет,
Если у вас включена федеративная аутентификация для входа пользователя, вы будете перенаправлены к федеративному IDP для проверки учетных данных. Теперь, когда вы используете поток ROPC через почтальона, это перенаправление невозможно, и это приводит к ошибке неверного имени пользователя или пароля.
Чтобы это работало, вам необходимо отключить федеративную проверку подлинности и использовать управляемую проверку подлинности, чтобы AAD мог проверять учетные данные локально и не требовалось перенаправления. Вы можете подтвердить это, запросив токен для облачной учетной записи пользователя.
Поскольку вы указываете свои учетные данные в теле запроса в случае ROPC, перенаправление не будет происходить на основе суффикса UPN.Если вы используете другие потоки, такие как неявный или поток предоставления кода, вы получите приглашение ADAL (как показано ниже), которое поддерживает перенаправление и Федеративная аутентификация будет работать в этом случае.
@amanmcse : Извините, но вы говорите на другом языке, чем я («федеративный IDP», «ROPC», «Неявный поток или поток предоставления кода», «ADAL» и т. д.). Но помимо этого:
Я думаю, что вы предполагаете другую ситуацию. Похоже, вы предполагаете, что я администратор домена («вам нужно отключить федеративную аутентификацию»). Я говорю с точки зрения разработчика программного обеспечения, которому необходимо аутентифицировать своих пользователей и который использует OAuth2. Он должен работать для всех пользователей , независимо от конфигурации. Ни у нас, ни у наших пользователей нет прав администратора в домене. То, что работает для одних пользователей, а не для других, в зависимости от конфигурации домена, является кошмаром для всех вовлеченных сторон.
Проблема здесь в другом, и она проста: серверы Microsoft возвращают неправильный код ошибки и сообщение. Сообщение об ошибке и код совершенно неверны.
Что касается программного обеспечения, мы должны однозначно различать: а) действительно неверный пароль, когда пользователь ввел неправильный пароль, и б) техническая проблема или несовместимость с настройкой домена. Причина, по которой так важно различать, заключается в том, что восстановление после ошибок сильно отличается. В первом случае а) я говорю пользователю, что его пароль неверен и ему нужно ввести его снова. Во втором случае b) я либо использую резервный код, либо говорю пользователю, что не могу поддерживать его учетную запись. Если я выберу неправильный регистр, потому что код ошибки, который я получаю, неправильный — как в этом случае — я буду продолжать просить пользователя повторно ввести пароли, что совершенно бесполезно, сбивает с толку и может даже привести его к вводить другие пароли, что опасно. В любом случае, это действительно плохой опыт для конечного пользователя.
В документации прямо говорится, что этот код ошибки означает, что это неверный пароль. Пароль правильный, поэтому сообщение об ошибке совершенно неверно. Сообщение об ошибке является правильным в большинстве конфигураций, где оно действительно возвращается только для неправильных паролей, но не в этой.
Ошибка здесь просто в том, что разработчик MS повторно использовал неправильный код ошибки, вместо того, чтобы создавать новый код ошибки, как он должен. Это должно быть исправлено в программном обеспечении Microsoft. Это единственное место, где это можно исправить. Другого способа исправить это должным образом нет.
Это причиняет вред и затрудняет настройку конечных пользователей. Пожалуйста, исправьте.
@benbucksch Да, в этом случае имеет смысл оставить отзыв об этом на https://feedback.azure.com, который контролируется командой разработчиков продукта.
Но для возврата другой ошибки потребуется выполнить определенные проверки, и выполнение этих проверок будет сложной задачей, которая может повлиять на общее время предоставления ответа аутентификации. Возможно, если вы прочитаете о «федеративном IDP», «ROPC», «Неявном потоке или потоке предоставления кода», «ADAL» и т. Д., Это будет иметь больший смысл.
@amanmcse : +1:
Спасибо за подтверждение! Это ценится.
может повлиять на общее время предоставления ответа аутентификации
Учитывая, что это ситуация с ошибкой, более медленный ответ — это нормально, если это дает более правильный ответ. Последствия текущей ситуации отнимают у пользователя много времени или приводят к полному отказу всего процесса. Правильное сообщение об ошибке может быть исправлено. Это стоит нескольких мс или даже нескольких секунд.
Хуже того, текущая ситуация означает, что я не могу доверять коду ошибки ни в какой ситуации, даже если он действительный и правильный.
@ Все, кого это касается:
вы можете оставить отзыв об этом на https://feedback.azure.com, который контролируется командой разработчиков продукта.
и как говорится в документе, на который ссылается @CelesteDG :
Если у вас уже есть план поддержки Azure, откройте запрос поддержки
Всем привет,
Кто-нибудь нашел решение этой проблемы? Или есть альтернатива ?. Пожалуйста, поделитесь, если есть.
Привет всем,
У меня такая же проблема.
Поделитесь пожалуйста решением.
У меня такая же проблема. Никто на это не смотрит?
У меня такая же проблема. Любой ответ?
Я опубликовал другое решение этой проблемы здесь: https://medium.com/@amanmcse/ropc -username-password-flow-fails-with-aadsts50126-invalid-username-or-password-for-federated-90c666b4808d? Sk = 7c4c55332c5b27d0546abf3d3487e85b
@amanmcse
У меня такая же проблема.
Я пробовал ваше решение с применением HomeRealmDiscoveryPolicy к принципалу. Никаких изменений.
По-прежнему получаю 400 с ответом с неверными учетными данными.
"timestamp": "2020-07-19 13:53:14Z",
"trace_id": "87892273-8a5f-474a-a79e-2ef8d1fd2201",
"correlation_id": "feaee5d2-7301-483a-8e8e-5baa2e8a7e7d",
@tochilavictor Спасибо за ваш отзыв. В команде New-AzureADPolicy произошла небольшая ошибка. Я исправил это. Пожалуйста, попробуйте еще раз выполнить описанные здесь шаги и дайте мне знать, если это поможет.
Мы дополнительно отладили это с помощью проектирования крупного клиента и обнаружили, что ошибка 50126 возвращается в тех случаях, когда домен Office365 использует стороннего поставщика MFA, а программное обеспечение почтового клиента пытается использовать OAuth2 с паролем. В этом случае серверы Microsoft возвращают этот код ошибки 50126.
Это явно ошибка сервера Microsoft, потому что код ошибки 50126 очень четко определен как ошибка пользователя , когда пользователь ввел неправильный пароль. Однако пароль правильный, просто неправильный метод аутентификации.
Как уже объяснялось выше , разница между случаями очень важна, потому что программное обеспечение почтового клиента должно либо попросить пользователя исправить пароль, либо попробовать другие методы аутентификации, которые также требуют взаимодействия с пользователем, но другого. Итак, программное обеспечение должно решить, что делать. Но из-за этой ошибки, когда оба случая возвращают один и тот же код ошибки (а также нет другого известного нам способа узнать включенные методы аутентификации заранее), мы застряли. Правильно это реализовать невозможно.
@amanmcse : Не могли бы вы исправить это? Я подал «ящик предложений», но его не только проигнорировали, но и просто удалили :-(.
@benbucksch @amanmcse
есть ли какое-либо решение, кроме этого, у нас есть клиент с гибридной AD, а пользователю, созданному в облаке, нельзя предоставить доступ к рабочему пространству power bi, поскольку пользователь не будет синхронизироваться.
Как получить токен доступа, чтобы мы могли встроить отчет power bi в веб-приложение.
Всем привет. У меня такая же проблема. Я ввел правильные учетные данные и могу получить доступ через браузер, но не через почтальон.
Надеюсь, кто-нибудь сможет мне помочь, потому что я застрял. заранее спасибо
параметры:
grant_type: пароль
client_id: xxxxxprovidedxxxxxx
client_secret: xxxxxxprovidedxxxxxx
область: https://graph.microsoft.com/.default
имя пользователя: xxxxxxprovidedxxxxxx (можно получить через браузер https://developer.microsoft.com/en-us/graph/graph-explorer)
пароль: xxxxxxprovidedxxxxxx
возврат ошибки
{
«error»: «invalid_grant»,
«error_description»: «AADSTS50126: Ошибка проверки учетных данных из-за неправильного имени пользователя или пароля. rnTrace ID: d9cc74aa-91da-4bd2-b77f-ecaa6ec28d00 rnCorrelation ID: 38941c60-5898-462b-9ab7-cb18estfa: rn 10 05: 09: 57Z «,
«error_codes»: [
50126
],
«timestamp»: «2020-12-10 05: 09: 57Z»,
«trace_id»: «d9cc74aa-91da-4bd2-b77f-ecaa6ec28d00»,
«correlation_id»: «38941c60-5898-462b-9ab7-cb4bfa0cb18e»,
«error_uri»: » https://login.microsoftonline.com/error?code=50126 «
}
Была ли эта страница полезной?
0 / 5 — 0 рейтинги