Saturday, September 28, 2013

Virtual Machines, Snapshots and Domain Membership

I have a number of virtual machines that I use for QA. All of these machines have snapshots for easy rollback and all are members in an Active Directory (AD) domain. One of my goals has been to allow all the users in the domain to have administrative rights for these virtual machines, but getting that working has encountered a few hiccups.

Every once in a while, the domain membership breaks. When trying to log in with a domain login through RDP, I get an authentication error, specifically: The Local Security Authority cannot be contacted. When trying to log into the machine directly (through the vSphere Client) using the same domain login, I get a different a different - but also vague error: The trust relationship between this workstation and the primary domain failed.

The short and recommended answer is to rejoin the machine to the domain. This can be done in several creative ways in addition to Microsoft's recommendation, but it doesn't really solve the problem. Microsoft's article does give me a little more insight, though. "For Windows 2000 or Windows XP, the default computer account password change period is every 30 days." The article was written many, many moons ago, but this behavior hasn't changed with newer versions of Windows.

Roughly translated, every 30 days or so, a Windows machine that is part of a domain, renegotiates its connection to the domain. Basically, Windows changes its "machine password" on the domain controller. This new password is only known by the domain controller(s) and the machine. What this means for me is that every time I rollback one of my QA virtual machines, Windows loses its new password and goes back to using its previous password - the one created before the snapshot.

Considering these machines are going to be rolled back to a snapshot often, having to rejoin them to the domain after every rollback is not a viable option. A better solution would be to stop the trust from breaking in the first place. This is actually something I can accomplish pretty quickly thanks to the article Machine Account Password Process from the Ask the Directory Services Team blog.

Unlike Windows user passwords, machine passwords don't expire; they are entirely client driven - meaning the Windows machine itself decides whether to change the password or not. So, as long as no one messes up the Computer account in AD, as long as the machine doesn't change its machine password, we are good to go.

Thanks to that article, there are a couple of ways I can accomplish this, both of them through GPOs.

If you haven't read it and like knowing nitty-gritty details, I highly recommend reading the Machine Account Password Process article.

Friday, September 27, 2013

SQL Server 2012 Integration Services and DCOM Permissions

On my development machine, I noticed I was getting the same DistributedCOM error 28 times every 15 minutes.
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {FDC3723D-1588-4BA3-92D4-42C430735D7D} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.
I'm not sure it is possible for this error to be any more cryptic. Luckily, I know a little about DCOM permissions. Roughly translated, there is a process calling a particular COM+ server (also known as a component). When that happens, the process fails to create/initialize the component because of a permissions error.

Debugging the Error

Based on the error, I know a couple of things. I know the process is a Windows service. Only Windows services can run under the Network Service (also known as "NT Authority\Network Service") user. I also know the GUID listed is the CLSID (also known as the Class ID) for the component.

Now, all COM security is configured from a little utility named dcomcnfg.exe. More specifically, the permissions I need to deal with are handled under the "DCOM Config" branch of the tree displayed in dcomcnfg.
Console Root -> Component Services -> Computers -> My Computer -> DCOM Config

So, a quick look at the listed components; and the CLSID can't be found. That's okay. Components can be listed in a variety of ways. The CLSID is only used as a last ditch effort if a more readable name is not stored for the component. To find the name for the component, I need to look it up in the registry under HKCR\CLSID, which gives me something much more useful.

Now I know that the COM+ server is named Microsoft.SqlServer.Dts.Server.DtsServer, and I know that this is definitely related to SQL Server - Data Transformation Services by the name. Switching back to dcomcnfg, the Microsoft.SqlServer.Dts.Server.DtsServer component is not listed either.

What else can the component be named? The registry key also displays an AppID GUID in addition to the component name. This represents the name of the process that hosts the component. Similarly to a component name, I can look up the application name in the registry under HKCR\AppID.

The process listed here is a Windows Service named MsDtsServer110, which is the short name for the SQL Server Integration Services 11.0 service. Switching back to dcomcnfg, the SQL Server Integration Services 11.0 component is listed. Perfect. Now all I have to do is configure it.

Fixing the Permissions

The steps listed here are very specific to my error but can easily be adapted to whatever component you need by replacing SQL Server Integration Services 11.0 with the appropriate application name, AppID or CLSID and replacing Network Service with the appropriate Windows user.
  1. In dcomcnfg, right-click on SQL Server Integration Services 11.0 and click on Properties.

  2. Change to the Security tab.
  3. Under Launch and Activation Permissions select Customize.

  4. Click [Edit] to display the Launch and Activation Permissions window.

  5. Click [Add] to open the Select Users or Groups window.

  6. Enter Network Service.
  7. Click [Check Names].
  8. Click [OK] to close the Select Users or Groups window.

  9. Select NETWORK SERVICE in the Group or user names list.
  10. Check the Local Launch and Local Activation permissions.
  11. Click [OK] to close the Launch and Activation Permissions window.
The error should now be resolved. For me, all I have to do is wait 15 minutes to see if the error is logged again. If your error can be duplicated another way, repeat those steps to see if you are still getting the error.

How did I get here?

Perhaps more important than all of this is, "why did I get this error in the first place?" The answer to that, in my case, is that I installed SQL Server 2012 and selected Network Service as the logon account for all the Windows services created by the installer. This is contrary to recommended practices, especially since the SQL Server 2012 installer has the ability to configure Windows accounts specifically for use by the Windows services it creates.

The short answer is that I shot myself in the foot because I didn't follow recommended security practices for the installation of SQL Server. Still, I would have thought that DCOM permissions would have been automatically configured for these components upon installation.

Regardless, it was relatively easy to fix, as long as I knew what DCOM was and how to deal with it.

Update (2013-09-28): Found another useful article for Troubleshooting DCOM and thought I would share.

Saturday, September 21, 2013

Encrypted File System on Windows 7 Home Premium

While Windows 7 Home Premium edition doesn't support EFS, you can get it working in a roundabout way - given you have temporary access to a copy of Windows that does have support for EFS. I found this out while using an external hard drive when passing files between my desktop (Windows Vista Ultimate) and my laptop (Windows 7 Home Premium).

  1. On the machine which does support EFS, go ahead and set up an encryption certificate.
  2. Export the encryption certificate, copy it over to the Windows 7 machine and install it.
  3. Create a folder and mark it as encrypted on the first machine.
  4. Copy the folder onto a USB drive formatted with NTFS.
  5. Finally, copy the folder from the USB drive onto the Windows 7 machine.
Any files created under (or copied to) the encrypted folder will be encrypted, themselves. In addition, this folder can be used as a template for creating additional encrypted folders. So, keeping an empty copy of the folder lying around can be useful.

There are a couple caveats to deal with, though.

  • The hard drives on both machines and the USB drive must be formatted with NTFS.
  • New folders on the Windows 7 machine cannot be marked as encrypted, unless they are children of folders already encrypted.
  • Once a folder or file has been encrypted, it cannot be marked as decrypted on the Home Premium machine.
  • Folders shared on the network cannot be decrypted - regardless of whether the certificate & key are installed on the client machine. This is why a USB drive is required.
I realize this seems a long way to go just to get EFS onto a weaker copy of Windows 7. To be honest, I don't use EFS on my laptop extensively; but the files I keep encrypted, I want them to stay encrypted, regardless of which machine they are stored.