Adjusting DCOM Settings via Script

This post was previously released under a different blog and is being republished by me below. That site is no longer available. I am the original author.

I was recently tasked with adjusting the DCOM Security Settings (DCOM: Machine Access Restrictions and DCOM: Machine Launch Restrictions) in the local security policy on a number of computers. These can be changed manually by opening the Local Security Policy and browsing to Local Policies and then Security Options, but it needed to be more automated than that and needed to be rolled out to a few hundred Windows XP Computers.

The requirements of the script were as follows:

  • Add two groups to each of the policy settings
  • Do not try and add them again if they already exist
  • Do not overwrite the users/groups that are already there
  • Group Policy is not an option for this project
  • Log Everything

I played around for about 45 minutes with secedit and applying a policy that way but I couldn’t get it to import and append the existing policy correctly. I decided that the changes were going to need to be made through script, and probably through the registry.

I first used REGMON (from Microsoft SysInternals) to find out where these settings were stored in the registry. I found they are both in the same spot under HKLM\Software\Policies\Microsoft\Windows NT\DCOM. Unfortunately, it wasn’t just a comma delimited list of users and rights.

On the bright side, at least it wasn’t some binary key that made even less sense. These strings seemed workable; it seemed like there was a pattern.

I’ll save you the paragraphs I could write about how I added and removed users, changed their permissions, etc. just to see the changes on these keys to break the pattern and just bring you to my end result. The strings are in SDDL (Security Descriptor Definition Language) format. While Microsoft had some light write-ups on MSDN about SDDL, the best resource I found on the matter was at this University of Washington page.

While reading about SDDL from that site is important if you’re looking to take on a similar task, the short version is that SDDL strings can be first broken up into five groups (Header, DACL, SACL, Primary Group, and Owner). Each of these fields is separated by a colon. I wont go into details about each of these as the University of Washington site will do this for you, but for the purposes of this project the only thing that needs to be changed for the DCOM policies is the last field in the string. In my screen shot above, that’s the one that looks like this:


In a nutshell, each user or group in the string is represented by a parentheses grouping. You can see in the one in bold that there are two groupings, representing two users/groups. These grouping are further broken down by fields that are separated by semicolons. You can see there are six fields and they are:

  • Type
  • Flags
  • Permissions
  • ObjectType
  • Trustee (SID)

Again, read up on either MSDN or the University of Washington page to learn about what each of these fields mean. You can see from the existing SDDL strings that the DCOM policy only uses three of these fields: Type, Permissions, and Trustee. By digesting all of this, I was now ready to create a script to parse the existing users/groups, modify their permissions if necessary, and add the users if they didn’t exist.

The script below is the product of this effort. You are welcome to use, however please keep the header intact and provide credit to this post if you share it with others. I’ve commented on how the script works beneath it.

Basically, the meat of the script is that after setting up our log file, we read the two registry keys that we need to possibly modify. We then break them down into their 5 parts and log them, and then break the fifth field down into it’s six parts so that we can look at all the users.

We then loop over each user and pull out who the user is and what their permissions are. If they are a user that we want to modify, we update our temporary SDDL string to set the permissions to what we want (see the tables on the University of Washington site). If they are not a user that we care about, we insert them as-is into our temporary SDDL string. If at the end of it all we haven’t found the users we want to modify, we add them. Once all is said and done, we insert the new SDDL right back into the registry.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.