A couple of weeks ago I performed an upgrade of my LAN at home. A trusty old Pentium 4 that had been doing it’s duties as a Windows Server 2003 domain controller showed signs of old age, and kept locking up at an increasing rate. I’m guessing that the hard drives, and possibly a couple of the fans had started to take enough of the abuse Trying to fix it wouldn’t make sense economically, and while I’ve spare parts and computers with similar specs I wanted to go 64-bit. It all ended up in me re-installing two low-end PowerEdge tower servers running Windows Server 2008 to 2008 R2. The improvements in Hyper-V was one of the reasons, but while at it I thought it would be a good idea to upgrade the domain controller too. (Note to others out there running Linux-based NAS boxes: don’t assume they like 2008 DCs just because they boast AD integration, and worked happily with 2003. Samba can bite my shiny metal ass…)

I haven’t actually upgraded the forest and domain level to 2008 yet, as most services will run with 2003 levels. I haven’t gone the whole nine yards transitioning to IPv6 either for that matter. What I have been taking a closer look at is Certificate Services. It’s been one of those components that have just been working for a long time out of the box, but the feature list said there were a couple of new bits to take note of. I’d like to provide a minor update based on a few things I have learned so far about them

Network Device Enrollment Service
The first “new” feature is NDES. (I say “new” because it was available previously as an add-on, but now it’s a native component of the OS.) NDES stands for Network Device Enrollment Service, also known as MSCEP, which is the Microsoft implementation of Cisco’s Simple Certificate Enrollment Protocol. The purpose of SCEP is to be able to enroll certificates to Cisco equipment like routers and switches, but it is open for others to implement too. A common feature of network equipment is that you cannot always enroll certificates the same way you do with a desktop or server – often the component cannot access the CA directly through a graphical user interface, and since you don’t like moving private keys around you don’t want to be copying pfx files around either you need a different enrollment mechanism. So basically, you “assist” the device by creating a sort of pre-enrollment request, and let the rest work itself out automagically. (Of course this is over-simplifying, but hopefully you understand what I’m getting at.)

How nice, but why are you telling us this? Do we care about Cisco in this context? No, possibly not, but we do care about the iPhone. And while it’s still a love/hate thing for many IT people the iPhone is unavoidable in more and more enterprises. As much Steve Jobs possibly classifies as a megalomaniac, the man understands that to progress further with this device in the enterprise, Apple needs to add enterprise features. The 3GS sports encryption, and the latest incarnation of the OS also supports client certificate based ActiveSync and all sorts of things. And even better, they’re taking steps towards manageability providing options for bootstrapping devices through the iPhone Configuration Utility. For a single-user scenario this tool works nicely, but you don’t want to use this en masse for deploying a large number of devices. And you don’t have too – you can create xml that can be send over-the-air much like OMA DM on Nokia devices. Based on this Good Technology has support for the iPhone in their product, and Afaria from Sybase hopefully has support coming during December if there isn’t an unexpected showstopper.

The profile can be pushed as mandatory, so the user cannot uninstall it. To accomplish this the profile is signed/encrypted with a certificate, and – you guessed it. This certificate is enrolled via SCEP. Unfortunately I do not have any slick screenshots at the moment showing how this works, but do have a look at the docs from Apple to learn more:
http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

SCEP is implemented as an ISAPI plug-in in IIS, and you interface with it through HTTP POST/GET. If you want to test that it’s all working enter the following URL in your browser:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(The message part of the URL can be any random text at this point.)
You’ll be rewarded with a file called “mscep” that contains the certificate of the CA in a binary form.

To actually enroll for a certificate you need to prepare a request device side, and depending on the configuration you might need to acquire a one-time-password as well. I’m testing out how this works in a Windows Mobile context, (I don’t develop for the iPhone), so I haven’t worked out all the low level bits yet. Hoping to present something at a later time.

Certificate Enrollment Web Services
The other new feature in 2008 R2, that actually is new and not re-cycled, is Certificate Enrollment Web Services. While there’s been a web interface for enrolling certificates it has required ActiveX, needed the site to be trusted, notoriously difficult using programmatically, not really supporting mobile devices…well… a few shortcomings. But everybody loves Web Services, and it has been created to simplify enrollment from non domain-joined computers and other platforms than Windows/Internet Explorer.

While my own DojoCert utility does what it’s supposed to do there are things I’d like to see better implemented. Problem is I’ve been limited as to what I can do in C# and the .Net Compact Framework. The native C++ APIs could probably produce something, but these are also intended for enrolling via LAN/WLAN. I’m not going into all the technical details here and now, as my early experiments shows you need to perform some tweaking to use it on mobile devices. (Not there quite yet, unfortunately.)

How does it work then?
Do yourself a favor if you are interested in this topic – read the following white paper from Microsoft. Should help you out in installing it on your CA.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=28b910f8-6374-48dd-a897-11fff62ab795

The short version is – the client will ask the Enrollment Policy Web Service what templates are available, and what requirements these templates have. Based on this the client generates a certificate request, sends it off to the Enrollment Web Service, and a response is returned. Sounds ever so simple, I know, and provided I can get it working I believe it adds value as opposed to the simpler NDES scenario. (How simple it really is I do not know the extent of yet.)

NDES/SCEP are primarily intended for machine certificates, so in a scenario where you issue certificates to both devices and users you might decide to go for both, or just the web services.

I’m hard at work looking at both these two alternatives, and I hope to get something to work. Although you never know what kind of snags you run into. Will be posting more, if I find something worthwhile