There is a fairly cool update in Windows Server 2003 SP1 that is currently biting folks.
In SP1 Microsoft took the ACL that always existed on the Service Control Manager and made it useful. They made it so you can now modify that ACL to control who can access the SCM, previously you could enumerate the ACL but you couldn’t do anything about it so it was pretty worthless to even think about it.
When they did this, they also made a change to that ACL, that change being they made it so ONLY Administrators of a machine could remotely enumerate the services on that machine. This is cool, but it doesn’t seem that they gave a mechanism to update the ACL so everyone is pretty much stuck like this unless they know how to write code to update that ACL (and I haven’t done this yet, haven’t gotten a chance). I have heard that a few companies have had to roll back SP1 because of this…
You may be sitting there thinking, well this is a good thing, the machine is more secure right? Why would this be bad in any way? Why would anyone have to roll it back?
The bad part is that many people have set up service monitoring such that they have some basic script or monitoring tool (or even a person) that does things remotely that scans machines and verifies all of the services they want running are indeed running. They may even have added functionality to have certain services be restarted which is quite easy to do. None of this requires administrator rights on the machines because you could delegate some non-admin the ability to stop/start services simply by modifying the ACLs of the service with say SUBINACL.
Well previously, since the ACL of the SCM couldn’t be modified, everyone writing tools to work with the services remotely simply opened the SCM with GENERIC_READ which *always* worked…. until now. Now if you are not an administrator and you try to remotely open the SCM with GENERIC_READ you will be denied access. Processes that have always worked all the way back into the early NT days now all break unless someone was silly and using an admin ID to do the work when they didn’t need to[1].
So basically, people following Least User Access Privilege mechanisms with the monitoring of these services are very likely broken now until the tools they use are updated or they roll back from SP1 or they start throwing a bunch of unneeded access rights at the userid doing the work.
If you are doing this work from the command line, you have a couple of options. The SC command line tool that comes with Windows Server 2003 was also updated in SP1 so you can use that. I am not sure on the licensing in terms of what machines you can copy that too so keep that in mind if you do copy it. I have also updated SvcUtil to work within these new confines. You won’t be able to remotely enumerate all services still unless you are an admin, but you can look at the status of individual services and also control them if you have had the appropriate rights delegated to you.
Microsoft is doing a good thing in locking this stuff down. Unfortunately in this case, they either made the specific decision to screw people using LUA or they figured since they weren’t doing it, no one was. I know this was caught in beta as I saw unanswered posts in the beta newsgroups about this feature; MS never acknowledged them.
It is sort of like the ACL Bases Enumerate feature in SP1, they added some extra security but didn’t provide tools for controlling it. Finally after much chatter about it, they published an ABE tool, hopefully they will do something for modifying the SCM permissions as well. You would think this would probably be a good GPO item since they have other service ACL manipulation there.
Again, this is a great feature, I am just not completely thrilled with how it was implemented and announced. I intend at some point to take some time out and write a tool to modify that ACL so admins can take control over who can enumerate the services on their machines without having to give out excessive rights for it. It might be today, it might be a month from now. Keep watching here.
joe
[1] This kind of sucks, people who did things the right way were punished, those who did it the “wrong” way are rewarded.
This is a decrease in security because if you are like most companies, you will add all the users you need to access this to the local admins group. Then rather than just having the permissions the user needs, it has all permissions to run amok. Really pathetic. Let me know when you find out more on how to fine tune this.
I’m working with MS CPR on this now. This would have hit us hard because we have a 1st Tier group that are not admins that we allow to cycle services. Once I get more information from MS, I will repost. I’m requesting that they add extended attributes to the ACL to allow delegation.
Check out this post as well
http://blog.joeware.net/2005/06/12/38/
Basically SP1 SC.EXE was modified to allow you to tweak the ACL that is now on the SC Manager. That means you can change it back to what it was.
That also gives you a mechanism to delegate it. I would recommend setting up a group on every server called something like RemoteServiceMgmt and then grant that access to the SC Manager ACL like the old auth users used to have.
That is good to know, but man having to do this on 800 servers would suck. I know it could be scripted, but I’m going to try to force MS into an ammendment for GPO templates, or visable extended attributes on the ACL.
Consider doing this in a computer startup script. That way you write one script to create the local group on the servers and run the appropriate SC command. Of course you don’t need to use a local group, you could use a domain group. I just think a local group would be more flexible.
I was sent this KB article from MS. I will be testing this later today.
http://support.microsoft.com/?id=889248
Yeah not exactly sure why they sent that to you unless your issue isn’t the one described in my blog entry.
That KB is about an issue with DCOM connections to a machine. The tools such as SC and my SVCUTIL don’t use DCOM, they use the SCM WIN32 API calls remotely so this has no bearing on what many people are running into. This will impact you if the tool you use makes a DCOM connection to the server in question and tries to manipulate things that way.
We created a Computer startup script that will run only on W2K3 machines, and will only run once on those machines. We set this up to utilize a domain group created to house users we want to have access.
On Error Resume Next
Dim objShell
Dim objOS
Dim objWMIService
Dim fso
Dim WinVer
Dim ServicePackVer
Dim strSDDL
strSDDL = “(your SDDL format Group here)”
strComputer = “.”
Set objShell = WScript.CreateObject (“WScript.shell”)
Set objWMIService = GetObject(“winmgmts:{impersonationLevel=impersonate}\\” & strComputer & “\root\cimv2”)
Set objOS = objWMIService.ExecQuery(“Select * from Win32_OperatingSystem”)
For each OS in objOS
Winver= OS.Caption
ServicePackVer = OS.CSDVersion
Next
MyPos = InStr(1, Winver, “2003”, 1)
If MyPos 0 and ServicePackVer = “Service Pack 1” then
If objShell.RegRead(“HKLM\Software\SDDLScript\”) “True” then
objShell.LogEvent 4, “SDDL script has not been run on this machine.”
Dim temp
temp = “sc \\” & strComputer & ” SDSet SCManager ” & strSDDL
objShell.RegWrite “HKLM\Software\SDDLScript\”, “True”, “REG_SZ”
Return = objShell.run(temp,1,true)
If Return 0 Then
objShell.LogEvent 1, “SDDL script failed”
Else
WobjShell.LogEvent 0, “SDDL script succeeded”
End if
Set objShell = Nothing
End if
End if
WScript.Quit(0)