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.
Security Changes
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.
Deprecation Timeline
- 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.
Contact Us
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.
FAQ
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.
My organization is using git on Linux and are using personal access tokens to access an ADO https server. We have a question about how to interpret the advice in this article. It states in one place that use of PATs is recommended. But then in another place it says SSH is recommended for Linux. What exactly is your advice? For use on Linux, should our first choice be PATs, or SSH?
Sorry about the confusion in our docs. Our recommendation is to use PATs even on Linux.
Can someone suggest how I automate azure work item resolution without using my own PAT in absence of alternate creds?
You can create a service account, log-in with that and generate a PAT for the service account. Have you tried that?
Hi All
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...
Try using the GIT credential manager and see if that helps.
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:...
Hi,
The guide will work with PATs or other authentication methods as well.
Thank you,
Corina
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
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...
Hi Sakura, please post your idea in the developer community so people can upvote it https://developercommunity.visualstudio.com/
Hi Corina,
Can you please link to where the developer community voted to remove alternate credentials?
Hi Corina
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)
Thank you
Hi Corina
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.”
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...
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
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
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...
Hi Matt,
<
p>I think you can specify an empty password in the LibGit2Sharp library.
You just need to replicate this git command:
Thank you,
Corina
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.
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...
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...
@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...