I am having an issue getting my OnPrem Azure DevOps 2019 Server to allow things to authenticate to it with Personal Access Tokens (PAT). No mater what I do, I get failed to authenticate using the supplied token.
How I am creating my token:
Log into my OnPrem devops site
Go to my user profile icon in the top right, click security click personal access tokens, click new token
In Create new personal access toekn for some reasobn the organization (colleciton) I want to use is not listed, I am seeing an old XML based collection but not my new Inheritance based collection, why doesn't the newer format collection show up? My user account is an admin account, you'd think it would be here?
If I create a PAT token for the old XML based collection and give it full access plus a 90 day expiration it creates it fine
Now I have a PAT token bases off the old XML based collection, but that still doesn't work, if I run the AZ CLI I get this
AZ DEVOPS LOGIN --organization https://tfs.mydomain.com/OldXmlCollection --verbose
Token: {paste in token}
Creating connection with personal access token.
Failed to authenticate using the supplied token.
Command ran in 6.385 seconds (init: 0.167, invoke 6.12)
I also have the same problem if I try to set up a build agent using a PAT token. Fails every time, but if I change to negotiate auth it works immediately.
On the IIS end the service is running on the authentication is set up to Anonymous Authentication: Enabled, ASPS.NET Impersonation: Disabled, Basic Authentication: Enabled, Digest and Forms: Disabled and Windows Authentication: Enabled
any ideas what I am doing wrong, what to look at?
PAT Token isn't working on 2019 OnPrem Azure DevOps
You could try to disable IIS Basic Authentication.
That because when IIS Basic Authentication is enabled on your windows machine, it prevents you from using personal access tokens (PATs) as an authentication mechanism.
Please check this document Enabling IIS Basic Authentication invalidates using Personal Access Tokens for some more details.
What it turned out to be is a missing ACL in the file system. The service account that is running TFS needs to have write permission to the machine keys folder at %ProgramData%\Microsoft\Crypto\RSA\MachineKeys
Why in the world is the installer not setting this permission? PAT will not work until this is set
Related
I'm trying to create a release pipeline in DevOps, that releases packages to LCS. The normal Dynamics 365 FO way of working. The issue is, I don't have an admin account without MFA that can be used to do this. Which roles or general setup, should I set on the AAD user, to be able to create the release? Currently I'm getting the AADSTS7000218 error.
I created a user that doesn't have MFA and I expect to add certain roles to be able to use this user for creating releases in DevOps.
In Azure DevOps, to create release pipeline you need "Edit release pipeline" permission set to Allow. And you need to be at least a Basic user.
And as per the document, AADSTS7000218 means The request body must contain the following parameter: 'client_assertion' or 'client_secret'. When authenticating to Azure AD to get an access token, the client application is not providing its “password” (in the form of either a client secret or a client assertion) as expected by Azure AD’s token endpoint.
You could try navigating to Azure Active Directory->App Registration and find Authentication in your application. And set "Allow public client flows" to "Yes" in Azure portal.
Here's another ticket has the similar issue, hope it can help.
If I use a Personal Access Token, I can access all Azure DevOps REST APIS by including the PAT in the header. This works great from NodeJS, PowerShell and curl, but I want to do the same thing from JS running in a web-browser, without any server-side code. Just purely from the JS in the browser.
Now, I could prompt the user to enter their PAT and store it in local storage, but I'd rather not do that. Instead, I'd like to prompt the user to log in and get a token that way. Microsoft has the MSAL library to do that, and they have sample code on how to do this from JavaScript in the browser. Unfortunately, for some reason, they require that you also create an Azure AD Tenant along with a client ID. I don't want to use Azure cloud for anything. I just want my users to access an existing company Azure DevOps server. As I said I can already access these resources using a PAT that the user has to create from the portal themselves. I want to avoid that step and have them log in to get a token. Seems simple enough. Am I missing something?
Why is a tenant even needed for this?
From the doc: https://github.com/AzureAD/microsoft-authentication-library-for-java/wiki
Before using MSAL4J you will have to register your applications with
Azure AD.
In conclusion, to use MSAL to connect to Azure DevOps from vanilla JS in browser, you need to register your App with Azure AD first to acquire the client ID for authorization.
I would like to run frontend end to end test from an azure devops pipeline, the website requires login using azure ad.
Unfortunately it is not easy to automate the login (sometimes involves sending code via email).
I tried using oauth and jwt tokens, but for some reason my app authentication does not recognize it when deployed to azure website.
What is the best way to have access to login protected website from azure pipeline?
Thanks
I think using an orgnization wide AD account is not secure, especially you're in a public cloud, that's why Azure provides a life-time limited project scope account. If you really want to use AD account, save its credentials in Azure Key Vault, then during the pipeline time, retrieve the credentials by the default project scope token, then you can do anything you want with the credentials.
I don't have a lot of experience regarding this, but I've done something similair using a Service Principal or Managed Identity.
I tried using oauth and jwt tokens, but for some reason my app authentication does not recognize
After a while I actually figured out that there was an identity provider configured, and there was kind of double authentication configured. After removing the jwt token started working perfectly.
In any case thanks a lot for your answers!
We've got an install of Azure Devops server that currently authenticates against our active directory server and authentication works, but it appears to do so by means of browser basic authentication (the browser modal prompt that asks for a simple user name and password).
I'm wondering if there is some way to configure authentication such that users that have never logged in, actually get a login page... not just the basic authentication prompt in the browser.
I appreciate any input, I've used and administered azure devops in the cloud for a LONG time, but the devops server stuff I'm new to.
NOTE: I've played with IIS settings for authentication (enabling and disabling basic authentication and forms auth etc, but nothing really seemed to help there)
it appears to do so by means of browser basic authentication (the
browser modal prompt that asks for a simple user name and password).
I'm wondering if there is some way to configure authentication such
that users that have never logged in, actually get a login page... not
just the basic authentication prompt in the browser.
What's the login page do you mean?
1.If you mean the login page to connect to TFS web portal, as I know using basic prompt with username+password is the only appraoch.
Web Portal:
Only logic page:
2.But if you mean something used for authentication when accessing the code. I think you must be familiar with PAT which is widely used in Azure Devops Service. IIS Basic Authentication is not recommended. You can check Enabling IIS Basic Authentication invalidates using Personal Access Tokens and Use the TFS Cross Platform Command Line with TFS using basic authentication or personal access tokens (PATs).
Hope it helps to resolve your puzzle :)
So after lots of research, I found that in the differences between azure devops server and azure devops services documentation. In this documentation it states that it uses windows authentication, and you will never be presented with any login experience.
I'd vote that this should be something that be configured to show a login screen, as sometimes we want to log in as users other than the users we logged into the machine as.
I built a project that uses PAT (Personal Access Token) generated by a user to connect to Azure DevOps REST API and get some data about a project and its commits, etc..
It happened to me twice now that the request returns with:
Access Denied: The Personal Access Token used has expired
Even though the token is not expired yet, it's been created two days ago.
Is there any limitation on using this RestAPI which if I exceeded it'll expire my token automatically?
First, you need to check with the user if the PAT has expired, because Expiration can be customized.
If the PAT confirms that it has not expired, you can try to re-create a new PAT, select All accessible organizations and Full access scope , revoke the previous PAT, and see if the new PAT is available.
In this case with the similar issue, a contributor provided a solution : the user was able to fix it by signing out and back in. This seemed to refresh the auth token and unblocked them. You can also try it .