0

I've been happily using Samba's net rpc service ... to control services on a Windows 2003 server from my linux box, however now controlling a Windows 2008 server gives me WERR_ACCESS_DENIED errors.

It appears the issues exists also on WinXP (using sc) but things work from Win7. Has something changed in how Windows 2008 server allows remote access, and is there anything that can be done on the client (Samba)-side to get around this?

Thanks in Advance!

(Samba 3.6.3, Win2008R2)

U47
  • 1
  • 2
  • Access denied is a pretty strong clue. have you verified your account permissions. – uSlackr Jun 12 '12 at 20:00
  • Like I say, I can start/stop services just fine using `sc` in Windows 7. It's not working for WinXP or Samba. – U47 Jun 12 '12 at 21:07
  • 1
    Like I say, have you verified account permissions. Are you using the same admin account in all cases? – uSlackr Jun 12 '12 at 21:14
  • Yep. `sc \\servername stop servicename` works from win7, not winxp `net rpc service stop -S servername -U user%pass` doesn't work – U47 Jun 12 '12 at 21:20
  • Is anything recorded in the system or security log. – uSlackr Jun 12 '12 at 21:25
  • I should say that on win7 I've already mapped into a share using the same user%pass as I'm trying to use on linux. Am I missing a step? – U47 Jun 12 '12 at 21:26
  • According to the Windows logs, it's negotiating NTLMv2 128, and the password is correct. To windows it appears I connect and then disconnect, without ever sending a command to the service. Odd. – U47 Jun 12 '12 at 21:42

1 Answers1

3

Looks like the permissions have changed since 2003 SP1; "Service Control Manager Security for non-admins" has more information and a fix that allows authenticated users the ability to list services.

I'm playing around with the "sc sdshow" and "sc sdset" commands to give me the ability to control the cygwin sshd service on a win7 home from my unbuntu machine. The first sdset command in that article gave me the ability to list some services from linux, so it shows promise.

I'll try to post back with more detailed instructions, but that should be enough to get you started. Good luck.

Update

OK; so here's what I did and it seems to do the trick. Note that you have to run these commands in an elevated "cmd.exe" - search the start bubble for "cmd", right click, run as administrator.

  1. First, get the current security descriptor for the service control manager:

    sc sdshow scmanager

D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

    This gave me almost exactly as listed in the link above. The form of the output is D:(DACL)(DACL)(...)S:(SACL)(SACL)(...). Each DACL is structured as a ;-delimited string. The first, third, and last fields are the important parts. The first is A for "allow" and D for "deny". The last part is either an abbreviation for a well known user or group, or it is the SID of a user or group. The third string is a series of permissions - one permission per pair of characters. The full breakdown is at "MSDN Article: ACE Strings". The meaning of the characters in the "rights" field is a bit difference for the service control manager, and different again for services. If you cross reference the three tables from that first link you will see what I mean. So for example, (A;;CC;;;AU) as given by the sc sdshow scmanager command means that authenticated users are allowed to connect to the service control manager. The article recommends expanding that to (A;;CCLCRPRC;;;AU) which is "CC", "LC", "RP", and "RC" - "connect", "enumerate", "query lock status", and "read control". Basically we are just giving "AU" - "Authenticated Users" the same rights as "IU" - "Interactive Users" - those users who are logged into Windows. When you change the DACL with 'sc sdset', you are replacing the entire entry, so you need to modify only the DACL that is important for your purposes, and copy the others.

    sc sdset "D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)"

    Notice how I just replaced the DACL pertaining to "Authenticated Users".

  2. OK; now for the easy part. For this you'll need "subinacl" - if you don't have it you can download it from the various Microsoft sites. (You could use 'sc sdset' but 'subinacl' is much easier. Unfortunately 'subinacl' only works with actual services, not the service control manager, hence the first step.) Personally I deviated from the article a bit and instead of granting my user permissions on the service, I created a local group, and added myself to that.

    net localgroup "Service Operator" /add
net localgroup "Service Operator" "My Login Account" /add

  3. Next, I gave that group full control over the sshd service:

    subinacl /service sshd "/grant=Service Operator=F"

  4. On my linux machine, I can now start and stop the service:

    beltorak@kryos [~]
$ net -S diabolique rpc service stop sshd
Enter beltorak's password:
..
sshd service is stopped.

beltorak@kryos [~]
$ net -S diabolique rpc service start sshd
Enter beltorak's password:
..............................
Failed to start service: sshd [WERR_OK]

I don't know why it says "failed: WERR_OK" - I think that's the equivalent of an error dialogue that says "ERROR: Success". Verifying the state of the service on the win7 machine definitely indicates that I can now control the service from my linux machine.

NOTE: It would probably be wise to grant the Service Operator group those extra permissions over the service control manager - I'm sure the restriction of rights for "authenticated users" was done for a reason - and to limit the permissions on sshd to just those required to start and stop the service. I was just happy to get it working, and this is a home network, so I'm done.

beltorak
  • 131
  • 3