none
Setting Up PKI infrastructure for SCCM

    Question

  • I having so many problems I thought I would step back and ask a couple of questions before going further.

     

    1) Does the PKI CA structure need to be on a Domain Controller or will any server in the Domain with Windows 2003 Enterprise work OK? Currently my PKI CA is hosted on a non-domain controller and I am wondering if that is part of my problem. I know that Enterprise is required to auto-enroll the site signing certificate, but since the recommendations always say that one should do all of the certificate creation from a Domain Controller, I wonder if this requires it to be on a DC as well as being on an Enterprise version of Windows.

     

    2) I have considered revoking all outstanding certificates, destroying the complete PKI CA and starting over. The reasons being that I now cannot push the SIte Server Signing Certificates to the clients, and can't even request them from a client.

    Or will this idea cause me more harm than good?

     

     

    Monday, January 28, 2008 2:22 PM

Answers

All replies

  • Addendum: I revoked all certificates relating to clients. I killed the current Signing Certificate. I rebuilt it from scratch (again!) and can't push it through Group Policy, nor can I request the cert from a client:

    "The certificate request failed because of one of the following conditions:

    - The certificate request was submitted to a Certification Authority (CA) that is not started.

    - You do not have the permissions to request certificated from the availavle CAs."

     

    In the first case, I was able to install the cert on the SCCM 2007 server, so I doubt that.

    In the second case, I am trying as an Enterprise Admin. In addition, the article I am using for configuration information doesn't change the rights on the COmputer template used for creating the Site Server Signing cert.

     

    Anyone have a clue as to what I might be doing wrong?

    Monday, January 28, 2008 4:24 PM
  • Configuration Manager will work with just about any type of Certificate Authority.  In your case, having the certificate authority auto-enroll clients is an issue external to these forums.  You may want to contact the provider directly or review some of the articles online for setting up auto-enrollment.

     

    Configuring Autoenrollment on Server 2003

    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx

     

    Monday, January 28, 2008 8:16 PM
  • Gabe is correct - the PKI setup and configuration is external to Configuration Manager.  However, some pointers that might help:

     

    If you're new to PKI then I hope this is a test lab.  If so, then probably your best bet is to tear it down and rebuild Active Directory because an enterprise CA writes to AD and "killing" it isn't easy.  I seem to remember having to go into ADSIEdit to clear it out properly. So there's a good chance your computers still know about the old CA and can't contact it, although you've uninstalled it.  Revoking certificates and then destroying the CA will also destory your CRL unless you've published this somewhere else - so computers will have no way of know that they are revoked because they won't be able to contact the CRL

     

    In a lab enviroment, I recommend you follow our step-by-step exactly, including all the test network requirements: Step-By-Step Example Deployment of the PKI Certificates Required for Configuration Manager Native Mode (http://technet.microsoft.com/en-us/library/bb694035.aspx).  As soon as you make any modifications to these steps it can have an impact that prevents things from working.  If you get this working and then make small changes to better suit your production network, you are more likely to resolve issues.

     

    Autoenrollment is a good option for the client certificates and the Web server certificates - but not the site server signing certificate. You can't autoenroll the site server signing certiifcate with Group Policy because it needs a custom string in the certificate subject - which contains your site code.  That's why the step-by-step includes changing the option to "Supply in the request" and then uses Web enrollment to type in the string.  And I wouldn't advise using autoenrollment for such an important certificate. That's why the step-by-step doesn't change the default permissions for the computer template, because it's using manual approval. You could make the permisions more restrictive, but it's not necessary to get it to work.

     

    Don't deploy the site server signing certificate to clients using PKI certificate deployment - only to the primary site server. The client-side gets handled automatically (either through Active Directory or the management point) or manually through CCMSetup.  For more information, see Decide How to Deploy the Site Server Signing Certificate to Clients (Native Mode) (http://technet.microsoft.com/en-us/library/bb694140.aspx). 

     

    Hope this helps!

     

    - Carol

     

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

    Tuesday, January 29, 2008 8:13 PM
  • Following the steps exactly was what caused my client push *not* to work. HTTP filures were reported when using the suggested Common name on the SUbject Name tab when configuring the web certificate. After changing that to Fully distinguished name, it started installing clients correctly.

     

    Wednesday, January 30, 2008 10:32 PM
  • Something doesn't sound right here.  Are you referring to the instructions that say:

     

     ...select one of the following for the Subject name format:

    • Common name: Select this option if you will use fully qualified domain names for site systems in Configuration Manager (required for Internet-based client management, and recommended for clients on the intranet).
    • Fully distinguished name: Select this option if you will not use fully qualified domain names in Configuration Manager.

    The common name produces a CN= value that is the computer's FQDN and the fully distinguished name produces a CN= value that is the computer's short name. You can check this yourself by viewing the deployed certificate in the Certificates MMC and the "Issued to" field. Or double-click the certificate and check the Subject field in the Details tab.

     

    Are you saying that you selected the common name, it produced a certificate with the FQDN, and client push failed when your management point was configured with an FQDN?  Or was your MP not configured with an FQDN?  The certificate configuration and MP configuration are independent, so you have to match these yourself.  There was a bug in a pre-release version but fixed in RTM that client push failed in native mode when the MP was configured with an FQDN (only client push, not other client-to-MP communication - for example clients already installed or installed uisng another method) - but I'm sure you must be using an RTM version?

     

    - Carol

     

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

    Friday, February 01, 2008 6:18 PM
  • What worked was to use the FQDN in the Subject name format option and in the MP configuration. I already had the MP in FQDN configuration when the first certificate was created. What happened is that with Common name selected, it produced a certificate with just the common name in it, which is backwards of what the instructions say.

     

    And yes, I am using an RTM version.

     

    Friday, February 01, 2008 7:41 PM
  • What you are describing doesn’t match the results I get when I test this.  For example I can request a certificate for the same computer using 2 different templates, using the option “common name” in one template and “fully distinguished name” in the other template.

     

    Selecting the option “Common name”, results in my certificate looking like this when I look at the Subject field in the certificate Details tab:

    CN = server1.contoso.com

     

    Selecting the option “Fully distinguished name”, results in my certificate looking like this when I look at the Subject field in the certificate Details tab:

    CN = server1

    OU = Web Servers

    DC = Contoso

    DC = com

     

    Native mode uses only the CN value, which is why although it sounds the wrong way around, choosing the common name option matches the FQDN configuration, and the fully distinguished name option matches the NetBIOS configuration.

     

    I have tested this many times (including Windows Server 2008) and I’ve always had this result. I can’t think what configuration you might have that would flip them around and I haven’t heard of anybody else having a problem with these documented the wrong way around.

     

    I’m please you got it working, though!

     

     

    - Carol

     

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

     

     

    Saturday, February 02, 2008 1:35 AM
  • From my hands-on lab on migrating from a mixed mode to a native mode environment, I actually followed Carol's docs, the step-by-step guide explicitly. For my web server certificate, I specified to use the Common name, and my site is publishing FQDN for all site system roles (in my case all are on the same box).

     

    Everything works in the lab to migrate to native mode. So, from my experience, what Carol has written absolutely works.

    Monday, February 04, 2008 4:22 PM
  • I've tried following the Step-by-step example provided by Microsoft but I am getting permissions issues.

    We are migrating from SCCM 2007 to SCCM 2012. We currently have SCCM 2007 working in Native mode. When I try to issue the newly created certificate I am getting a permissions issue. "The permissions on the certificate template do not allow the current user to enroll for this type of certificate."

    I find this confusing because the guide says to uncheck the "Enroll" permissions for Domain and Enterprise Admins yet the user account I am using to install SCCM is a Domain Admin member. I also have my server in the ConfigMgr IIS Server group which has "Read" and "Enroll" permissions. Am I missing something here?

    Monday, April 30, 2012 3:12 PM
  • The step-by-step in the Configuration Manager documentation library requests the web server certificate by using the Certificates MMC from the local computer store, which uses the machine security context - Read and Enroll for the computer from which you are requesting the certificate.  And the computer gets these permissions by adding the computer to a security group and granting the security group Read and Enroll.  If you were requesting a user certificate, or using Certreq.exe to request the certificate (which always uses the user context, even for computer certificates), then you would use the user context to request the certificate.  Because this is a computer certificate and because of how you're requesting it, the user account permissions is not needed (removed for security best practices).

    By default, the web server certificate template gives Read and Enroll to Domain Admins and Enterprise Admins because it is often used to request a certificate from an external CA, so an admin would request it from a proxy computer in the user context, install it into the user store temporarily when the request is granted from the external CA, then export the certificate from that computer and import it to the computer that will use it (into the computer store).  In this scenario, it's safest to use the user context to request and install the certificate.  But when you can request the computer certificate directly from the computer and certificate store that will use it (which you can do when you use an internal CA), it's more secure to use the computer context.

    On a production environment, you often see a delay in replicating certificate permissions - in my experience, this is often why you can't request a certificate if you've just configured it (either just configured the certificate template or just applied new security permissions to it). You typically don't see this delay in a test environment, which is why it's a good idea to get this working first in a small test environment so you have the confidence that you've configured it the same, in which case replication delay is a good contender for what's different. And of course, if you're adding a new server to the security group, make sure you reboot that server to pick up the new security group. 

    Sunday, May 06, 2012 2:46 PM