Windows 10 Security Update breaks TSVN Auth?

[Per Salmi]

Hi!

Are there any TSVN users out there that have ran into trouble using TSVN during the last couple of weeks since installing Windows 10 Security Update KB3193494 or KB3189866?

The scenario is that installing any of these updates seems to break TSVN authentication.
Trying to checkout or update results in "Error running context: An error occurred during authentication", while right-click -> Repo Browser on an existing working copy shows an incomplete repo browser view with a few folders but no files.

This is when the repo is on a server using Windows authentication and the users are working on machines that are on the same network but not members of the same domain. Before the security patches this gave a username/password popup when trying SVN operations and after entering the correct DOMAIN\user + password the operations completed without any problems. Now after the updates there is no user/password dialog, the operations just fails immediately. It looks like the TSVN client just tries to authenticate with the user logged into the Windows 10 machine, in this case Microsoft Accounts that are not part of the windows domain without letting the user enter any other credentials.

We are using TSVN 1.9.4 build 27285 on Windows 10 x64 with Anniversary Update and we have reproduced this behavior on multiple machines with the same security updates.

/Per Salmi

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3187373

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[Pavel Lyalyakin]

Hello Per,

On Tue, Sep 27, 2016 at 3:59 PM, Per Salmi <per....@gmail.com> wrote:

Hi!

Are there any TSVN users out there that have ran into trouble using TSVN during the last couple of weeks since installing Windows 10 Security Update KB3193494 or KB3189866?

Are you sure that this behavior is related to those Windows Updates? I really doubt that this issue has anything to do with those updates. Does it reproduce on any other non-domain machine with Windows 7 or Windows 8.1?
 

The scenario is that installing any of these updates seems to break TSVN authentication.
Trying to checkout or update results in "Error running context: An error occurred during authentication", while right-click -> Repo Browser on an existing working copy shows an incomplete repo browser view with a few folders but no files.

This is when the repo is on a server using Windows authentication and the users are working on machines that are on the same network but not members of the same domain. Before the security patches this gave a username/password popup when trying SVN operations and after entering the correct DOMAIN\user + password the operations completed without any problems. Now after the updates there is no user/password dialog, the operations just fails immediately. It looks like the TSVN client just tries to authenticate with the user logged into the Windows 10 machine, in this case Microsoft Accounts that are not part of the windows domain without letting the user enter any other credentials.

We are using TSVN 1.9.4 build 27285 on Windows 10 x64 with Anniversary Update and we have reproduced this behavior on multiple machines with the same security updates.

I can guess that by "Windows authentication" you mean Integrated Windows Authentication (IWA). Right? Have you recently switched to using IWA? The behavior could occur if you switched to IWA from Basic authentication. Basic auth will prompt users for credentials, but IWA does not.

In such case, you should use Windows Credential Manager on non-domain machines. The users should put their account's credentials to access VisualSVN Server into Windows Credential Manager:

1. Start Control Panel | Credential Manager.
2. Click Add a Windows Credential.
3. As Internet or network address enter the FQDN of VisualSVN Server's machine.
4. As Username enter your domain account's username in DOMAIN\Username format.
5. Complete the password field and click OK.

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

[Per Salmi]

> > Are there any TSVN users out there that have ran into trouble using TSVN
> > during the last couple of weeks since installing Windows 10 Security Update
> > KB3193494 or KB3189866?
> >
>
> Are you sure that this behavior is related to those Windows Updates? I
> really doubt that this issue has anything to do with those updates. Does it
> reproduce on any other non-domain machine with Windows 7 or Windows 8.1?

The authentication works again if we uninstall the security updates, whichever of them that got installed. But KB3193494, as it is a replacement for KB3189866, will automatically be reinstalled again as soon as Windows Update runs again... so it is not a very good workaround.
We do not have any non-domain Windows 7 och 8.1 clients available to test with. Some domain-joined ones are around and then the authentication works.

> I can guess that by "Windows authentication" you mean Integrated Windows

> Authentication <https://www.visualsvn.com/server/features/windows-auth/>
> (IWA). Right?

The server is 1.8.x from a WANDisco distribution, server config says the authentication is set to SSPIAuth, and also should offer basic authentication because of some other clients.

>Have you recently switched to using IWA? The behavior could
> occur if you switched to IWA from Basic authentication. Basic auth will
> prompt users for credentials, but IWA does not.

No changes have been made to the server side at all when this problem occurred.

> In such case, you should use Windows Credential Manager on non-domain
> machines. The users should put their account's credentials to access
> VisualSVN Server into Windows Credential Manager:
>

> 1. Start *Control Panel | Credential Manager*.
> 2. Click *Add a Windows Credential*.
> 3. As *Internet or network address* enter the FQDN of VisualSVN Server's
> machine.
> 4. As *Username* enter your domain account's username in DOMAIN\Username
> format.
> 5. Complete the password field and click *OK*.

Tried this as a workaround but still get the same authentication error message, the FQDN, user and password was already in the credential manager. Tried removing and reentering info. No success.

/Per

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3187378

[Per Salmi]

Could the fact that the server is using HTTP on port 8080 be a part of the problem here?

No SSL/HTTPS is used.

/Per

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3187380

[Stefan Küng]

On 27.09.2016 15:52, Per Salmi wrote:
>>> Are there any TSVN users out there that have ran into trouble using TSVN
>>> during the last couple of weeks since installing Windows 10 Security Update
>>> KB3193494 or KB3189866?
>>>
>>
>> Are you sure that this behavior is related to those Windows Updates? I
>> really doubt that this issue has anything to do with those updates. Does it
>> reproduce on any other non-domain machine with Windows 7 or Windows 8.1?
>
> The authentication works again if we uninstall the security updates, whichever of them that got installed. But KB3193494, as it is a replacement for KB3189866, will automatically be reinstalled again as soon as Windows Update runs again... so it is not a very good workaround.
> We do not have any non-domain Windows 7 och 8.1 clients available to test with. Some domain-joined ones are around and then the authentication works.

Looking at the changes done in that update, we'll find this:
https://technet.microsoft.com/library/security/MS16-110

"preventing NT LAN Manager (NTLM) Single Sign-On (SSO) authentication to
non-private SMB resources when users are signed in to Windows via a
Microsoft Account (https://www.microsoft.com/account) and connected to a
“Guest or public networks” firewall profile."

And since SSPI is using NTLM auth, I'm guessing that's your problem.

so, to fix this you have to correct what the KB update now prevents:
* make the SMB private
* don't connect to a public network but only a private one

Sorry, but you have to figure out how to do that yourself - only you
know your setup.

Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3187406

[Per Salmi]

> > The authentication works again if we uninstall the security updates, whichever of them that got installed. But KB3193494, as it is a replacement for KB3189866, will automatically be reinstalled again as soon as Windows Update runs again... so it is not a very good workaround.
>

> Looking at the changes done in that update, we'll find this:
> https://technet.microsoft.com/library/security/MS16-110
>
> "preventing NT LAN Manager (NTLM) Single Sign-On (SSO) authentication to
> non-private SMB resources when users are signed in to Windows via a
> Microsoft Account (https://www.microsoft.com/account) and connected to a
> “Guest or public networks” firewall profile."
>
> And since SSPI is using NTLM auth, I'm guessing that's your problem.
>
> so, to fix this you have to correct what the KB update now prevents:
> * make the SMB private
> * don't connect to a public network but only a private one
>

Thanks! Will try it as soon as I'm back at the office tomorrow. Very likely that I didn't set that network to be a private network!

/Per

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3187420

[Per Salmi]

> And since SSPI is using NTLM auth, I'm guessing that's your problem.
>
> so, to fix this you have to correct what the KB update now prevents:
> * make the SMB private
> * don't connect to a public network but only a private one

Bad news... Checked the network profile this morning and it was set to private all the time, so there is something that makes the authentication fail anyway also for private networks in this security update.

/Per

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3187467

[cpm2]

Finally! Your report and the subsequent analysis have explained to me why I cannot access my SVN servers any more. Thank you.

My machine updated to the AU last week and I have been locked out ever since.

Were you able to solve the problem?

C

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3189848

[cpm2]

I got into my code repo by doing 3 things

1. Mark my unidentified VPN network as a private network using secpol.msc (specify that all unidentified networks are private by default)
(See the Feb 12, 2016 reply here: http://answers.microsoft.com/en-us/windows/forum/windows_8-networking/cant-change-network-type-in-windows-8/2d07a961-62e5-4d0b-926f-0e2f63116b02?page=2)

2. Use a command prompt to make a NETONLY login to my box using the domain ID and password (this does not require my machine to be domain-attached):
D:\Code>runas /netonly /user:DOMAIN\user cmd
Enter the password for DOMAIN\user:
Attempting to start cmd as user "DOMAIN\user" ...

3. When the command prompt appears, navigate to a new code directory, and execute an SVN command:
svn checkout URL .

That got my code.

What a pain in the neck!

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3189853

[Per Salmi]

Well, I didn't find any solution other than that I had to join the computer to the domain.

Your runas /netonly trick works partially as when I use that I do not have to switch to my domain user to work with SVN. With "runas" I can run VS 2015 as the domain user and and use AnkhSVN or command line tools to update or commit, while logged into the desktop as my Microsoft Account user.

Still got problems as I would not like to join the customers domain when working with SVN as I am a consultant working with multiple networks and customers. So the domain join and runas is a workaround that gives back access in command prompt but not a solution for TortoiseSVN Explorer shell integration.

Thanks for the "runas" suggestion!

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3189880

[Per Salmi]

Hi!
Did you ever find a solution that makes Tortoise SVN work on Windows 10 clients that are not members of the domain?

/Per

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3221421

[cy...@crua.net]

> Did you ever find a solution that makes Tortoise SVN work on Windows 10 clients that are not members of the domain?

Hi

I realise this is an old thread but some, like me, may still be looking for workarounds. I've managed to get most functionality back by doing 2 things:

1. Run TortoiseProc.exe with runas at startup:

In Registry Editor:
go to "Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run"
change the "TortoiseSVN Monitor" data to: runas /netonly /user:DOMAIN\USERNAME "C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe /tray"

(replace the DOMAIN and USERNAME values, and check that the path to TortoiseProc.exe is valid for your system)

Restart the machine and type your password when prompted. The TortoiseSVN Project Monitor in the notification area taskbar will now be running with the runas credentials. This enables checking logs and updating working copies, but not performing commits. To enable commits in Explorer you can then:

2. Create a "Send To" batch script
browse to %AppData%\Microsoft\Windows\SendTo
create a new batch file called "SVN commit.bat" and add the following line: runas /netonly /user:DOMAIN\USERNAME "TortoiseProc.exe /command:commit /path:\"%~dp1\""

To perform a commit in Explorer just go to your working copy, right click any existing file, and select Send to > SVN commit.bat

Cyril