Myth Busting “Native Mode Requires a Microsoft PKI Enterprise CA with Windows Server 2003 Enterprise Edition”

It’s pretty well known now that in order to use the exciting Internet-based client management feature in Configuration Manager 2007, the site needs to be operating in native mode. This requires PKI certificates, which is a new juncture for many administrators. Configuration Manager doesn’t provide the means to help you create, deploy or manage the certificates – it simply requires that they are there, as an external dependency.

The good news about this design is that it offers the maximum flexibility in how you deploy those certificates. There is nothing proprietary about the creation or use of these certificates. They are standard v3 x.509 certificates, which means that can use any PKI to deploy the certificates. It doesn’t have to be a Microsoft PKI solution. Quite simply, if the PKI can create the certificates that are listed in the topic Certificate Requirements for Native Mode, then you can use that PKI solution to support native mode and Internet-based client management.

So why do I keep hearing reports that native mode requires a Microsoft PKI, an Enterprise CA, and running on Windows Server 2003 Enterprise Edition? Well, there are probably 3 reasons:

  • First, we recommend this solution because it’s another “better together” scenario and offers customers a complete solution from one vendor. We can’t help you with another vendor’s solution (for both legal and technical reasons) but we can help you implement a Microsoft solution by providing you with relevant information and pointing you towards additional references.
  • Second, we know that a Microsoft PKI, using an Enterprise CA and running on Windows Server 2003 Enterprise Edition, offers very practical methods for managing all the certificates that are required for native mode.
  • Third, existing native mode documentation (from us and third parties) refers to this combination precisely because it offers a very practical one-stop deployment solution.

 

What are these benefits that a Microsoft PKI provides? And what if you can’t meet all the conditions, for example you have an Enterprise CA but it’s running on Windows Server 2003 Standard Edition? Consult the Microsoft PKI documentation for the official answer, but here is my quick checklist of goodies that you get with each piece of the equation:

  • Using a Microsoft CA with IIS installed provides the benefit of Web enrollment, which is useful for both custom certificates (such as the site server signing certificate), and workgroup clients or clients on the Internet that cannot install certificates through Group Policy.
  • Using a Microsoft Enterprise CA provides the following benefits:
    • Root and intermediate CAs are automatically deployed to all computers in the forest
    • You can use the supplied certificate templates, which can greatly ease the creation of standard certificates.
    • Certificates can be automatically approved, based on Active Directory security permissions.
    • Certificates can be automatically renewed when they expire.
    • Certificates can be automatically deployed, using Group Policy.
  • Using a Microsoft Enterprise CA with the Enterprise Edition of Windows Server 2003 means that you can create your own certificate templates, so for example, you can create a new certificate template for the site server signing certificate by selecting the document signing capability and ensuring that the Subject Name field is provided at the time of certificate creation. Then filling in the resulting Web enrollment form for each site server is a snap, rather than supplying the unfriendly OID.

 

Of course, you don’t have to use the Web enrollment method to create the site server signing certificate (or any other native mode certificate). You could use text files to supply all the certificate requirements and request the certificates using the Certreq.exe utility – but it’s not as user friendly and can be more error prone than selecting UI options and filling out a form.

The documentation team for Configuration Manager can’t document all the possible ways to deploy the native mode certificates, or tell you how to design a PKI that’s suitable for your organization. But realizing that PKI is unfamiliar territory for many admins who are keen to try out the new features, we’ve tried to point you in the right direction. The topic Deploying the PKI Certificates Required for Native Mode has links to useful Microsoft PKI resources, and we’ve provided guidance for certificate deployment options for each of the certificates you will need to deploy. For an A-Z workflow that puts it all together, see Administrator Workflow: Deploying the PKI Requirements for Native Mode.

The step-by-step guide we’ve provided offers an easy and reliable method of deploying the basic certificates for native mode, as a proof of concept: Step-By-Step Example Deployment of the PKI Certificates Required for Configuration Manager Native Mode. We’ve had reports of customers successfully using these procedures, even with no previous PKI experience, so it offers a good starting point.

Note: This step-by-step is not the way to deploy the native mode certificates but simply one possible deployment method. The step-by-step can be used to achieve basic native mode communication on the intranet. It’s not the end of the PKI journey, but the beginning. These procedures will not fit every customer requirement, and the requirements for Internet-based site systems or NLB site systems are good examples. At this point you should do your own PKI homework, and if necessary, enlist the help of PKI specialists.

However, we have had customer requests for more documentation around the creation of certificates for Internet-based scenarios. If this applies to you, see my next blog post for some tips and a new documented scenario planned for November.

The verdict for the myth “Native Mode Requires a Microsoft PKI Enterprise CA with Windows Server 2003 Enterprise Edition”: Busted - but Recommended!

 

 

- Carol Bailey

This posting is provided “AS IS” with no warranties and confers no rights.