I have a fully working deployment of SCCM working in my domain environment. The problem is, I have a handful of clients that are non-domain bound which I still need to manage. From an SCCM standpoint this isn’t a terribly difficult thing to accomplish, however it requires a bit of work from the PKI side if you have an Enterprise PKI in-house. The following directions explain how I configured my Enterprise PKI to issue SCCM client certificates, and how I was able to install the client software manually on each machine.
Here is my topology breakdown:
- IssuingCA – CA1
- SCCM Server – SCCM1
- Workgroup PC – WORKPC1
- Domain Controller – DC1
Through trial and error I found out that the existing ConfigMgr client certificate I am using for my domain bound clients will not work with non-domain bound clients. The easiest explanation is that my Subject Name for the certificate is set to generate using the DNS name of the client. This is required to perform Auto-Enrollment and since everything is working as expected in my domain environment, I don’t really want to make any changes to this certificate.
The easiest way I found around this is to duplicate the existing SCCM client certificate template and create a new one specifically for your workgroup computers. I named mine “Workgroup ConfigMgr Client Certificate”. Once the certificate was duplicated, I edited the Subject Name tab properties to: “Supply in the Request” which should allow me to build a certificate specifying a Subject Name manually.
The other option I changed, was to enable “CA certificate manage approval” for enrollment. This adds an additional layer of security to help prevent rogue clients from requesting certificates from your PKI. Since I only have a handful of non-domain bound clients this adds only a small amount of additional administrative overhead to the process.
You will need to issue the new template to production before proceeding. To do so, close the certificate management console window, and right-click on the “Certificate Templates” folder. Choose New –> Certificate Template to Issue and select your new Workgroup certificate.
The next step is to log into the workgroup PC and create a certificate request config file using notepad. Here’s what mine ended up looking like”:
KeyLength = 2048
I named the file RequestConfig.inf and saved it to my desktop. It’s important to note that the Subject line needs to contain the FQDN of the workgroup PC and that if you are requesting a certificate from a Windows 2003 machine to a Windows 2008 PKI, the KeyLength field must be set to 2048. If you do not specify 2048 as the key length, Windows 2003 creates the request with the default value of 1024. You will receive an error message later on when you go to submit the request indicating a key size mismatch. It’s also very important that the CertificateTemplate line be identical to the name of your ConfigMgr certificate template created in earlier steps.
The next step is to generate the certificate request from the workgroup machine. From a command line, navigate to the location of your RequestConfig.inf file. Execute the following command: certreq -new -f RequestConfig.inf MyCertRequestFile.req where MyCertRequestFile.req is the filename of whatever you want to call your request file. You may want to name it after the workgroup PC since it will be easier to distinguish when performing the task on multiple machines.
Once the .req file has been created, you have to get the file on a machine that is domain bound in the same forest as your PKI. This allows you to access the PKI with appropriate rights. Open a command line from the domain bound machine and navigate to the location of your request certificate. Issue the following command the send the request to the PKI: certreq -submit -f MyCertRequestFile.req You will receive a pop-up window asking you to select the PKI you wish to send the request to. Select the appropriate issuing server and click OK. The request will submit to the PKI and wait for your approval.
Log into your issuing PKI server and open the Certification Authority console. Under the “Pending Requests” you should see your workgroup machine request. Approve and switch to “Issued Certificates”. Find the certificate and export it. Save it to a location where you can easily copy it over to your workgroup machine. If your environment is like mine, this entailed copying to two separate machines to traverse a firewall.
Back on the workgroup machine, import the certificate into the personal certificates store of the local computer. This completes the process of obtaining a certificate for Native Mode installations.
To complete the actual client installation, I used trial and error with many different command line flags against the installer executable. What I ended up with is: ccmsetup.exe /native:FALLBACK /mp:WORKPC1.MYDOMAIN.COM SMSSLP=WORKPC1.MYDOMAIN.COM SMSSITECODE=LAN CCMFIRSTCERT=1