Jump to content

Win10 Update over SMB


Infractal
 Share

Recommended Posts

We have a SMB file share of our Mirror folder on the RAS server that we use to propigate definition updates internally. With our Win7/2008R2/2012R2 client using a mix of version 4/5 clients, we have no problem getting updates.

 

I started testing out the Win10 tech preview running 5.0.2229.1 client and gave it the same configuration as our other systems to connect to the \\[RAS]\mirror share (Domain Computers and Domain Users have read access) and I get a generic Could Not Connect To Server error. I can browse to it in Windows Explorer no problem, the update.ver and all the .nup files are readable and ready to go, but there's something about this OS that appears to be breaking the ability to update.

 

No idea what is causing it, and if there is some kind of detail client log that I should be enabling to get better information on what is going on then I will give that a shot. But I suspect this is some kind of bug in the client or incompatibility with the new OS, possibly the attempted SMB3 handshake throwing it off.

Link to comment
Share on other sites

  • Administrators

I've just tested update on Windows 10 and after entering valid credentials, I was able to update from a mirror created by ERAS via SMB.

Link to comment
Share on other sites

Yeah, if I I change it to the Current User option or hard-code credentials then I can make it work, but that isn't a good solution. If I use the currently logged in credentials, then it only updates when there is an active user session. If I hard code it, then credentials could possibly be stolen or if they are ever changed I have to go through the work of pushing a new config.

 

Pulling with the System credentials fixes both those problems, and appears to only have problems on this specific OS. The system account is a member of the domain computers account, which has read access to the share and its contents. It's not a permissions issue. I'm looking at a wireshark trace of the traffic when it fails and its extremely weird. The client initializes a SMB connection to the server, the server responds saying it supports SMB2, the client reconnects on SMB2, server sends back the protocol initialization response, and then the client sends a reset packet to the server and the whole thing dies without ever getting to the session setup request.

 

When I change it to use the current user credentials, it gets through the protocol initialization with zero problems and moves on to session setup and then pulls the update.ver file and everything proceeds normally. I don't know why its freaking out and sending resets that kill the connection, maybe there is some new security feature in the OS that is conflicting, but either way Nod32 is the only software I have seen so far that has problem accessing data over SMB, everything else works fine.

Link to comment
Share on other sites

  • Administrators

The thing is ekrn.exe is run in the local system account which means you always have to enter credentials for accessing the network share with a mirror in the update setup. It's always been so and nothing has changed in this regard recently as it's how Windows have always worked. System account has never had permissions to access network shares and my understanding is that giving permissions for it on the server applies only for the local system account on the server, not on clients.

You can test it as follows:

- create a new scheduled task that will run cmd.exe

- run the task manually

- run "whoami". You should get "nt authority\system"

- try to access the mirror from the console window. Access should be denied on any oper. system.

Link to comment
Share on other sites

No, this is an AD-joined system. Processes running as both System and Network Service execute with the token of the computer AD object, which is a member of Domain Computers and has access to the share. Local Service is the only built-in account that accesses network resources anonymously. If what you were saying was true, then domain joined computers would never be able to auth and access group policy data off the domain sysvol share before a user logon, which is not true. Like I said before, I can make this work on pre-Win10 but something screwy is going on here and I doubt I am the only one who is propagating definition updates this way.

 

System command prompt from Win7

PsExec v1.98 - Execute processes remotely

Copyright (C) 2001-2010 Mark Russinovich

Sysinternals - www.sysinternals.com





Microsoft Windows [Version 6.1.7601]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.



C:\Windows\system32>whoami

nt authority\system



C:\Windows\system32>pushd \\nod32\mirror



Z:\>dir update.ver

 Volume in drive Z has no label.

 Volume Serial Number is 4C55-E814



 Directory of Z:\



10/10/2014  02:06 PM            82,342 update.ver

               1 File(s)         82,342 bytes

               0 Dir(s)   7,302,033,408 bytes free



Z:\>

Same thing on Win10 with identical group permissions

PsExec v1.98 - Execute processes remotely

Copyright (C) 2001-2010 Mark Russinovich

Sysinternals - www.sysinternals.com





Microsoft Windows [Version 6.4.9841]

(c) 2014 Microsoft Corporation. All rights reserved.



C:\Windows\system32>whoami

nt authority\system



C:\Windows\system32>pushd \\nod32\mirror

The system cannot contact a domain controller to service the authentication request. Please try again later.



C:\Windows\system32>

I'm guessing Microsoft is ultimately responsible for this and there is some kind of security thing happening under the hood that is breaking things, but since you are a dev partner with them it seems worth pursuing since this is a feature that currently works but might be broken with the upcoming OS. And it isn't a problem with communicating with the DC because all the traffic in wireshark is passing, group policy applies, and domain logons are processing just fine.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...