@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.
A recurring job has started to fail, I’ve recreated the issue with Postman.
Error:
"error": "invalid_grant",
"error_description": "AADSTS50126: Error validating credentials due to invalid username or password."
"error_codes": [50126]
"error_uri": "https://login.microsoftonline.com/error?code=50126"
The Username & Password used, work with MS Graph Explorer so I’m confident that the password has not changed. I did change the grant_type=client_credentials and this works so I believe the rest of the settings are also correct. I did ramp up the frequency of the job from daily to hourly lately, but the error message indicates an authentication issue.
I’m running out of ideas to try & troubleshoot, perhaps someone knows something that I don’t.
Postman settings:
These are the production settings used in MS Power Automate, the same as above.
#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, и соответствующие делегированные разрешения должны присутствовать при регистрации приложения. Теперь еще одна вещь, в которой нужно убедиться: если делегированное разрешение, которое мы предоставляем, требует согласия администратора, то перед тем, как пользователь войдет в приложение, администратор должен предоставить согласие администратора на это делегированное разрешение. Если мы хотим, чтобы пользователь предоставил свое собственное согласие (если для делегированного разрешения требуется согласие пользователя), тогда нам нужно было бы каким-то образом предоставить согласие пользователя, прежде чем переходить к потоку предоставления пароля владельца ресурса.
- 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
Description
When the Logic App runs the process completes (the Team is built) however no Sensitivity Label is applied to the team. Checking the Run it has an error on ‘Get access token for service account’:
{
«statusCode»: 400,
«headers»: {
«Pragma»: «no-cache»,
«Strict-Transport-Security»: «max-age=31536000; includeSubDomains»,
«X-Content-Type-Options»: «nosniff»,
«x-ms-request-id»: «6b94c72a-ffa6-4020-a447-ba7d303a4f00»,
«x-ms-ests-server»: «2.1.13315.8 — NEULR1 ProdSlices»,
«X-XSS-Protection»: «0»,
«Cache-Control»: «no-store, no-cache»,
«P3P»: «CP=»DSP CUR OTPi IND OTRi ONL FIN»»,
«Set-Cookie»: «fpc=Aux22KyFavtGtvlkp7satYe_kuEMAQAAAKdgc9oOAAAA; expires=Fri, 26-Aug-2022 16:36:55 GMT; path=/; secure; HttpOnly; SameSite=None,x-ms-gateway-slice=estsfd; path=/; secure; samesite=none; httponly,stsservicecookie=estsfd; path=/; secure; samesite=none; httponly»,
«Date»: «Wed, 27 Jul 2022 16:36:55 GMT»,
«Content-Length»: «495»,
«Content-Type»: «application/json; charset=utf-8»,
«Expires»: «-1»
},
«body»: {
«error»: «invalid_grant»,
«error_description»: «AADSTS50126: Error validating credentials due to invalid username or password.rnTrace ID: 6b94c72a-ffa6-4020-a447-ba7d303a4f00rnCorrelation ID: 5bd05ce5-20ad-48b2-a509-dabfed573562rnTimestamp: 2022-07-27 16:36:55Z»,
«error_codes»: [
50126
],
«timestamp»: «2022-07-27 16:36:55Z»,
«trace_id»: «6b94c72a-ffa6-4020-a447-ba7d303a4f00»,
«correlation_id»: «5bd05ce5-20ad-48b2-a509-dabfed573562»,
«error_uri»: «https://login.microsoftonline.com/error?code=50126»
}
}
Steps to reproduce
- Use App to create a Team.
2.Team is created but missing the sensitivity label
Expected results
Expect to see sensitivity label applied to Team
Actual Results
Team is created with no sensitivity label.
Solution component
Logic Apps
Operating system (environment)
Windows
Additional Info
I have manually recreated new key vault with sapassword and sausername and amend the flow to use it however the same issue occurs.
BTW. The username and password for this service account is used throughout the App config and is correct.
In addition FYI: https://docs.microsoft.com/en-us/answers/questions/385629/aadsts50126-error-validating-credentials-due-to-in-1.html this article explains that for this to work we need to:
- Sync users’ passwords to Azure AD. If you don’t want to sync password for entire organization, you may consider using Selective Password Hash Sync.
- Create a policy to allow credentials validation of federated users from within Azure AD.
- Link the policy to the application, for which you want to use ROPC flow with federated accounts.
We have Password Hash Sync already enabled do we need to also do steps 2 & 3 so that will allow federated user to authenticate directly from AzureAD without requiring to redirect to the federated Identity Provider (IDP)?
(https://medium.com/@amanmcse/ropc-username-password-flow-fails-with-aadsts50126-invalid-username-or-password-for-federated-90c666b4808d)
Невозможно получить токен доступа, тип предоставления: пароль
URL:
https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token?resources=https%3A%2F%2Fgraph.microsoft.com%2F
Запрос:
{'grant_type': 'password', 'client_id': <client_id>, 'scope': 'openid User.Read Mail.Read', 'username': '<email_id>', 'client_secret': '<client_secret>, 'password':<password>}
Отклик:
{'correlation_id': 'bbe33e96-aeb8-4e8f-8a2f-1330510c298f',
'error_codes': [70002, 50126],
'timestamp': '2018-12-19 06:58:03Z',
'error': 'invalid_grant',
'trace_id': 'c69686fb-a84e-4299-a72c-0cf079381300',
'error_description': 'AADSTS70002: Error validating credentials. AADSTS50126: Invalid username or passwordrnTrace ID: c69686fb-a84e-4299-a72c-0cf079381300rnCorrelation ID: bbe33e96-aeb8-4e8f-8a2f-1330510c298frnTimestamp: 2018-12-19 06:58:03Z'}
Может ли кто-нибудь узнать, что не так. Имя пользователя и пароль верны.
2 ответа
Для меня в Postman сработало следующее.
URL (POST):
https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token
Заголовок:
Content-Type
application/x-www-form-urlencoded
Тело запроса (текст):
client_id=<client_id>&
scope=https://graph.microsoft.com/.default&
grant_type=client_credentials&
client_secret=<client_secret>
-1
4b0
12 Апр 2019 в 10:21
Предлагаем вам попробовать следующий способ:
URL:
Post https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token
Тип содержимого:
application/x-www-form-urlencoded
Тело запроса:
client_id=<client_id>&
scope=https://graph.microsot.com/Mail.Read openid User.Read&
grant_type=password&
username=<email_id>&
client_secret=<client_secret>&
password=<password>
И ответ: 
0
SunnySun
20 Дек 2018 в 11:00
A recurring job has started to fail, I’ve recreated the issue with Postman.
Error:
"error": "invalid_grant",
"error_description": "AADSTS50126: Error validating credentials due to invalid username or password."
"error_codes": [50126]
"error_uri": "https://login.microsoftonline.com/error?code=50126"
The Username & Password used, work with MS Graph Explorer so I’m confident that the password has not changed. I did change the grant_type=client_credentials and this works so I believe the rest of the settings are also correct. I did ramp up the frequency of the job from daily to hourly lately, but the error message indicates an authentication issue.
I’m running out of ideas to try & troubleshoot, perhaps someone knows something that I don’t.
Postman settings:
These are the production settings used in MS Power Automate, the same as above.
asked Apr 1, 2020 at 6:21
4
If its an unattended process and uses the client credentials flow, then the username and password are not being used at all.
An Access token is being obtained using the clientId and the client secret alone.
It’d help if you can list the operations that you are planning to call in the question.
Note that MS Graph uses both delegated and application permissions and depending on the Api being called, you would be required to sign-in as an app of sign-in a user. Its a bit of a learning curve and I’d recommend you go through a session like this one.
answered Apr 1, 2020 at 10:45
5
Problem: Authentication error when trying to authenticate to MS Graph API with an AD account that had previously worked.
Final Hypothesise: A potential issue between cloud authentication & on-prem AD authentication.
Solution: A new AzureAD service account specifically for the purpose was created & provisioned with similar access to the original service account & all worked as normal.
Summary: The issue seems to have been the link between AzureAD & on-premAD. Hope this helps someone out in future
answered Apr 13, 2020 at 23:30
M O’ConnellM O’Connell
4875 silver badges18 bronze badges
Вот точный пример того, как вы можете получить токен, используя Resource Owner Password Credentials (ROPC)
Шаг 1:
Установите URL-адрес вашего запроса следующим образом:
https://login.microsoftonline.com/ YourTenantName / TenantID.onmicrosoft.com / oauth2 / v2.0 / token
Смотрите скриншот
https://stackru.com/images/2040c4141ecef3cb047892e2d555949492263516.png g
Вы можете получить свое имя арендатора прямо вверху вашего лазурного портала. Посмотрите на
снимок экрана ниже:
https://stackru.com/images/8fd39fa2e7f16a1ae161cb213d8b546c68029540.png g
Шаг 2:
Формат заголовка запроса
https://stackru.com/images/b395a7aae5836fd963067bec27458718369716f6.png g
Шаг 3:
Установите тело запроса согласно информации вашего приложения в следующем формате:
client_id: ваш идентификатор клиента
client_secret: секрет вашего приложения
username: Ваше имя пользователя для этого приложения
пароль: ваш пароль для этого приложения
grant_type: пароль
область действия: https: //graph.microsoft.com/.default или ваш предпочтительный объем
См. Снимок экрана ниже для формата тела запроса:
https://stackru.com/images/3eedb8559b02eb5218bbc756c9ea6faa81bd4b03.png g
В ответ я получил свой токен, как и ожидалось. Смотрите картинку ниже:
https://stackru.com/images/f0b43142488ddeae31bc42b239e63e5e06420eb7.png g
Возможная причина вашей проблемы:
-
Личный кабинет не может быть использован для этого потока кода
-
Это может произойти, если вы изменили секрет приложения и попытались использовать старый.
-
Ваше имя пользователя и пароль могут не совпадать с текущим арендатором.
Вы можете попробовать этот пример выше, чтобы получить ваш запрос, как ожидалось. Вы также можете проверить портал Azure, чтобы убедиться, что ваше приложение успешно создано. Для получения дополнительной информации вы можете посмотреть здесь
Примечание. Вы используете личный кабинет, который не подходит для этого потока. см. снимок экрана ниже: Для получения дополнительной информации вы можете увидеть официальный документ Microsoft здесь
https://stackru.com/images/05861e66220d281385188602a42c85574b946978.png g
#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, и соответствующие делегированные разрешения должны присутствовать при регистрации приложения. Теперь еще одна вещь, в которой нужно убедиться: если делегированное разрешение, которое мы предоставляем, требует согласия администратора, то перед тем, как пользователь войдет в приложение, администратор должен предоставить согласие администратора на это делегированное разрешение. Если мы хотим, чтобы пользователь предоставил свое собственное согласие (если для делегированного разрешения требуется согласие пользователя), тогда нам нужно было бы каким-то образом предоставить согласие пользователя, прежде чем переходить к потоку предоставления пароля владельца ресурса.