Azure DevOps with Sourcetree - Adding a remote account
Asked by Derptastic:

I'm trying to add my Azure DevOps remote account to the list of accounts I have in Sourcetree same way as other providers: ![Untitled.png](/t5/image/serverpage/image-id/52312iFF9A5EE277AA5F6D/image-size/large?v=v2&px=999 "Untitled.png")

However, nothing I do seems to work when I try to add a new one (with Azure DevOps selected as Hosting Service):

* I tried with the email and account I use to log in DevOps which greets me with **VS30063 Not authorized** (I have full admin rights).
* I've generated a PAT inside DevOps and used it as a password to the account (as per instruction) which results in: **Failed to check login for \*user\*. Insufficient authentication credentials. Sourcetree could not find password for \*user\* at \*DevOps** **link\*** .![Untitled.png](https://community.atlassian.com/t5/image/serverpage/image-id/52315i7442CED04D96B5B9/image-size/large?v=v2&px=999 "Untitled.png")
* I've also tried using the PAT as a username (and still providing the account password) with the **same result as above.**

What exactly is the procedure for connecting the two, and what exactly is SourceTree expecting as an input for an Azure DevOps account?


Answers:
author: Derptastic
body: ***Edit:*** (as of 24.03.2021) The issue is reported as resolved - see <https://community.atlassian.com/t5/Sourcetree-questions/Azure-DevOps-with-Sourcetree-Adding-a-remote-account/qaq-p/1065001#M38503>

++***Please give this a go, before trying the workaround!***++

***Workaround:***

Apparently (at the time of writing 23.04.2019), when writing the host URL rather than writing:

**[https://dev.azure.com/{orgName}](https://dev.azure.com/*username*)**

one should still write it in the old VSTS link format (even if the organization has been made on DevOps):

**https://{orgName}.visualstudio.com**

When using this as host URL, and then using the account name used to log in DevOps as username and the PAT as password, it's working.

***Edit:*** As of **++28.01.2021++** the issue is still ++**ongoing**++ , and I see more people are finding the answer here. There is an open bug report on it (as *Christian W?lke* pointed out quite some time ago) that seems to be getting some slow progress, but a bump could help reminding them that it's still an active issue: [https://jira.atlassian.com/browse/SRCTREEWIN-10800?workflowName=SourceTree+Bug+Workflow\&stepId=8](https://jira.atlassian.com/browse/SRCTREEWIN-10800?workflowName=SourceTree+Bug+Workflow&stepId=8?)

comments: author: IBrown_BluePrint
body: This is still the case in the SourceTree 3.2.0 Windows beta that is only a few days old. When trying to authorize with <https://dev.azure.com/OrgName>, it seems to succeed in logging in, but fail at gaining Git permissions. Swapping to <https://OrgName.VisualStudio.com> works immediately. Remotes will work fine with the dev.azure.com format after this initial account authorization.  

Any remote repository added using the old Generic Account / Generic Host method (3.1.3 on Windows still had no DevOps integration) should still work if you didn't regenerate the token those remotes use. If, like me, you regenerated your token you use for SourceTree so you could get the password, you will need to edit the DevOps remotes and select the new DevOps Host entry instead of the old Generic Host.

EDIT: v3.4.4 - Spring 2021  
The Azure integration seems to be working okay now. I added a new account to Authentication and used the built-in Azure option and the \`<https://dev.azure.com/OrgName>\` URL for the Host. The only flaky part was actually clicking the button to activate the Personal Access Token; I had to make sure the Host URL field didn't have focus (I clicked every field in order, top to bottom to make the PAT button work). It popped up a login field; I entered my email as user name and the PAT password as my password and after a while it came back Authenticated.   

I can use this to add my repos as remotes and my old, carry-over authentication still works for old repos.


author: Alexander Riggs
body: After trying an failing many times, this worked for me as well!


author: Pitterling
body: same for me ... dev.azure.com link DON't work :(


author: Krisztian Ferencz
body: Same for me, it only worked with <https://OrgName.visualstudio.com>.


author: Justin Swenson
body: This worked for me as well with the Personal Access Token.


author: RobertDAltman
body: Ok, so I fought with this for the entire afternoon until I figured out (a) where to find my "OrgName", and (b) specifically what to enter for the URL.

In the Azure DevOps portal, it tells me that my repository is at a URL like this:

https://**MyCompanyName**\[at\]dev.azure.com/\<a bunch more stuff\>

So, the URL that worked for me was:

https://**MyCompanyName**.visualstudio.com

The part that had me messed up is that it doesn't want anything other than this "base" URL (subdomain dot host). Don't include any of the navigation stuff after the slash.


author: Alex Blokha
body: Well, The bug is still here and the solution worked for me in December of 2020.


author: Richard Davis
body: Worked for me 21/12/2020,


author: Securator
body: Same for me 22/12/2020


author: Stephan Geissb?hler
body: Even in 2021 it's still the way to go :D


author: albstr
body: This worked for me half the way, was able to add account but not pull/push code to new dev.azure.com adresses...


author: lucasda2
body: [@albstr](/t5/user/viewprofilepage/user-id/4523400) I had the same exact problem. I found Andrzej's solution [here](https://community.atlassian.com/t5/Sourcetree-questions/Azure-DevOps-with-Sourcetree-Adding-a-remote-account/qaq-p/1065001#M38503), and everything now seems to be working for me:

1) remove all "remote accounts" for that server (well, I wasn't even able to create one)

2) Switch SourceTree to "system" git in Tools -\> Options -\> Git -\> Git Version (at the bottom)

3) Close SourceTree

4) Reinstall GIT with an option "Git Credential Manager Core" enabled (!)

5) Start SourceTree

6) Clone repo and there should be an external modal dialog for authentication to the TFS. Just use normal credentials. No need for external account setup.

For me, step 2 was all I really needed, and suddenly everything worked.


author: Dong Wang
body: I use this way, I mean system git with credential manager, and everything is back to ok now. Thanks


author: Bilal Ben Mossa _ JEX
body: +1 for changing to system (actionpoint 2)


author: augmity-git
body: Thanks [lucasda](https://community.atlassian.com/t5/user/viewprofilepage/user-id/4532844) - changing to "system" fixed the issue!


author: IbrahimMD
body: **You will try, and think you are not successful, but you are really near from it ! follow with me:**

I am using SourceTree for Windows version 3.2.6

1- Tools -\> Options -\> Authentication

2- Remove all Visual Studio (or DevOps). Click Ok.

3- Close SouceTree completely. I closed Visual Studio as well, just in case !

3.5 - I switched to DevOps format from Organization settings in DevOps website. So, if you want to follow exactly what I did, do it. Currently it is possible to return back to old format xxx.visualstudio.com. It is your decision !

4- Open SourceTree, go again to Tools -\> Options -\> Authentication.

5- Enter Host URL as follows: <https://dev.azure.com/YourOrgName>

6- Prepare your new Personal Access Token, then click "Refresh Personal Access Token" button. Ensure you have this token saved somewhere ++TEMPORARILY++ because we will need it.

7- Enter your email as username, and the just generated PAT as password.

**It will tell you it failed, do not worry it did not !**

8- Click Ok then Close SourceTree Completely.

9- Remove the password cache file called "passwd" in "C:\\Users\\{YOUR_USER_NAME}\\AppData\\Local\\Atlassian\\SourceTree".

10- Open sourcetree again. You can go again to Authentication of SourceTree and see your account has actually been added !

11- Ensure that your repository setting of your git is correctly formatted (<https://dev.azure.com/YourOrgName/Project/_git/>......)

12- You will notice a new password window shows up asking for password, Enter the same Token which you used it earlier. Note that this password will be cached. You might get the same window when you Fetch anther repository. That is why we saved the token temporarily.

13- Fetch your repos, it should work now. Congratulations !

14- Do not forget to remove the TEMPORARILY saved token (if you saved it somewhere) which can be stolen and used to access your account. I mean that copy-pasted token.

comments: author: JMIC123
body: these instructions worked for me.

Thank you


author: Christian Schmid
body: This workes perfectly for me, thank you very much!


author: Christian W?lke
body: It works for git authentication, but not for azure devops organization authentication to use the remote account function, to clone a repository, this works only with the old URL:  

![RemoteAccount.png](https://community.atlassian.com/t5/image/serverpage/image-id/74475i2DE5AB5950C6D656/image-size/large?v=v2&px=999 "RemoteAccount.png")


author: Justin Swenson
body: 9- Remove the password cache file called "passwd" in "C:\\Users\\{YOUR_USER_NAME}\\AppData\\Local\\Atlassian"

That file doesn't exist for me.


author: menortech
body: [@Justin Swenson](/t5/user/viewprofilepage/user-id/3703199)

check "C:\\Users\\{YOUR_USER_NAME}\\AppData\\Local\\Atlassian\\SourceTree"

When sourcetree works, it's great. But this is really making me want to choose another tool


author: Goran
body: Worked perfectly for me. Followed every step except 3.5  
Thank you!


author: Rafael Chagas
body: Few years ago I spent few minutes to download, install and start to use this tool.

Now I am spending 2 days to create an account and still is not working. It does not make any sense.


author: dagillespie
body: [@IbrahimMD](/t5/user/viewprofilepage/user-id/3616906) - thanks however that's not working right now on my machine.

[@Derptastic](/t5/user/viewprofilepage/user-id/988469) - thanks however whilst I can set up my account correctly, when cloning a repo, it fails to authenticate.

This appears to still a broken feature in at least the windows client.

For Mac, I made it work by using the old domain and my PAT as both username and password.

On Windows this doesn't seem like it works as it always defaults to your devOps username rather than allowing you to use your PAT.

Any suggestions on this?

Really like sourcetree however reconsidering it as a client if this can't be resolved - particularly as this has been a known issue for over a year.


author: Derptastic
body: [@dagillespie](/t5/user/viewprofilepage/user-id/2670307) I'm using the windows client and so is everyone in my company - and we got it working for all. Therefore I can't back the statement that the windows client is broken, even if it's an unnecessary pain in the ass to set-up.  

As for the second part - AFAIK on the Windows client you *are*expected to use your DevOps username and use the PAT only as a password. At this point there's not much I can recommend besides double checking the set-up you have as well as your permissions within DevOps itself for the repositories it fails to clone (if you have Read/Write access). I know we occasionally have to double check those, especially for newly created projects.


author: dagillespie
body: Using DevOps username and PAT allows user authentication as a remote account (where the client should have been updated by now to use the new URL) and you can see a list of repos under remote, cloning these still fails as the client authenticates the account with the old style URL and tries to use the new URL for cloning the repo - where authentication fails.

You can however clone a repo, given a URL from DevOps - which is an inconsistent behaviour.

I would consider the client still broken as this is by no means the way that this process was intended to work, isn't straight forward to do and a work around is not a fix to a problem in a piece of software, just a temporary measure.


author: Yuan Zhou
body: It worked for me.

However next repo set-up took the same effort which is absurd!


author: Venkatesan Natarajan
body: @[IbrahimMD Thank you ! it worked for me..](https://community.atlassian.com/t5/user/viewprofilepage/user-id/3616906)


author: gabhijithg
body: Thank you very much. Finally this solution hot worked.


author: albstr
body: This actually worked!! Many thanks!


author: Andrzej
body: My solution:

1) remove all "remote accounts" for that server (well, I wasn't even able to create one)

2) Switch SourceTree to "system" git in Options

3) Close SourceTree

4) Reinstall GIT with an option "Git Credential Manager Core" enabled (!)

5) Start SourceTree

6) Clone repo and there should be an external modal dialog for authentication to the TFS. Just use normal credentials. No need for external account setup.

comments: author: Michael Lant
body: Thank you!

This is the only thing that has worked and I have been trying for over a year to solve this problem!


author: lucasda2
body: Agreed, the embedded Git that shipped with Sourcetree seems to be the root cause of my issues. As soon as I switched to the newer Git on my system, everything immediately started to work.


author: rlew23
body: 1) Create PAT at DevOps, copy off the token

2)\*\*\* Clear the CACHE \*\*\* OSX: /Users/rlew/Library/Application Support/SourceTree

3) Set up the account in SourceTree with [https://orgname.visualstudio.com](https://orgname.visualstudio.com/) like everyone else

4) Celebrate!!... then dry cry that I just lost 3 hours of my life on step #2

comments: author: adrielairaldo
body: Thanks buddy!


author: Jonas P?ckos
body: Still works like a charm in 2023!


author: dagillespie
body: I would suggest this item is not solved.


author: Christian W?lke
body: There is a bug for that topic. Please vote for it, to solve asap:  

[Authentication fails when using Azure DevOps URL](https://jira.atlassian.com/browse/SRCTREEWIN-10800?workflowName=SourceTree+Bug+Workflow&stepId=8 "https://jira.atlassian.com/browse/srctreewin-10800?workflowname=sourcetree+bug+workflow&stepid=8")

Thank you


author: chriswoel
body: As this topis is still a problem and really annoying, we decided to go with VSCode and its extensions for git.   
Really power full and better performance than sourcetree.

comments: author: Pavel Horyna
body: I agree, there are so many bugs and probles with SourceTree, it's not worth it. We used SC for years, and the integration with Azure DevOps never worked well and only gotten worse over time.

It's abandonware.


author: Jair Alejandro
body: I removed all the Sourcetree password from the keychain and thats worked form me.

NOTE: I follow all the steps and then remove the passwords


author: SRB1981
body: I give up, I'll find another tool.

I configured Visual Studio 2019 with Azure DevOps in a few minutes, and now I've spent too much time trying to configure SourceTree. The login with PAT is okay, but when I try to Pull from repository it fails.

Even if I found a workaround, I would consider this software unreliable because tomorrow it could give other troubles. Have a nice life.

PS: computer programs are meant to make our lives easy.

comments: author: menortech
body: Right after I posted a solution to my problem last year (Feb 2020), I abandoned ST last year and paid for Fork @ fork.dev. Works with Azure DevOps and github. None of this nonsense. Worth a small bit of money to save my sanity.


author: Christian W?lke
body: The issue is solved, you need to install the newest version  
[https://jira.atlassian.com/browse/SRCTREEWIN-10800?focusedCommentId=2664058\&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2664058](https://jira.atlassian.com/browse/SRCTREEWIN-10800?focusedCommentId=2664058&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-2664058)

comments: author: Derptastic
body: I am, unfortunately, unable to confirm for the time being, has anyone else been able (at latest SourceTree version) to authenticate using: **[https://dev.azure.com/{orgName}](https://dev.azure.com/*username*)**


author: Christian W?lke
body: [@Derptastic](/t5/user/viewprofilepage/user-id/988469) Do you have version 3.4.3?  
I have tested it succesfully, also all my collegues have confirmed that the authentication works.  

![SNAG_20210329_073847.png](https://community.atlassian.com/t5/image/serverpage/image-id/136364iD85F3DA4E83CDD9F/image-size/large?v=v2&px=999 "SNAG_20210329_073847.png")


author: Derptastic
body: [@Christian W?lke](/t5/user/viewprofilepage/user-id/1805276) Apologies, I was unclear. My comment wasn't because the solution is not working for me, the reason is much more trivial - I have since stopped working for the company I was using the account with, and I don't have a personal AzDo account to verify the solution personally, hence my question.


author: Gregory Herrmann
body: The only way I can get SourceTree on my Mac to connect to DevOps is when adding the account, instead of using my devops username and password, I had to enter in a PAT (personal access token) generated in devops. And of course they expires within a year. so that will be fun to maintain.

comments: author: RobertDAltman
body: \> And of course \[the PAT\] expires within a year...

Actually, you control the expiration date on the PAT. And, yes, longer expiration dates are more convenient. Azure DevOps is good about sending you an email before your PAT expires, so you can proactively regenerate the PAT and go back through the exercise of teaching SourceTree about the new PAT.

I assume (I'm not an expert in this subject) that a PAT is some variation on a public/private key pair. When you create or regenerate a PAT, the code that Azure Devops displays (and tells you to copy because they don't keep a record of it and can't reproduce it later) is your public/private key pair. So, Azure DevOps securely (we assume) stores their public and private keys for the PAT, and SourceTree stores your public and private keys. When you log in, SourceTree exchanges public keys with Azure DevOps (that is, the public keys associated with the PAT), and both ends use their associated private keys to decrypt the message traffic between SourceTree and Azure DevOps.

The point of this "mansplaining" is to give some context to the burning question that you alluded to: Can I give my PAT a 5-year expiration and not have to deal with it for a while? The answer, I guess, comes down to (1) can someone somehow get your key pair for that PAT (or, more specifically, your private key) from SourceTree on your development computer, or (2) can someone somehow compromise the entire public/private key thing for your conversation between SourceTree and Azure DevOps? If either of those bad things happens then you will be happy to have the PAT become invalid. Does rotating the PAT on some schedule (every 6 months, every year, every 5 years) actually help in either scenario? I doubt it. If a bad guys compromises your PAT, having it automatically expire 3 months later doesn't help much.

By my (questionable) analysis, you might as well give your PAT as long an expiration period as Azure DevOps will allow. The underlying encryption is as secure as your private key (stored by SourceTree). The moment that private key and its associated public key (much easier to see since it is transmitted unencrypted) is stolen by any means, the bad guy has as much access to your Azure DevOps data as you have authorized when you set up the PAT.


author: Gregory Herrmann
body: Thanks for the reply "mansplaining" :)

DevOps only gives me a 1 year max expiration. But it is what it is. Im not sure why SourceTree asks for my DevOps username/password by the text labels on the login form, but actually requires it as the PAT.


author: RobertDAltman
body: Somewhere in the Atlassian docs, there is a page that clearly states that, in order to wire up Azure DevOps, you can enter any username, but you must enter that PAT code as the password. The failure in this case is that SourceTree doesn't help us get to that nugget of information when we are trying to set up the connection between SourceTree and Azure DevOps.


author: Kevin Woo
body: I've updated to SourceTree 3.4.10 and still needed to set up the account in SourceTree with [https://orgname.visualstudio.com](https://orgname.visualstudio.com/) like everyone else.


author: Raluca Pandaru
body: I have the same issue with my Azure DevOps remote account. I was able to solve this issue by installing git on Windows system (and git LFS if you need it). I reinstalled SourceTree and during the installation I unchecked the using of git credential helper. Normally, if you install git and git LFS before SourceTree, SourceTree will use the git and git LFS found on Windows system. You can check that by going to **Tools -\> Options -\> Git** . Lower in the pop up window at **Git Version** section make sure that **System** option is checked and not **Embedded** . If you don't want to reinstall SourceTree, just select **System** option and browse to the location of your git installation.  

After that, you don't need to manually add an account. Just go and clone a repository. Before starting the cloning, SourceTree, via git, will ask you for your user and password. You can check the box which says remember my credentials or something like this.

comments: author: blessy_alexander
body: Thank you [@Raluca Pandaru](/t5/user/viewprofilepage/user-id/4852216). You saved my day!


author: Glenn Dominguez
body: This worked for me. My laptop thanks you for not getting thrown out of a window.


author: Hieu Le Van
body: I'm using PAT and token login successfull this morning. But cannot use SourceTreee with DevOps. Please help.


author: Bruce Mcleod
body: There are no answers on how to deal with in house DevOps. If you have this setup here is a suggestion -

- Make your Master branch the branch that requires a pull request

- Push your local changes to the relevant branch on your DevOps server

- Use Devops to create the Pull Request into Master

- Continue using SourceTree :-)

I had thought this was a show stopper but this is a simple workaround, arguably not even a workaround.


author: balyan10
body: It worked like charm. Issue persists as of today.


author: Manendra Pratap
body: You are amazing. Nothing else worked. And this worked like a charm. you saved my day .


author: kumaresh somi
body: As of 09-October-2020, Sourcetree version 3.3.9 on Windows, this problem can be worked around by configuring the host URL as <https://orgname.visualstudio.com> and selecting HTTPS as preferred protocol.

Click refresh PAT and provide your domain username and the PAT as password.

Be careful to configure the proxy correctly if you are sitting behind one.

The host url dev.azure.com still does not work !

comments: author: Jeff Gonzales
body: This helps me create the remote account, but after that I try to access the repo I get an "Authentication failed" error.


Tags: account

atl-gruland

azure

devops

language-ja

remote