Azure DevOps will no longer support Alternate Credentials authentication
We, the Azure DevOps team, work hard to ensure that your code is protected while enabling you to have friction free access. Until now, we’ve offered customers the ability to use Alternate Credentials in situations where they are connecting to Azure DevOps using legacy tools. While using Alternate Credentials was an easy way to set up authentication access to Azure DevOps, it is also less secure than other alternatives such as personal access tokens (PATs). As such, we believe the use of Alternate Credentials authentication represents a security risk to our customers because they never expire and can’t be scoped to limit access to the Azure DevOps data.
Azure DevOps will stop supporting Alternate Credentials authentication beginning March 2, 2020. The deprecation process will start by disabling and hiding this feature for organizations that are not using Alternate Credentials beginning December 9, 2019. Then starting March 2, 2020 we will gradually turn off this feature for the rest of the organizations, which means that individuals using Alternate Credentials have until then to transition to a more secure authentication method to avoid this breaking change impacting their DevOps workflows.
Will this impact you?
For each organization you belong to, in order to check if you have Alternate Credentials configured, go to the Azure DevOps portal. In the top right corner, open the User Settings menu , then click on the Alternate Credentials menu item.
If you have Alternate Credentials configured in Azure DevOps, you will see it listed. In this case, you should move to another form of authentication by March 2, 2020. We recommend PATs.
- If you are using Alternate Credentials with Git (this is the most common usage scenario), then follow these instructions to set up Git with PATs.
- The recommendation for Linux is to use SSH keys.
- If you are not using Alt Creds with Git and you are not using Linux, please follow these instructions for switching to PATs.
- If you need to refresh tokens programmatically, you can use OAuth.
If you see ‘Secondary Inactive’ or a message stating that Alternate Credentials were disabled for your organization, it means you don’t have Alternate Credentials set in Azure DevOps. There is no action item for you.
- Beginning December 9, 2019 we will disable and hide Alternate Credentials settings for organizations that don’t have Alternate Credentials set. This change will be in effect for all these organizations by December 20, 2019.
- In the coming months we will work with our customers that are still using the feature, to help them switch to another, more secure authentication method.
- March 2, 2020 – Start gradually disabling Alternate Credentials for all Azure DevOps organizations.
If you have any questions, please open a developer community item with the tag
[AltCreds] in the title. For faster service, please search for
[AltCreds] in the developer community forum first, as your question might already be answered. You can reach out to us on Twitter at @AzureDevOps too.
Q: As a user, what happens when Azure DevOps disables Alternate Credentials?
A: The tools that you use to connect to Azure DevOps using Alternate Credentials will stop working.
Q: As a user, how do I know in what scenario I am using Alternate Credentials in a specific organization?
A: We will email you the user agent (if we have it) and the identity that is using it, starting mid-December 2019.
Q: As a user, should I delete my Alternate Credentials for a specific organization?
A: You are not required to, but this is a way to test if anything is broken if you remove them. You can re-enable your Alternate Credentials after completing the test. Save the username and password somewhere before deleting it, just in case.
Q: As an administrator, how do I know if there are active users of Alternate Credentials in my organization?
A: We will email you this information, along with the user agents (if we have this information) and the identities that are using Alternate Credentials, starting mid-December 2019.
Q: As an administrator, should I turn off the alternate Credentials policy?
A: If you want to get this change faster, you can turn the policy off. Turning the policy off is reversible until December 8, 2019. After that, you won’t be able to turn the policy on from the portal. You would need to contact us to do that. (contact info above).
Q: Will this change apply to Azure DevOps Server?
A: No, because we already do not support Alternate Credentials in Azure DevOps Server.
In fact that’s not completely true. Alt IS supported when configuring build agents against a Devops Server (see https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops#required-options). There are currently some issues on *nix platform using only PAT (see https://github.com/microsoft/azure-pipelines-agent/issues/2565#issuecomment-555448786), and sometimes Alt is the only “out-of-the-box” working auth mecanism that works on these platforms. You should clarify support/roadmap about the Alt /Basic support into Devops Server.
Hi, the documentation does not say that Alt Creds are supported when configuring build agents against a Devops Server. The article you referenced addresses Azure DevOps (supports Alt Creds for now) Pipelines too, not only Azure DevOps Server (on prem).
If you have a setup with Alternate Credentials in Azure DevOps Server, we would be interested in seeing that. Please send us screenshots or relevant information at AdoAltCreds@microsoft.com
I’m all for having more secure authentication methods and think this is a step in the right direction. 👍
You also mentioned “while enabling you to have friction free access”. For this change to truly cause less friction, please prioritize this feature request to allow Personal Access Tokens not to expire (https://developercommunity.visualstudio.com/idea/817953/allow-personal-access-tokens-that-do-not-expire.html). Having to track down everywhere a PAT is used and replace it every year is definitely not a “friction free” experience.
Thanks for the update Corina 🙂
Thank you for the feedback Daniel! We will take into consideration the demand for auto renewable PATs.
We also need unexpireable tokens. This is simply nonsense that end users cannot control access!
Can we expect this same level of care and ceremony when build agent platforms get upgraded or when retention settings handling is changed?
The lack of announcements on these kinds of things is far more interrupitve and destructive than a credential system change that is surely less used than build agents and retention settings. That lack of announcement for those creates unexpected “drop what you are working on” level of work interruptions, and they dont get a blog post or any info tips in the UI leading up to it.
If you want to notify people, a blog post is not really the way. This should be either a persistent popup to those who use the feature, or a notification to the affected org admins, or both.
Hi Andrew, I forwarded your message to the Build team. Thank you for sharing your suggestions. Our goal is to make these changes with minimal disruption. In addition to the blog, we are notifying our customers of the Alternate Credentials change by:
– Adding a note to the relevant documentation pages like this one: https://docs.microsoft.com/en-us/azure/devops/repos/git/auth-overview?view=azure-devops
– Displaying banners in the User Settings -> Alternate Credentials and Policy Settings pages. This will roll out to customers by January 2020
– Email campaigns that will start mid December 2019 (please see FAQ above)
@Corina – Are those of us that dont use these alternate credentials going to be bothered by emails and banners telling us about this?
The point I was trying to make was about the disproportionate level of advance notice this is getting compared to other things that are also breaking. Forwarding the message along is appreciated but its not like they haven’t heard the complaints before. Even though I dont use this feature, I like the advance notice and time to react that you are granting for this feature removal. I would like the other changes that come out (whats new each sprint and other non-sprint activities like the build image updates) to be doing this instead of a surprise or a “y u no read release notes?”. Forwarding this process along to the other product/program teams and getting them on board with it should be the minimum level of goodness for communicating updates.
I have a Web API that automates some git actions using the LibGit2Sharp library.
As of now, I’m using Alternate Credentials as tokens in my Azure Build Pipeline, and using these credentials in order to connect to my DevOps repo.
What is the best way forward in this scenario, because the app is hosted in App Service, I am unable to install Git Credential Manager.
I’m also unable to put SSH keys in the correct directory as I do not have direct access to the file system.
Maybe I am missing something, but is my scenario supported?
p>I think you can specify an empty password in the LibGit2Sharp library.
You just need to replicate this git command:
Thank you for the quick response Corina,
I did not realize I can do this, I’ll give it a shot.
Is there any way to refresh a PAT or is this currently a manual process?
Maybe through an API? This was we can programmatically retrieve a new token and work it into our build pipelines.
You’re welcome! Right now renewing PATs is manual. We will take into account the feedback we get on this matter.
Extremely frustrated by this sort of thing. First off, there is no UI that I see in the portal that looks like what you’ve indicated above.
More importantly however, MS is a poor judge of what constitutes good security. If I judge alternate credentials to be adequately secure for my purposes then they are. Theoretically “more secure” is hogwash in most cases because the keys always exist somewhere and someone has access to them. It’s like strict user password requirements that just ensure the user will write them down on unsecured pieces of paper…
I use alternate credentials with a proprietary application that queries changesets for associated bugs to document releases. In this case neither the SSH or git-based alternatives that you link to will work. What do I do?
100% agreed, very bad idea to remove alternate credentials with no replacement with unexpirable PATs…
We have a local automated cross-build system which runs “tf get” command several times a day. How do you want me to handle it now?
Hi Sergey, if you need to refresh tokens programatically, please use OAuth https://docs.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops
Hi Jeff, to see the UI, please try this link after replacing ‘yourOrganizationName’ https://dev.azure.com/yourOrganizationName/_usersSettings/altcreds
For your scenario you should use PATs https://docs.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-5.1&viewFallbackFrom=azure-DevOps
Regarding the deactivation of alternative credentials, I would like to know if it is enough to deactivate the secondary alternative credentials. Because primary alternative credentials do not allow me to deactivate the azure devops platform.
Thanks and regards
Hi, deleting your Alternate Credentials is enough. (from the User Settings page https://dev.azure.com/yourOrganizationName/_usersSettings/altcreds)
The secondary credential is inactive, but the primary one gives me a username and does not allow me to remove that credential.
Hi, then you don’t need to do anything more, thank you! There is a section in the blog: “If you see ‘Secondary Inactive’ or a message stating that Alternate Credentials were disabled for your organization, it means you don’t have Alternate Credentials set in Azure DevOps. There is no action item for you.”
About this change, I think it’s too early for DevOps to deprecate it.
I know there’s some alternative solutions, but, sometimes, it’s a good idea to doesn’t have your key on any place.
For example, if you work on a shared environment, why I want to have a SSH key or a PAT key with access to all my projects? The same are true for deploy projects on final environment.
Maybe a good solution are to support SSH deploy keys assigned to one or more projects (gitlab have these option). I think that’s the best option, because I can push a SSH key on a server, but these key can only read one project.
Hi Sakura, please post your idea in the developer community so people can upvote it https://developercommunity.visualstudio.com/
Can you please link to where the developer community voted to remove alternate credentials?
Hi, how can i change authentication method in my azure agents already created from “alt” to “pat”?
Hi Jefry, the agents use PATs/alt creds only one time for setup. You don’t need to change anything. Agents generate their own SSH keypair to use for future communication. The agents don’t remember that you set them up using alt creds as opposed to any other mechanism https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops&tabs=browser#authentication
Hi DevOps Teams,
My Teams wants to block all access from outside of IP range X, Y, and Z:
– f accessing Azure DevOps via the web, the user is allowed from IP X,Y, and Z. If outside of that list, the user is blocked.
– If accessing Azure DevOps via alt-auth, the user is allowed from IP X,Y, and Z. If outside of that list, the user is blocked.
We inherently follow this guide: https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/manage-conditional-access?view=azure-devops&tabs=preview-page and it uses Alternate Credentials authentication.
Now how can we do that without Alternate Credentials authentication?
The guide will work with PATs or other authentication methods as well.
We are using Jenkins to connect to DevOps we removed the alternate credentials on 2nd March to find out what would break. We have tried to set up a PAT in Jenkins but we cant select it in Source Code Management to authenticate it. We work across 2 domains which is why we had the alternate credentials in the first place and neither password will authenticate in jenkins but i can copy the url it wont authenticate against into chrome and it works fine with the relevant signin.
The error is Failed to connect to repository : Command “git.exe ls-remote -h https://……………………. HEAD” returned status code 128:
stderr: fatal: Authentication failed for ‘https://…………………………………
Any help would be brilliant thanks
Try using the GIT credential manager and see if that helps.