joeware - never stop exploring... :)

You may recall the previous blog entries

http://blog.joeware.net/2005/06/12/36/

http://blog.joeware.net/2005/06/12/38/

about the new ACL that appeared in Windows Server 2003 SP1… The one that locks down who can work with the service control manager, like for instance enumerate services, etc. This problem impacts the Exchange tools as well as monitoring, etc many folks have set up.

Well another MVP pinged me and asked the question… “Hey do you know where that ACL is stored?”

Surprisingly or possibly not… My response was actually… “Why yes I do…”

One of the first things I wanted to know when that change was implemented was how was it implemented?? To figure this out I changed the ACL while watching the system[1] to see where the changes occurred. As I expected,  it was in the registry with darn near everything else related to services… I thought about and rejected the idea of writing about it previously because this kind of information usually isn’t something people care too much about. It is probably a bit esoteric… Not something that regularly comes up during normal dinner conversation I expect[2]. However, since someone else actually asked, that means there are probably others that are curious as well… So….

As you may or may not know, service info is stored primarily in the HKLM\System\CurrentControlSet section of the registry, the two main subkeys are under Control and also the entire Services key. The Services key enumerates all of the services for you and their parameters, etc. The “main” entry under Control that is involved is ServiceGroupOrder. Now logically, the place to make this change would probably be on the actual Services Key itself, since it is over all of the services. However arguments could be made to put in ServiceGroupOrder or even create a new subkey under Control.

What Microsoft did in fact do is create a new subkey called Security under ServiceGroupOrder and then under that key is a value called Security. If I were to guess why this was done this way (and no I never actually chased into the source on this one), I would guess that it was because when the SCuM fires up, it has to read the ServiceGroupOrder info anyway so while your there… why not?

Anyway, this value is a binary security descriptor blob just like the Security values under the Security keys of the services listed under the Services key that have ever had their security modified.

So the full path to the Security Descriptor value is…

HKLM\System\CurrentControlSet\Control\ServiceOrderGroup\Security\Security

Now let me end by saying… I do not in any way shape nor form recommend anyone play with that value. Sure read it all you want, but if you modify it, you are on your own baby! I, in fact, have never tried to change it directly myself. The SCuM may actually protect it, I don’t expect it does, but maybe. 🙂

Oh if you want to watch this being updated on your own system, use SC according to the directions given previously while running your favorite free registry monitor and then look for where sc.exe runs and then right after it looks up the computer name (HKLM\System\CurrentControlSet\Control\ComputerName), look for some work being done by services.exe… That’s right, SC doesn’t change it directly, it asks the SCuM to make the change on its behalf and this is handled via an API call that is fielded by services.exe. Specifically look for a RegSetValue with the previously mentioned registry key and value.

  joe

[1] You can guess what kind of free tools I was watching the system with to check for this… Those really good free tools that I didn’t write… You know, the other guys…

[2] Heck this is the first time someone has asked that I have seen in private or public forums in over a year and half….