Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change service's default user to Network Service. #72

Open
GoogleCodeExporter opened this issue Apr 4, 2015 · 10 comments
Open

Change service's default user to Network Service. #72

GoogleCodeExporter opened this issue Apr 4, 2015 · 10 comments

Comments

@GoogleCodeExporter
Copy link

I suggest that you might consider making wpkg-gp do the following

1. Change the default user that the wpkg-service runs under to "NT 
Authority\Network Service"
2.
3.

The reason I suggest this is that:

In most scenarios where WPKG-GP is used, WPKG.JS and the software repositories 
are on file shares. Technically speaking LocalSystem can't/shouldn't/won't 
access network shares and may not be the optimum choice of accounts to use as a 
default for the wpkg-service.

 More specifically, LocalSystem can authenticate properly, but only  under certain circumstances (before it defaults back to contacting servers as a null session and needs server administrators to add anonymous access to shares).

 "NT Authority\Network Service" has more complete access to the network and authenticates reliably as <domain>\<machinename>$ in a lot more scenarios. As it's still effectively the LocalSystem account (when it comes down to having administration rights), it might be a better account to default WPKG-gp's service to use :-)

Keith

Original issue reported on code.google.com by kej.andr...@gmail.com on 9 Sep 2011 at 10:20

@GoogleCodeExporter
Copy link
Author

Would you please test this by changing the service account user in your 
environment, and report back if it works as expected?

Original comment by clei...@gmail.com on 10 Sep 2011 at 7:30

  • Changed state: Accepted

@GoogleCodeExporter
Copy link
Author

According to http://msdn.microsoft.com/en-us/library/ms143504.aspx:

Local Service Account

The Local Service account is a built-in account that has the same level of 
access to resources and objects as members of the Users group. This limited 
access helps safeguard the system if individual services or processes are 
compromised. Services that run as the Local Service account access network 
resources as a null session without credentials. Be aware that the Local 
Service account is not supported for the SQL Server or SQL Server Agent 
services. The actual name of the account is "NT AUTHORITY\LOCAL SERVICE".
Network Service Account

The Network Service account is a built-in account that has more access to 
resources and objects than members of the Users group. Services that run as the 
Network Service account access network resources by using the credentials of 
the computer account. The actual name of the account is "NT AUTHORITY\NETWORK 
SERVICE".
Local System Account

Local System is a very high-privileged built-in account. It has extensive 
privileges on the local system and acts as the computer on the network. The 
actual name of the account is "NT AUTHORITY\SYSTEM".

Neither says anything about the security tokens granted to each of the users, 
but we need some pretty "high-hanging" ones, like the reboot computer and 
impersonate other users.

Original comment by clei...@gmail.com on 11 Sep 2011 at 7:15

@GoogleCodeExporter
Copy link
Author

Hi,

 Sorry, that was very confusingly written and I definately put the wrong spin on it (more coffee please!). Doh! {Note to self re-read things more than 3 times before hitting save}. Actually you probably should have caught me on the idea that "Network Service" doesn't have any ACL access to %PROGRAMFILES%, or to COM+ settings or to half the registry... Doh! I see what you mean!

 I shouldn't have said "run the service under" the Network Service or implied anything like that. That gave you the wrong impression totally. I'll write a bit clearer in future! Promise!

 I should have been suggesting wpkgservice should impersonate/use Network service to make a connection to the network rather than skipping the network connection and relying on LocalSystem's access (in the absence of other user credentials). I got tied up trying to avoid problems tinkering with code that could possibly be called directly by a priviliged user and mean access might be implicitly layered on top of their permissions. It's all a bit complex in my head still! :-}

 I tried tweaking your code so it would take "NT Authority\Network Service" and use None for a password to make a connection to the WPKG script source. (I literally specified "NT Authority\Network Service" as the user and an empty password in wpkg-gp.ini, then modified the python code so it used None as the password when it attempted the "user connection" rather than self.Network_Password)

ie
  win32wnet.WNetAddConnection2(win32netcon.RESOURCETYPE_DISK, None, self.network_share, None, self.network_username, None, 0)   

 This accessed the share in question without me needing to add anonymous access to the server (it just relied on giving "Domain Computers" read access on the ACL for the folder) and has been running quite reliably and predictably :-)

 Given 20-20 hindsight on my screwups in explanation, would it be worth testing the idea of having the service check to see if it's running as LocalSystem and if so, creating a a connection as you would for a user but using "Network Service" as the user?

 Ummm.. does that make a more sensible pitch?

Keith


Original comment by kej.andr...@gmail.com on 12 Sep 2011 at 8:42

@GoogleCodeExporter
Copy link
Author

I think that the system account impersonates the computer account on the 
network as well, doesn't it?

Anyway, your fix is partly the fix I committed in r250, which allows the 
service user to connect to the network as itself if no username/password is 
provided.

Original comment by clei...@gmail.com on 14 Sep 2011 at 3:59

@GoogleCodeExporter
Copy link
Author

Could you please check if the service impersonates as Computer Account in newly 
released version 0.15?

Original comment by clei...@gmail.com on 15 Sep 2011 at 2:06

@GoogleCodeExporter
Copy link
Author

Original comment by clei...@gmail.com on 29 May 2012 at 2:43

  • Changed state: NoFeedback

@GoogleCodeExporter
Copy link
Author

I checked this with v0.17, and when there is no username provided, the service 
attempts to authenticate as "NULL". Verified with a wireshark capture:

--
NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_AUTH (0x00000003)
Lan Manager Response: 00
NTLM Response: Empty
Domain name: NULL
User name: NULL
Host name: PC01
Session Key: Empty
--

Proposed patch by Keith looks fine IMHO. Also the documentation needs to be 
updated. I know the MS article says so, but obviously we are missing something 
because packet captures are showing the SYSTEM account is *not* authenticating 
as the computer account in this case but as a NULL session.

Best regards!!

Original comment by jorgito1...@gmail.com on 17 Aug 2014 at 7:12

@GoogleCodeExporter
Copy link
Author

Original comment by sao.es...@gmail.com on 19 Aug 2014 at 6:42

  • Changed state: New

@GoogleCodeExporter
Copy link
Author

AFAIK the account "NT Authority\Network Service" does not have the 
administrative rights required to install applications, which is by design. 
Using the SYSTEM account, as it is currently implemented in WPkg-GP, is the 
only viable option. And when it connects to network shares, it is mapped to the 
computer account in AD by Windows automatically.

In my experience, it works fine with both Kerberos in Active Directory domains 
and NTLM in NT4 domains. Both username and password are commented out in my 
Wpkg-gp.ini:

#WpkgNetworkUsername = 
#WpkgNetworkPassword = 

Original comment by mgr...@gmail.com on 16 Jan 2015 at 11:05

@GoogleCodeExporter
Copy link
Author

NetworkService indeed does not have administrative privileges on the local 
computer. I believe that the proper resolution for this issue is make wpkg 
service run as the SYSTEM account as usual, but impersonate NetworkService when 
accessing the network (as explained on #3). It seems that this account will 
always access the network with the computer account credentials while 
LocalSystem sometimes uses a null session (not sure exactly when though, but it 
does)

Original comment by jorgito1...@gmail.com on 1 Feb 2015 at 4:00

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant