This is part of a series of posts on automating Windows and deploying systems in the real world of enterprise operations. I’ve focused the series on the those nuances and problems that I’ve hit trying to deploy the various software stacks found in a typical Windows centric enterprise.
DCOM. It strikes fear and bewilderment into IT Pros everywhere. Usually because some third party application is installed that loads some DCOM components and at some point someone broke the security permissions or activation settings; and no one knows what the correct settings were.
If there was ever a case for automation and infrastructure as code then this is it. Personally, I have one fairly important third party framework that, occasionally over the years, has needed to be deployed/redeployed. And every time there is a period of head scratching as to how to get it configured correctly. It has a couple of DCOM objects that get installed but these don’t ever have the correct permissions or identity set after installation. Enter Chef and dcomperm.exe, a compiled tool from Microsoft’s SDK sample code, that allows for programmatic control of DCOM permissions.
It seems setting DCOM permissions is actually pretty hard to automate, the permission ACL’s are binary strings in the registry and a slight mistake trying to set a binary string renders the ACL unusable. There aren’t any Powershell commands out of the box so you either assemble a script that hits WMI or you use the compiled tool.
Fortunately this application actually ships with dcomperm.exe, as I suspect it tries to use it itself to set the permissions at some point. As such I’ll focus on how I bundled this into a Chef recipe and the limitations of doing so. Hopefully I’ll have an improved solution at some point in the future to share.
Set out below are the snippets of a cookbook, as one way of using dcomperm.exe to set permissions on a DCOM object. You need to retrieve the objects GUID in advance for this example. If you are setting the identity for the object to run under then please note that you should securely encrypt the password in a Chef vault, rather than just leaving it as plain text in the attributes!
In the attributes I set an array of options that I want the dcomperm.exe tool to run to set my object’s permissions and identity. Then in the recipe I loop through each of those strings of options and use an “execute” resource to then run dcomperm.exe with those options. You will need to distribute the dcomperm.exe in the cookbook as well, but I have not included that step in the sample for the sake of brevity.
The important thing to note is that there is no idempotence. Every time the recipe is run this section will run regardless of current settings. On the positive side it is a very fast set of commands to run and it does not affect the operation of the DCOM object when it is applied.
Attributes
default[‘poal_openroad’][‘dcom_options’] = [
‘-runas {9804E901-495A-11D4-A083-00C04F740D56} domain\username password’,
‘-al {9804E901-495A-11d4-A083-00C04F740D56} default’,
‘-aa {9804E901-495A-11d4-A083-00C04F740D56} default’,
‘-al {9804E901-495A-11d4-A083-00C04F740D56} set domain\username permit’,
‘-aa {9804E901-495A-11d4-A083-00C04F740D56} set domain\username permit’
]
Recipe
#Set DCOM Permissions
node[‘cookbook’][‘dcom_options’].each do |dcom_options|
execute “#{dcom_options}” do
command “dcomperm.exe #{dcom_options}”
cwd “#{node[‘cookbook’][‘bin’]}”
end
end
24 by 7, 3 6 5 