We have a code that logins to Sharepoint Online using :
https://login.microsoftonline.com/extSTS.srf or https://login.microsoftonline.com/RST2.srf, but recently we starting to get authentication failed saying that "Incorrect Username or Password" and after some retries it returns:
"0x80048823 message : AADSTS70002: Error validating credentials. AADSTS50053: You've tried to sign in too many times with an incorrect user ID or password."
While using same username and password to login in the browser works fine, and neither password or username were changed, also code didn't changed. As same code works fine for another Sharepoint tenants. Seems that something changed in the Microsoft login servers, where it's started to not accept user credentials, while web browser login works fine.
Please advise.
Thanks
Microsoft Rep has helped me get this far.
They had us create a "Cloud Only" user. This user was setup as "#" so if your name is bill and your corporate sharepoint site is name is FakeCompany.sharepoint.com then you would have the person as "bill#FakeCompany.onmicrosoft.com"
This user was able to login to https://login.microsoftonline.com/extSTS.srf by just passing username and password.
Our on prem AD users are still having issues, i mentioned this and got the following response.
There is no issue with sync as you are able to login to portal using the same account and password.
The solution you need is documented in https://learn.microsoft.com/en-gb/azure/active-directory/manage-apps/configure-authentication-for-federated-users-portal#enable-direct-authentication-for-legacy-applications
You need to create a home realm discovery (HRD) policy where "AllowCloudPasswordValidation":true.
We have not yet implemented the last solution but the creating of a cloud account may help some of you.
So I think I understand what they are trying to say. There are 2 paths that you are able to authenticate with according to the node-sp-auth example.
"Managed" and "Federated"
"Managed" was the easier version and allowed for you to be able to just provide username and credentials in a soap assertion to login.
Federated is a lot more complicated. You need to first perform a post to Microsoft to validate the user hitting your adfs server. https://adfs.XXXXXXX.com/adfs/services/trust/13/usernamemixed
Then you take the saml:Assertion from that response and put it into the "Token" section of the call you make to https://login.microsoftonline.com/extSTS.srf utilizing the templates from the node-sp-auth.
I have C# code that performs all these steps but I am getting an error
AADSTS70002: Error validating credentials. AADSTS50008: SAML token is invalid. AADSTS50006: Invalid signature. Signature verification failed.
Even though the signature is being generated by Microsoft in their SAML.
node-sp-auth code refrence is OnlineUserCredential.ts file.
If someone can figure out the last mile I can post a comprehensive C# solution.
Related
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.
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.
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
Unable to get the access token by directly passing the username and password
Endpoint : https://login.microsoftonline.com/{tenant_id}/oauth2/token
grant_type: password
client_id: APPLICATION_ID
resource: https://graph.microsoft.com/.default
username: <username#microsoft.com>
password: <password>
Scope : openid
App is created in https://apps.dev.microsoft.com/
Getting Invalid grant error:
{
"error": "invalid_grant",
"error_description": "AADSTS70002: Error validating credentials. AADSTS50126: Invalid username or password\r\nTrace ID: 1ff96bc3-29c8-48f1-b7cc-f77c01525500\r\nCorrelation ID: 9821fdf5-25dc-4b07-84b3-f084194ea123\r\nTimestamp: 2018-09-14 20:04:01Z",
"error_codes": [
70002,
50126
],
"timestamp": "2018-09-14 20:04:01Z",
"trace_id": "1ff96bc3-29c8-48f1-b7cc-f77c01525500",
"correlation_id": "9821fdf5-25dc-4b07-84b3-f084194ea123"
}
UPDATE
Looks like there are more than one issues in play here.
You were using Azure AD token endpoint but had registered your application with Azure AD B2C by mistake (so case 2 as per my original answer).
Now after correcting that one, you should be using clientid and client secret for this new application that is registered with Azure AD.
Make sure you have added Microsoft Graph permissions for your application in Azure AD under "required permissions" and at the end of selecting appropriate permissions, make sure you press on the "Grant Permissions" button to give consent.
Looking at the error message and code you are getting (invalid_grant and "AADSTS70002: Error validating credentials. AADSTS50126"), I tried out ROPC exactly like you from Postman with a test application of my own and I tried multiple different combinations of passing wrong inputs, but the exact error codes you see come only in scenario where either my password or the username is incorrect (as the message says :)). In all other cases, error code will be different.
So, for username - make sure you give fully qualified name e.g. rohitsaigal#mydomain.onmicrosoft.com
for password - pretty obvious.
Give it another try based on instructions above and lets see how it goes.
ORIGINAL ANSWER
App is created in https://apps.dev.microsoft.com/
This means that your application is registered with Azure AD B2C.
Where you have registered your application isn't matching with the token endpoint you are using.
Case 1 - You are looking to use Azure AD B2C
Resource Owner Password Credentials Grant is still in public preview and you will need to follow the instructions provided by Microsoft here -
Configure the resource owner password credentials flow in Azure AD B2C
The endpoint you will hit to get the token will also be different that the one you have mentioned.
https://yourtenant.b2clogin.com/<yourtenant.onmicrosoft.com>/oauth2/v2.0/token?p=B2C_1_ROPC_Auth
Case 2 - You are looking to use Azure AD B2B
In this case you are using the correct end point to get the token, but you have wrongly registered your application with Azure AD B2C, you will need to change that and register your application from Azure Portal.
Instructions and details here - Integrating applications with Azure Active Directory
Just in case you need to read up on differences between Azure AD B2B v/s B2C - look at this SO Post
Here is another useful SO Post that gives information about registering your application through Azure Portal v/s https://apps.dev.microsoft.com (New application registration portal)
It seems like you didn't Grant Permissions to your app. Make sure all of the users are added to the app and ensure that you have the correct web.config parameters.
Also, ensure that the username and password are correct for the managed domain to connect. I've gotten this error before using the incorrect user. A regular azure global admin user may not be able to authenticate. You need to make sure you are using a CSP admin user.
This works https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-ropc-policy?tabs=app-reg-ga&pivots=b2c-user-flow
But keep in mind that there are limitations like:
You cannot use when a password is expired or needs to be changed.
MFA is not supported
Social logins are not supported
I am trying to follow the tutorial here: http://wiki.cloudbees.com/bin/view/Documentation/CloudBeesEclipseToolkit that describes how to configure your eclipse to use the CloudBees subversion respository. When I get to step 2, and try to validate my account username and password, I get:
Failed to validate your account.
Reason:
Failed to get account services info.
Authentication of user: xxxx failed.;
Details -
Unexpected response code:400. Message: Bad Request
I did use my google account (and oauth?) to create my cloudbees account. I am using my google username and password to try to validate.
The account name is what you see when you enter in cloudbees on the top right.
Regarding your missing password this is due to the fact that google and github sign in don't ask user to define a password - that's why you get an authentication failure.
Users can use https://grandcentral.cloudbees.com/account/forgot_password to request password reset and define the password.
I was able to fix this by clicking on the builds sectio of my account. This led me to some pages that told me I didn't have a password with cloudbees, and prompted me to create one.
When I used this password, instead of my gmail one, validation worked.
Also, I had to use my account name minus #gmaail.com to perform svn checkins, which wasn't the most intuative - it's not clear what un/ow and where
We have done a fair amount of work and have come pretty close to getting Jenkins to automatically kick off a build when a push is made into Github. However, Github is logging an error from Jenkins when attempting to post to the Github plugin webhook as follows:
Error 401 Either no such user 'CN=Github Account,OU=Jenkins,OU=Applications,DC=mydomain,DC=com' or incorrect password; nested exception is javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece?]
We have LDAP enabled in our environment to allow for active directory logins. An account called "github" has been created on our domain and authorized as a Jenkins user. We are able to manually login to Jenkins by punching in the username and password for this account and it works as expected. The "github" account has been authorized on the project for READ and BUILD directives on the job.
On Github, the push webhook has the url defined as follows:
http://github:password#jenkins.mydomain.com:8080/github-webhook/
We can confirm that the push event effectively triggers the post to the URL, but the response is a 401 with error details as described above. We know the account is valid and the password is correct, but we are stuck because we cannot understand why Jenkins suggests that it is invalid.
We have used the following link, among many others as a guide:
http://fourkitchens.com/blog/2011/09/20/trigger-jenkins-builds-pushing-github
As far as we can tell, the only difference between our configuration and those of others who have posted about their success on blogs and here on Stackoverflow is our use of LDAP authentication.
Does anyone have any guidance to help us overcome this hurdle? Currently, we can successfully run a build manually, so our communication TO Github FROM Jenkins is tip top. But Github back to Jenkins is a frustrating no-go.
This is now working. Here is what went wrong. When configuring the following string, pay careful attention to both the username and password:
http://github:password#jenkins.mydomain.com:8080/github-webhook/
In our case, the password contained special characters that Jenkins was tripping over. Usernames and passwords with special characters must be URL encoded or the authentication will fail. For example, the following password
!test+pw
must be URL encoded as follows:
%21test%2Bpw
I know this question has been asked a thousand times before and I came across some topics here when doing some Google research about this.
My problem is: I get an Error 10002 - "Security header invalid". I checked the credentials and they are right. I use the live credentials for the live mode and am connecting to the right server and endpoint.
I am using a Paypal class written in PHP. When using it in Sandbox mode it works fine. If I am using it in live mode it shows the checkout as we know it: on the left the item and the total sum and on the right the login screen.
Now I log in with my Paypal account credentials and the API asks me to confirm the purchase. I do so. When it is at the point where it would execute the transaction and redirects to the "Purchase successful" page it suddenly says the above mentioned error.
So I did some testing on my machine with the sandbox account. Assuming that I would use invalid API credentials I would not ever see the checkout (on the left summary on the right login form). But I do. First if I confirm the transaction the API is not okay with the credentials anymore.
How can the credentials first be valid and later on they are invalid? This doesn't make any sense to me. When testing in Sandbox mode everything works fine.
I am using this library:
http://www.php-suit.com/paypal
Help would be highly appreciated as I can't find any explaination for that behaviour anymore. Again: I checked the credentials and they are right.
Best regards,
extrawagant
I'd recommend to double check again the API credentials or the endpoint used.
The error "Error 10002 - Security header invalid" is returned for these common reasons:
Providing the username/password to your actual PayPal account, instead of your API username and API password. We generate your API username and password when you generate your API certificate/signature.
Using the same API information for Sandbox and Live. You need to generate separate API information for your Sandbox and Live accounts.
You have not updated the endpoint to point to PayPal's live API servers.
Trailing or leading white space on any of the characters.
E.g. if you are using the Live Environment endpoint, make sure you are using the credentials created in the Live account. Double check for white spaces when you are pasting into your integration. If you are using the variable "SUBJECT" double check the value inserted.