Skip to main content

Why XP clients cannot request web enrollment certificates from Windows 2008

By
One of the strong points of what Microsoft has been doing over the years has been to maintain compatibility with software for previous versions of its operating systems. This has worked well for a long time. After all, why would you go through the expense of upgrading all your clients to a new OS if it meant buying completely new software packages. The cost would be to prohibitive. As with all old technology, sometimes the old has to give away completely to the new. Case in point, take a look at what the telegraph did to the Pony Express.

The Web Enrollment on Windows Server 2008 has changed. On a Vista machine, it will look as it always has. On XP, it simply will not work. The Server 2003 enrollment control, XEnroll.dll has been replaced by CertEnroll.dll in Server 2008. The enrollment agent has been moved from the server to the client (Vista). Since XP and 2000 relied on the enrollment agent being available on the server, this legacy Oss are not able to request a certificate. So, how do you install a CA on a Server 2008 based system without completely upgrading all your clients to Vista first? It’s a little combination of the old and the new.

First off, you can use a Vista client to request the certificate for the legacy OS. This is all fine and dandy, but a little cumbersome. The other option is to follow a best practice and have a subordinate CA that is running Server 2003 with Web Enrollment installed. This will allow your legacy Oss to continue functioning happily in a secured environment.

12/08/2008
Correction to paragraph 2

I’ve found some contradictory information. XP/2000/2003 can still use web enroll on a Windows @008 AD CS server. AD CS will detect the legacy operating system and use Xenroll.dll to issue the certificates. One thing to note is that Smart Card enrollment is not support on the legacy applications unless you use one of the other methods mentioned.

Refferenc: http://technet.microsoft.com/en-us/library/cc732517.aspx
Labels:

Comments

Post a Comment

Popular posts from this blog

How to run GPResult on a remote client with PowerShell

By
In the past, to run the GPResult command, you would need to either physically visit this client, have the user do it, or use and RDP connection.  In all cases, this will disrupt the user.  First, you need PowerShell remoting enabled on the target machine.  You can do this via Group Policy . Open PowerShell and type this command. Invoke-Command –ScriptBlock {GPResult /r} –ComputerName <ComputerName> Replace <ComputerName> with the name of the target.  Remember, the target needs to be online and accessible to you.
Post a Comment
Read more

Set up your Environment to utilize Invoke-GPUpdate

By
I’m sitting in O’Hare enjoying my 3 hour layover as I get ready to teach a Windows 10 class in Fort Wayne.  I’m actually prepping for my class in Fort Wayne in a few weeks, 10982 Supporting and Troubleshooting Windows 10.  This class is very much like the Windows 7 version that I used to teach so I decided to up the detail quite a bit.  In the GPO troubleshootin chapter, I’m including a demonstration on how to use PowerShell’s Invoke-GPUpdate.  I needed to make sure the environment is set up for me to be able to utilize this cmdlet.  If you read the Notes section on Invoke-GPUpdate’s help file, you will see there are three firwall rules that need to be in place:          Remote Scheduled Tasks Management (RPC)          Remote Scheduled Tasks Management (RPC-ERMAP)          Windows Management Instrumentation (WMI-IN) I decided to create a little PowerShell script to crea...
Post a Comment
Read more

Where did a User’s Account Get Locked Out?

By
Updated: May 15, 2015 When this article was originally published, two extra carriage returns were add causing the code to malfunction.  The code below is correct.   My client for this week’s PowerShell class had a really interesting question. They needed to know where an account is being locked out at. OK, interesting. Apparently users hop around clients and forget to log off, leading to eventual lock out of their accounts. The accounts can be unlocked, but are then relocked after Active Directory replication. This problem is solved in two parts. The first one is to modify the event auditing on the network. The second part is resolved with PowerShell. The first part involves creating a group policy that will encompass your Domain Controllers. In this GPO, make these changes. Expand Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Account Management Double click User Account Management C...
18 comments
Read more