Archives for January 2013

MS Security Compliance Manager 3.0 Hits the streets

One of the absolute best tools for managing security group policy settings in a Microsoft environment is their Security Compliance Manager. Hot off the presses is version 3.0, which is a major step forward in both functionality and OS/product support.

The full product announcement from Microsoft is here. The most exciting news for me is full support of Windows Server 2012, IE 10, and configuring stand-alone machines. Oh yes, Windows 8 support, but who’s even using that?

Not new to the 3.0 release, is the ability to compare different baselines, archive baselines, and create your own custom baselines that you can export to a GPO. Your IA guys should love it!  And in case you missed it, there’s a beta version of a SCM baseline for SQL Server 2012 you can find here.

Are VMware vSphere 5.1 bugs behind us?

If anyone has been following the release of vSphere 5.1, you know it was not exactly a smooth launch. In fact, I would dare to call it a huge debacle. To me, it seems like it was rushed out the door without having components even beta tested, like the required SSO service. The original SSL certificate replacement instructions were 100% wrong, plus several components were very buggy. I really have no earthly idea how the code made it past internal quality assurance.

Clearly VMware recognized the 5.1.0 GA version had significant problems, and support calls probably clogged their phones. I know I personally spent many hours with the India support desk trying to fix SSL problems, with little success. So a few weeks after 5.1.0 GA, out came 5.1.0a. This helped, but still had a number of install problems and bugs. In late December 2012 they shipped 5.1.0b, which did zap many remaining installation bugs. Meantime, they also published a number of KB articles covering the right way to replace the certificates. Several articles have had revisions since their initial release.

So using the vSphere 5.1.0b media, refreshed VMware KB articles, and updating my own 15 blog articles, I finally got through a complete install without having to hack VMware scripts or do other undocumented steps. Easy? No. Quick? No. Vastly harder than it should be? Yes. Feel fragile? Yes.

Should you bet the stability of a large enterprise production environment on vSphere 5.1.0b? Only you can answer that for yourself, but personally this is the first release of vSphere that I won’t put into production. vSphere 5.0 U2 is very stable, and there aren’t any compelling features for my environment in 5.1 that I can’t wait to get rolled into vSphere v.Next due out in late 2013.

I’m also hopeful the new VMware CEO will put an emphasis on quality, and not push releases out the door that are not production ready. Just yesterday VMware announced some layoffs, spinning off a few products, and re-focusing on their core technology. I hope that includes re-focusing on quality releases and not just packing in new features to one-up Hyper-V.

Even if you don’t want to put 5.1 into production, I would strongly urge you to install it in a lab environment. Get used to the new web client, try out the new VDS features, etc. This will help you ramp up quicker on vSphere v.Next. Plus if you run into any bugs, open a support case so the future releases are more stable.

You can find Part 1 of my 15-part vCenter 5.1 installation series here. It was a lot of work, but I tried to incorporate my own lessons learned, reader feedback, and changes in VMware KB articles. In my home lab I now have a running vCenter 5.1.0b install, and I have yet to see any SSL problems or broken services.

If anyone follows my revamped guides and still has problems, please leave comments for the appropriate article. I can’t guarantee I’ll respond to all comments, but other readers may.

Create Trusted Remote Desktop Services (RDP) SSL Certificate

For Windows environments that want extra security, one of the features that has been around for ages is requiring TLS 1.0 for Windows RDP (Remote Desktop) connections. This functionality requires a certificate on the server, since TLS is based on the usage of X.509 certificates. Installing a RDP SSL certificate is easy.

By default Windows will create a self-signed certificate automatically for use with RDP. But as we all know, self-signed certificates are nearly worthless, and could easily be intercepted for man-in-the-middle attacks. So one should reconfigure Windows to use a trusted certificate. Thankfully this is fairly easy, and once configured, pushed down to all servers via GPO for automated deployment.

I’ve validated that this procedure works both on Windows Server 2008 R2 and Windows Server 2012. It may work on Windows Server 2008.It requires the use of a Microsoft enterprise online certificate authority. Again, I’ve used both Windows Server 2008 R2 and Windows Server 2012 CAs with success. Not surprising, since certificates are industry standard. For the purposes of this article I’ll use Windows Server 2008 R2 CA, and Windows Server 2012 “target” server.

The general process is first creating a new Certificate Authority certificate template that has an extended key usage to limit its use to only Remote Desktop TLS sessions. Second, we configure a GPO setting to automatically configure servers to request a certificate via this template, and use it for RDP TLS. Refresh GPO on the target server, and finally we attempt to connect via a stand-alone computer to verify it sees the certificate that we deployed.

Installing a RDP SSL Certificate

1. On your Microsoft certificate authority server open the Certificate Templates console.

2. Duplicate the Computer template and use the Windows Server 2003 Enterprise format (Server 2008 v3 templates will NOT work).

3. Change the template display name to RemoteDesktopComputer (no spaces). Verify the Template Name is exactly the same (no spaces). You can use a different name if you want, but both fields must match exactly.

4. Now we need to create an application policy to limit the usage to RDS authentication, then remove the other application uses for the certificate. On the extensions tab click on Application Policies then click on Edit.

5. Click on Add, then click on New.  Set the value of Name to Remote Desktop Authentication. Change the object identifier to

6. From the Application Policies list, select Remote Desktop Authentication.
7. Back on the certificate template properties, remove all other entries. Only Remote Desktop Authentication should be present.
8. If you wish, you can modify the validity period of the certificate, making it say two years instead of the default of one.
9. You probably want to secure your domain controllers as well, so for that we need to modify the security setting on the template. Open the Security tab and add the group Domain Controllers and give the group Read and Enroll (not Autoenroll).
10. Open the MMC snap-in for managing your Certificate Authority and locate the Certificate Templates node. Right click, select New, then Certificate Template to Issue. Choose the RemoteDesktopComputer template.
11. Next up is configuring the GPO to utilize the new template. You can modify any GPO you wish, or create a new one. Obviously the scope of the GPO should cover any servers that you want to secure with TLS. This could be a server baseline GPO, domain GPO, or whatever you want.
12. In the GPO editor locate the node Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session HostSecurity. Modify the Server Authentication Certificate Template setting. Enable the policy and enter the certificate template name that exactly matches what you created in your CA.

13. In the same GPO node, configure the Require use of specific security layer for remote (RDP) connections to use SSL (TLS 1.0).

14. Wait for the GPO to replicate, then refresh the GPO on a test server. Wait a minute, then open the Certificates MMC snap-in for the computer account. Look in the PersonalCertificates store for a certificate that has the Intended Purposes of Remote Desktop Authentication. If it’s not there, wait a minute, and refresh. If it never appears, something is wrong. Look at the gpresult to make sure your GPO is being applied to the server.

15. Once the certificate appears, double click on the certificate to open it. On the Details tab look at the first few characters of the thumbprint value and remember them.

16. To make sure the RDP service is aware of the new certificate, I restart the Remote Desktop Services service.

17. Open an elevated PowerShell prompt and run this command:

Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

Validate that the Security Layer value is 2 and that the thumbprint matches the certificate. If both of those settings are correct, then you are good to go!

As a quick test I attempted to connect to this server from a non-domain joined computer that did not have the root certificate for my CA. I configured the RDP client to warn on any security issues. As expected, the client threw errors about the CRL not being available, and that it didn’t trust the chain. I also viewed the certificate and verified it was the correct one.

It seems Windows 8 has much more stringent certificate checking than Windows 7. The screenshots below are from Windows 7, in case you didn’t recognize the chrome. When using a Windows 7 non-domain joined computer to access the same TLS protected server, I got NO certificate warnings. That was even with the RDP 8 add-on hotfix. I’m glad to see Win8 does thorough certificate validation.

Connecting to the same server from a domain-joined computer that trusted the root CA resulted in no security warnings and a successful connection. If you look at a Wireshark capture you can also validate that CRL information is being exchanged between the computers, which means TLS is being used.