Script remote DCOM / WMI access for a non admin

Recently I was asked to create an inventory process that would query active directory for servers and gather data on their hardware.

I said “No problem”, fired up my trusty domain admin account and ran a bunch of WMI calls against the servers. Of course, for a script that is to be run on a daily basis, a domain admin is NOT the account of choice.

So, I needed to create a domain user account that could access WMI on all the servers.

Additionally, on a certain percentage of remote servers, my domain admin account was getting an error that I traced to DCOM not allowing access. When I cleared that up, using dcomcnfg, I realized the domain user would also need remote DCOM privileges.

So, my problem was two-fold:

1) Allow remote WMI for a domain user.

2) Allow remote DCOM for a domain user.

I thought I was going to have to modify the firewalls on my servers, but that was already done when they were built.

We have 557 Windows servers in the department, so I wasn’t about to do this by hand.

Of those 557 servers, only 56 are Server 2008 or newer. Now I had a third criteria:

3) My script needs to work against Server 2000, 2003, 2008, 2008 R2

I did some searching, and asked around, and wasn’t getting very far – starting to get desperate, I enabled remote DCOM on a test machine, found out what registry keys it changed, and thought I’d use this:

(From Shay Levi’s "Stand alone registry functions library")
http://blogs.microsoft.co.il/blogs/scriptfanatic/archive/2007/10/30/stand-alone-registry-functions-library.aspx

1. $a = Get-RegBinary <machine that works> localmachine software\microsoft\ole MachineLaunchRestriction
2. $a | Export-Clixml C:\scripts\New\dcom.clixml
3. $b = Import-Clixml C:\scripts\New\dcom.clixml\parSet-RegBinary <other server> localmachine software\microsoft\ole MachineLaunchRestriction $b

This has problems though – If the target server had other than default DCOM permissions I’d overwrite them.

For the second part of the problem, enabling remote WMI, I thought I found a solution on this blog:

https://blogs.msdn.com/wmi/archive/2009/07/27/scripting-wmi-namespace-security-part-3-of-3.aspx – I mean how perfect, “Scripting WMI Namespace Security” right?

Well, it turns out that I needed to read this on Part 1 of his post: “In each namespace, there is a singleton instance that controls namespace security: __SystemSecurity=@.  It exposes several methods, but in this case, we are only interested in two (available on Vista+): GetSecurityDescriptor and SetSecurityDescriptor.  On older systems, these two methods are not available and you would have to use GetSD and SetSD which work on SECURITY_DESCRIPTOR structs represented as binary arrays.  Discussion on how to use those methods (which is only really possible with C/C++) is outside of the scope of this blog post.”

Wow – Bummer. But, I don’t give up easily. So, off to Bing some more. I DID find a C# project on “The Code Project” called WMI Namespace Security, (http://www.codeproject.com/KB/system/WmiSecurity.aspx) and when I downloaded and compiled it, it granted the permissions I needed. However, the groups that own the servers wanted a script, not a compiled program. They wanted to see what the script was doing, and besides, I wanted to do it in PowerShell!

But, between Steve Lee’s blog on Scripting WMI Namespace Security, and J_Madden’s C# program, I had some clues.

I searched the web for information and found this:

http://msdn.microsoft.com/en-us/library/ms735120.aspx

Close, but I don’t want to add the built in users group.

I searched for a method to retrieve a SID and found Adam Bell’s excellent script on:

http://www.leadfollowmove.com/archives/powershell/security-identifiers-sids-and-nt-account-name

Now I have a SID, I know what registry value I need to modify for the DCOM permissions, and what I have to do to set WMI permissions, so I need to read and write registry values. I could have continued to use Shay’s excellent functions from above, but found this page:

http://www.vistax64.com/powershell/23050-powershell-stdregprov.html

OK, I’m starting to tie it all together, and have a working script in 31 lines of PowerShell:

1. function get-sid
2. {
3. Param (
4. $DSIdentity
5. )
6. $ID = new-object System.Security.Principal.NTAccount($DSIdentity)
7. return $ID.Translate( [System.Security.Principal.SecurityIdentifier] ).toString()
8. }
9. $sid = get-sid "local\maxsmart"
10. $SDDL = "A;;CCWP;;;$sid"
11. $DCOMSDDL = "A;;CCDCRP;;;$sid"
12. $computers = Get-Content "computers.txt"
13. foreach ($strcomputer in $computers)
14. {
15.     $Reg = [WMIClass]"\\$strcomputer\root\default:StdRegProv"
16.     $DCOM = $Reg.GetBinaryValue(2147483650,"software\microsoft\ole","MachineLaunchRestriction").uValue
17.     $security = Get-WmiObject -ComputerName $strcomputer -Namespace root/cimv2 -Class __SystemSecurity
18.     $converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
19.     $binarySD = @($null)
20.     $result = $security.PsBase.InvokeMethod("GetSD",$binarySD)
21.     $outsddl = $converter.BinarySDToSDDL($binarySD[0])
22.     $outDCOMSDDL = $converter.BinarySDToSDDL($DCOM)
23.     $newSDDL = $outsddl.SDDL += "(" + $SDDL + ")"
24.     $newDCOMSDDL = $outDCOMSDDL.SDDL += "(" + $DCOMSDDL + ")"
25.     $WMIbinarySD = $converter.SDDLToBinarySD($newSDDL)
26.     $WMIconvertedPermissions = ,$WMIbinarySD.BinarySD
27.     $DCOMbinarySD = $converter.SDDLToBinarySD($newDCOMSDDL)
28.     $DCOMconvertedPermissions = ,$DCOMbinarySD.BinarySD
29.     $result = $security.PsBase.InvokeMethod("SetSD",$WMIconvertedPermissions)
30.     $result = $Reg.SetBinaryValue(2147483650,"software\microsoft\ole","MachineLaunchRestriction", $DCOMbinarySD.binarySD)
31. }

I guess my first post was a little long – thanks for sticking with me. Trust me, it was a lot more painful for me 😉

 

Advertisement