Posted by The Admin Arsenal Team on Mon, Feb 08, 2010
Author: Adam Ruth
DCOM, or Distributed Component Object Model, is a technology in Windows allowing remote communication between programs. WMI, in particular, uses it to communicate. A lot of business oriented server applications use it, as well, to communicate between layers. If you've ever spent any time with DCOM you probably have come to understand just how fragile it can be. When it works, it's like magic, but when it doesn't it can be a serious hair pulling experience.
One of the more fragile bits of DCOM is its security. There are are four different areas of DCOM each with their own ACLs (Access Control Lists) and a problem in any one of the four can lead to hard to track down problems. To make matters worse, many applications that use DCOM will alter the security settings, potentially breaking DCOM access for other programs on the same computer. Sometimes it's necessary to just reset DCOM security to its default state, just as it was when Windows was installed.
Last week I found a quick way to do this, but it does require editing the registry so the standard warnings and "do not try this at home" apply. However, if you're stuck fixing a problem down in the guts of DCOM security, editing the registry is the least of your worries.
You can view the DCOM ACLs by running dcomcnfg.exe and navigating to Component Services > Computers > My Computer > Right-click > Properties > COM Security tab.
The ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:
- DefaultAccessPermission
- DefaultLaunchPermission
- MachineAccessRestriction
- MachineLaunchRestriction
To reset them, all you need to do is to delete these values. If DCOM doesn't find any ACLs here, then it will use its defaults. Any changes you make will then re-create the values. Of course, you'll want to back them up before you delete them, or you could just rename them to be safe.
Posted by The Admin Arsenal Team on Mon, Jan 11, 2010
Photo by Brad & Ying
Author: Adam Ruth
Our goal at Admin Arsenal is about helping administrators work remotely by getting them to unplug their sneakernets. System security can sometimes make it difficult to achieve this goal. It would be great to live in a world without the need for security, not least because of its delicious gumdrop houses, use of sparkling rainbow wishes for currency, and ruler Princess Yum-yum-tum-tum of the Rose Scented Flatus. Unfortunately, we don't live in that world (which is a shame because the dollar to rainbow wish exchange rate is at its highest ever.)
Like most things in life there is a trade-off between the security of assets and their availability for use (or administration, as the case may be.) We've found that security issues tend to be the biggest roadblocks in achieving remote administration nirvana. So in that vein, I present the 5 biggest security roadblocks that we encounter regularly.
Firewall
This one should be obvious. If a computer doesn't allow inbound connections to its remote administration facilities, then it's not going to work. With the advent of the Firewall in Windows XP more and more people are seeing their remote administration break. It's been a while since the Windows Firewall entered the scene so this problem, and its cure, are quite well known now. The simplest fix (short of disabling the firewall) is to enable the
remote administration firewall exception, the file sharing exception (for remote access to the file system) and the ICMP echo exception (for ping.)
DCOM Security
WMI (Windows Management Instrumentation) is one of the primary methods of remotely administering computers. It uses DCOM (Distributed Component Object Model) as its method of communication. If the rights for DCOM aren't properly set, then WMI isn't going to work correctly, if at all. WMI, for all its power, seems to be quite fragile or brittle. One of the reasons behind this is its reliance on DCOM which seems to be the target of well meaning but misguided security experts and tools. We see this problem so often that we created a tool called DCOMAcls which allows for the remote setting of DCOM security settings.
System Time
Windows security has trouble coping with computers with clocks that are out of sync. This is actually for a good reason, since security tokens use timestamps and expirations to prevent their misuse. Depending on the settings of your authentication scheme (such as Active Directory's implementation of Kerberos) a clock that is out of sync by only a few minutes can cause connectivity problems. Usually, though, it takes clocks off by a few hours (such as reversing AM/PM or being on the wrong day.) Troubleshooting this problem can be difficult because the connectivity issues don't usually indicate that it's a time sync problem.
DNS/DHCP
WMI's authentication validates the host name being used to access the computer (unless a raw IP address is used.) If there are DNS or DHCP problems causing the wrong computer name to be used for connection, WMI will quite often fail. Windows DNS is notorious for stale records and it takes some effort and planning to ensure that a good DHCP setup prevents the same addresses being reused often. Then throw NetBIOS into the mix and once your name resolution is compromised then all bets are off.
The Double-Hop Problem
This problem only affects a certain type of remote administration, so while it's not generally encountered by most administrators, those who use this type of administration will almost always run into it. The
double-hop problem is, to put it simply, the inability for a security token to hop twice between machines. If you connect from computer A to computer B to execute a task (such as start a remote software install) and that task needs files on computer C then the security token can't hop again from B to C and access to those files will be denied. There are three solutions to this problem, the first is to configure a level of trust called "delegation" between computers, but this requires some high-level settings in Active Directory and is usually discouraged. The second solution is to send a user name and password from computer A to computer B so that a new token can be created to hop between B and C, but this is also problematic because it involves sending a password over the wire (possibly encrypted, but out in the open) and there aren't any native Windows tools that work that way. The third solution is to figure out a way to not need files on computer C, but this may not always be possible. So, while you may never run into this problem, when you do it can be a bear to deal with.
Hopefully this list will help any of you having security problems in your remote administration daily lives. Personally, I've filled out the immigration paperwork for the the land of gumdrop houses...
Posted by The Admin Arsenal Team on Mon, Nov 02, 2009
Photo by Boston Public Library
What you want to look for is the Architecture type of the OS. Since a 64 bit OS cannot run on a 32 bit processor you know that if you identify the current OS type then you've accomplished your goal.
I prefer to look in WMI. One problem that you can run into is Windows versions prior to Vista. When looking at Windows XP and Windows 2003 you need to look in the Win32_ComputerSystem class. The property that I have found useful is SystemType. I extract the value from this property and apply a regular expression to extract the first three characters found. Here is a function in Visual Basic .NET that I use.
Dim OSArchitecture As Integer = 32
Dim objCS As New ManagementObjectSearcher("SELECT * FROM Win32_ComputerSystem")
For Each objMgmt As ManagementObject In objCS.Get
Dim TypeMatch As New Regex("(x64)")
Dim CSystemType As String= objMgmt("SystemType")).ToString
If TypeMatch.Match(CSystemType).Success Then
Return 64
End If
Next
For Vista or later I use the Win32_OperatingSystem class and extract the value of the OSArchitecture property. I use a regular expression to match the first two digits encountered.
Dim objOS As New ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem")
Dim OSArchMatch As New Regex("(^\d\d)")
For Each objMgmt As ManagementObject In objOS.Get
If OSArchitecture = 32 Then
Dim OSArchitectureString As String = GetWmiValue(objMgmt, "OSArchitecture").ToString
If Not OSArchitectureString = "" Then
If OSArchMatch.Match(OSArchitectureString).Success Then
OSArchitecture = AsInt(OSArchMatch.Group(0))
Return OSArchitecture
End If
End If
End If
Return 32
Next
I'm always interested in more efficient methods for extracting this type of information. If you know of other methods I can use then, by all means, let me know.
Posted by The Admin Arsenal Team on Mon, Oct 12, 2009
If you aren't using Windows 7 and you haven't installed Windows PowerShell yet, then go here to download and install.
Here are a couple of useful PowerShell examples for common tasks:
- Example of Extracting the Total Physical Memory from WMI
- Use PowerShell to directly query WMI
The two examples above show how you can use the "-filter" cmdlet to narrow down the results. In this case we filtered out any device where the DeviceId wasn't "C:". The second example shows how you can pass a WMI query using the "-query" cmdlet. In this case we only returned disks that are registered as Fixed Disks ("DriveType = 3")
- You can also query remote computers
Using the "-ComputerName" cmdlet you can specify a remote system. This should work for any object under the "get-WmiObject" cmdlet.
Posted by The Admin Arsenal Team on Fri, Sep 25, 2009
Many hardware vendors store the firmware version of their devices in WMI. Extracting this value can give you some very important information when it comes to determining which devices may need to have their firmware updated.
In this example I am using the Microsoft WMI Object Browser (available free for download here).
Let's say that I want to script a solution that reports the Firmware version for all the Smart Card Readers in my organization. In the following screenshots you can see where this data can be viewed via the Device Manager:
By looking at the properties of the device I can see both the Device Instance ID (this is important when you need to extract this device via WMI) and the Firmware Version.
When you open the WMI Object Browser change the namespace from root\cimv2 to root\WMI.
The property that we are interested in is FirmwareRevision.
Here is an example of extracting this property in Visual Basic .NET.
Private Function GetFirmware(ByVal id As String) As String
Dim firmWare As String = ""
Try
Dim objFirmWare As New ManagementObjectSearcher("\\.\root\WMI", "SELECT * FROM MSDeviceUI_FirmwareRevision where InstanceName = '" & id.Replace("\", "\\") & "_0'")
For Each objMgmt As ManagementObject In objFirmWare.Get
firmWare = AsString(GetWmiValue(objMgmt, "FirmwareRevision"))
Next
Catch ex As Exception
' do nothing
End Try
Return firmWare
End Function
When this function is instantiated it processes an argument called ID. This ID is extracted in a previous Class via the Microsoft tool DevCon.exe. Devcon.Exe is a decent command line utility used to extract information available via Device Manager. While this article is not centered on Devcon.exe, I will include an example of the output of devcon.
As you can see from the example, the first line returned is the DeviceID that I need in my WMI Query.
As always, if you have questions, comments or smart-ass remarks, let me know.
Posted by The Admin Arsenal Team on Wed, Apr 29, 2009
For those of us who use WMI everyday here is a great blog at MSDN to learn tips and tricks with accessing WMI via PowerShell.
I found a tip to help me start using PowerShell to traverse my WMI database.
Give 'er a look.
Posted by Adam Ruth, Shane Corellian, and Shawn Anderson on Mon, Apr 20, 2009
In my last post on WMI Headaches, I mentioned a tool from Microsoft for diagnosing problems with WMI services. This tool is called the WMI Diagnosis Utility and it provides an in-depth analysis of all things WMI. It has pointed me in the right direction a number of times.
The utility is a giant (and by giant I mean 30,000 line) VB Script file. You'll want to run it with the cscript.exescript host so that you can see some progress as it runs. If you run it with wscript.exe (which is the default graphical VB Script host) it'll run in the background and you won't see status.
- Running WMIDiag.vbs
It can take quite a while to run, particularly on a slower machine or if there are a lot of WMI providers installed. I've never seen it take more than 15 minutes, but I've heard it can sometimes double that. On my super-macho machine with a relatively small WMI installation, it took just over 3 minutes.
Once the test is run, you'll get a long diagnostic report. The more errors there are, the longer it will be. Search for the words ERROR and WARNING. There is a summary at the bottom to tell you how many errors there are.
In the screen shot below, I've highlighted a couple of the more common types of errors (and snipped a bunch of stuff between them.) You'll see that the file recommends what to do to correct the problems. In the case of the permissions error we have a free utility called DCOMACLS which will allow you to correct it remotely.
- WMIDiag Report
In summary, if you have a problems with WMI errors this utility is very valuable for rooting out the causes. It doesn't always identify the problem in a handful of cases, but for the most part you can count on it to narrow things down.
Posted by The Admin Arsenal Team on Tue, Apr 14, 2009
You don't work with WMI as much as we do without getting a number of headaches. For all of the functionality that WMI provides, it has contributed more than its fair share of clenched fists, muttered expletives, and harshly flung mice. WMI has a lot of moving parts, any one of which can break - leading to cranial pain.
WMI errors can can be caused by... well... by almost anything, including a stern look. One common cause of WMI problems is a corrupted repository. The repository is a collection of files that WMI maintains internally to define all of the classes and methods for its providers. If the repository gets corrupted, you'll get all sorts of strange errors. Luckily, rebuilding the repository is quick so it's a good place to start.
There are only 3 steps:
- Stop the WMI service (net stop winmgmt).
- Delete (or rename, just in case) the repository directory (%windir%\system32\WBEM\Repository).
- Start the WMI service (net start winmgmt).
When WMI comes back up, it will rebuild its repository and *hopefully* eliminate the error. On the off chance that this makes things worse, just re-do the steps but put back the renamed repository from step 2.
Microsoft has a pretty in-depth article covering a variety of WMI troubleshooting techniques. They also have a tool for testing a WMI installation which I'll cover in an article next week.