Aug 302010
 

While setting up a PKI environment in our lab (using LDAP as our first CRL and HTTP as our second CRL), we noticed some weird behavior. We are using HTTP as a second CRL since most (if not all) of our clients are not joined to our lab environment’s domain.

When everything was installed and the certificates where distributed we noticed a weird error when connecting with RDP to one of our domain controllers. The error was “A revocation check could not be performed for the certificate”. Ok, this error would indicate that the client is not able to contact the CRL list which is located in AD and on the HTTP server.

image

While testing we noticed that the HTTP server was accessible for anonymous traffic. So that wouldn’t be the problem. While searching the internet for some relevant information we found two links which seemed to be related with our case. The Microsoft TechNet threads “Revocation check using LDAP URL fails” and “Certificate revocation check from external network”. While doing some tests we also noticed that domain joined systems didn’t have any of the same issues. So for some reason the RDP client could not failover to the HTTP CRL URL. To me it looks like a bug, and it’s something I’m certainly going to test more in a “private” lab within VMware Lab manager. Hopefully a sniffer trace or something like that will shed some light on this.

In the end we decided to change our PKI environment because we are lacking the time to trace the problem deeply. Instead of using Active Directory (or LDAP) as the first CRL and HTTP as the second CRL we switched it around and are now using HTTP as the first CRL and LDAP as the second CRL. This is currently working just fine.

Jun 282010
 

Ok, it’s been a long time since I wrote something but this really bothered me for almost a week. I was trying to install Forefront Client Security in our lab environment. I really thought that this couldn’t be that hard to just get it up and running. Most applications install subcomponents automatically, or at least they request for additional subcomponents to be installed. You’d be wrong if you thought this is also the case for Forefront Client Security. I’ve learned my lesson, RTFM 🙂

Anyhow there are a couple of things you really need to know before you even consider installing Forefront Client Security. There are some pre-requisites. First of all, Forefront Client Security is currently not supported on Windows 2008 x64. So, Windows 2008 R2 isn’t supported either. This was a little shock for me since I thought 64-bit was a commonly supported platform. Well at least for Microsoft Software. 🙂 So switching back to x86 was supported but still I couldn’t manage to install Forefront Client Security on my server.

After almost a week of trying to install the Microsoft Forefront Client Security I finally found  this Microsoft document which helped me to Install it. I still think that Microsoft should do a check of what software is installed and if not, install it or ask for it.

Since I’m running WSUS on a different server, I didn’t need to install WSUS again. Still though check out the pre-installation requirements below if you want to run it all on the same server:

  • Install Microsoft .NET Framework 1.1 with SP1
  • Install .NET Framework 3.0.
  • Install IIS and ASP.NET
  • Install SQL Server 2005 with SP2.
  • Install GPMC with SP1
  • Install, configure, and synchronize Windows Server Update Services (WSUS) with SP1

For me, leaving out WSUS worked fine, but come on, installing 2 versions of .NET framework, IIS, GPMC, couldn’t this be included in the installation wizard?

Anyhow, I did managed to get it up which made me pretty happy… 🙂

Apr 212010
 

This is a very quick message since I’m busy at the moment. Yesterday one of my fellow forum members at the Petri Knowledgebase posted a very interesting link to some videos Tech·Ed 2009. Since I’m always interested in such videos I thought I should share it 🙂

Edit: At the LinkedIn website I just found the dates for Tech·Ed Europe 2010

Tech·Ed Europe 2010 will be on Nov 8-12, 2010 at the Messe Berlin Conference Center in Berlin, Germany

Mar 012010
 

Well today i learned something new… Sometimes there might be some reason that you want to login twice on the same Windows server 2008 machine with the same username. Although I think you always should give each administrator his own account. But if you really want to login multiple times with the same username, Windows server 2008 will bring your current session to the newly logged in machine. For example:

If you are logged into a Windows server 2008 machine using the administrator account and your colleague wants also to login to the same machine with the administrator account, your session will be transferred to your colleague. Ok that’s annoying…

So how do we fix this?

Press the Start button and choose for option Run. In the run field type the command “tsconfig.msc” and press OK. The terminal server configuration will be opened.

Run tsconfig.msc

Once the terminal server configuration has been opened check out the middle console. You will find the option Restrict each user to a single session.Right click this setting and choose for properties. Then you will see the following screen where you can easily remove the checkmark.Terminal Server Configuration

Properties of the restrict user to single session