I had an issue today where the application team responsible for the application support on a new implementation I'm managing wanted the rights to stop and start services.
As the application support team are also a subset of the users, and as the team as a whole are Windows developers, I am unwilling to give them full local admin rights - I need to ensure any OS changes go through the internal change control process and I get the distinct feeling that simply mandating this in the support policy wasn't going to cut it. :(
I used subinacl.exe from the resource kit to grant the necessary access to the services.
subinacl /service servicename /grant="domain\usergroup"=QSETOI
This grants the domain user group members the following permissions on the services:
Query Service Config
Query Service Status
Enumerate Dependent Services
StarT Service
StOp Service
Interrogate Service
All this is as documented in KB288129
I supplied the relevent people with the relevent command line tools (PSService, SC.exc, NetSVC) but none of them appeared to work - they were all getting access denied.
Some googling, KBing and head-scratching later I found details of some changes that were made in W2K3 SP1 to the default DACL of the service controller (the rights given to remote users had beed reduced by default, and an API had been added that allowed the security on the service manager to be changed. (See http://msdn2.microsoft.com/en-us/library/ms684323.aspx)
So, to grant the users access to the service controller, it was as simple as using
sc sdset SCMANAGER 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)
(The important part of this sddl code is A;;CCLCRPRC;;;AU which gives authenticated users the same rights as interactive users - In W2K3 SP1 these rights are changed to A;;CC;;;AU)
Or so I thought.
With this solution in place, users were able to remotely query the services, but any attempt to stop or start them resulted in an access denied message
Checking the security event log, I found the following alert:
Object Open:
Object Server: SC Manager
Object Type: SC_MANAGER OBJECT
Object Name: ServicesActive
Handle ID: -
Operation ID: {0,90876741}
Process ID: 524
Image File Name: C:\WINDOWS\system32\services.exe
Primary User Name: SERVERNAME$
Primary Domain: DOMAINNAME
Primary Logon ID: (0x0,0x3F7)
Client User Name:
Client Domain:
Client Logon ID: (0x0,0xC657EA)
Accesses: DELETE
READ_CONTROL
WRITE_DAC
WRITE_OWNER
Connect to service controller
Create a new service
Enumerate services
Lock service database for exclusive access
Query service database lock state
Set last-known-good state of service database
Privileges: -
Restricted Sid Count: 0
Access Mask: 0xF003F
The info highlighted in red indicates that instead of just requesting the permissions required to enumerate, start and stop services, the command line tools were actually requesting FULL CONTROL access - which hadn't been given.
WARNING: If I had granted full control permissions, the users would have had the right to add a new service or modify one of the existing services. This service could be configured to point to any exe placed on the server. This could include an exe specifically written to add the users into the local administrators group.
So now my problem was with command line tools which were not coded to support this function.
To my surprise, however, when we tried to use the services.msc tool remotely, this worked exactly as designed - only requesting the exact permissions it needed to start and stop the services remotely. This was a better solution than I originally anticipated, and more in line with how the users actually wanted to work.
