What is SDDL? SDDL stands for “Security Descriptor Definition Language”, the definition from Microsoft “The security descriptor definition language (SDDL) defines the string format that the ConvertSecurityDescriptorToStringSecurityDescriptor and ConvertStringSecurityDescriptorToSecurityDescriptor functions use to describe a security descriptor as a text string. The language also defines string elements for describing information in the components of a security descriptor”. Combined with some nifty tools from Microsoft it provides you with an alternate way to grant users and/or groups permission over Window Services, other then group policy. They can be tricky to master, and devastating if you mess up the SDDL string when trying to change a services ACL.
A user calls in with a support request, said user was trying to modify a services ACL to allow any user to stop, start, and restart a service. This user was to be used as a schedule task user. The user could not be a member of the Administrator’s group, and group policy settings were out of the question as the server was a part of a domain that he did not have control over. Long story short, the user messed up the SDDL and ended up making to where no user could even see the service in Microsoft’s Service Manager.
Attempts to reset the permissions after that resulted in the tool returning “Access Denied” error message which is to be expected. Search’s of google returned almost nothing except for one helpful post about a registry key that needed to be deleted… Regretfully for us that key did not exist on the server for unknown reasons.
So what to do? Every account was locked out from seeing this service, including domain and local administrator accounts. The only option in sight was to rebuild the server, or was it. Rummaging around in my head is a lot of useful, and useless information. Here is the solution I came up with which ultimately fixed the issue and made the customer happy.
Back in the day was tasked to access a domain who the previous domain administrator changed all the passwords before he left. The trick to doing this relies on getting access to a command prompt and other applications that are ran as and owned by the user “SYSTEM”. The windows “SYSTEM” account is the account that Windows Services, process, and tasks are run as by default, think of it as the “super admin”, or “root” if you are a Linux junkie.
The How (USE AT YOUR OWN RISK):
While this is not as complicated as task as resetting the Domain Admin account that I had to one time. It is still dangerous, because running anything as system bypass all permissions in place, you can seriously destroy your windows install if you run the wrong commands.
1. The first cravat is that you have to be logged on to the console of the box, I.E equivalent of sitting in front of it. If you don’t have physical access to the machine your still in luck because Microsoft RDP supports connecting to the console, you just have to shift through the options of whatever client you are using to enable it.
2. The second step is accessing a normal command prompt
3. A. Windows 2003
Now what we need to do is to tell Windows to run a “cmd.exe” process at few minutes in the future. We do that by using the “at” command. Which you will type in your first command prompt window.
at hh:mm /interactive "cmd.exe"
Replace the hh:mm with the time you want it to run in 24 hour format, a few minutes in the future should be sufficient . Once that command runs you should be presented with a new command prompt with the default path as “C:\Windows\System32\”
3. B. Windows Vista/7/2008
In Windows Vista/7/2008 microsoft has locked down the previous way to run a command prompt as the system user, but fear not, it can be done with the below steps.
In the command prompt type the below command.
sc create systemcmd binpath= "cmd /k start" type= own type= interact"
sc start systemcmd
Basically what you are doing is creating a service which will run the command prompt when the service is start. You will then see a pop up telling you that a program is trying to interact with the desktop. When you click “View Message” your desktop will disappear and you will be presented with the command prompt that is using the system account.
4. Verify the new command prompt window is running as system. Type “whoami” and you should get the results like below.
5. The magic to fix the original error. Run the command below replacing “SERVICE_NAME” with the name of the effected service. The below command resets the SDDL on the service to allow “All Authenticated Users” access to the service. When the command is ran you should see it return success.
sc sdset SERVICE_NAME "D:AR(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
6. Clean up. If you are on Windows Vista/7/2008 you can remove the service we created by issuing the below command.
sc delete systemcmd
That’s it! You should now be able to access Windows Service Manager, and see your service again. Run through your normal test to make sure it is running correctly, testing start/stop/restart.