Computer and Domain Controller Certificates

Posted on 2011-04-27
Last Modified: 2012-05-11
I have come into an environment where certificate services has been installed and an Enterprise Root CA has been created.  I've got several years experience with AD DS, but have never had to work with certificates until now.  We recently began having problems with Office Communications Server certificate expired that was issued by the CA.  I've installed a lab environment for learning and to troubleshoot the issue.  The lab consists of 5 machines: domain controller, certificate services, Office Communications server, and 2 workstations.  I have no GPOs configured execept the default settings - so nothing to do with certificate enrollment or trusted root CAs.  I have got Communications server installed and requested a certificate from my CA and imported it into the server.  Communicator generated a request in the form of .txt file, I took it into my CA server and submitted request and it gave me a .cer file.  Took the .cer back to Communicator server and imported it and everything is working fine.  Both workstations can connect an IM through the server.

What I would like to understand now is in our production environment, someone set up group policies for auto requesting the certificate.  Here are the settings in the production domain dealing with certificates:

Computer Config\Windows Settings\Security Settings\Public Key Policies\Automatic Certificate Request Settings\Automatic Certificate Request
- contains 2 objects: Computer and Domain Controller
..\Trusted Root Certificate Authorities
Allow users to select new root CAs - Enabled
Client comptuers trust the following stores - (default values)
To Perform auth. of users and comp. CAs must meet - Registered in Active Directory only
-contains a single certificate that appears to be the root CA itself.  It's name is domain-computer-CA and the issued by field shows the same value (example: mydomain-CERTS1-CA) with intended purposes of <All>

Those are the only GPO settings in the domain for Public Key Policies.  Can someone help me understand what these settings do?  And why did I not need them in my lab environment?  I intentinoally left them out in an attempt to discover what they do and was expecting to have to especially add the policy setting that adds the CA certificate to the trusted root settings on the servers/workstations.  The application works fine without them though...  not sure how Office Communications Server know it can trust the generated certificate without GPO adding the CA to the machine trusted root CAs.  Also, in production, due to the auto request GPO setting every computer and server has a certificate issued to it if I look on the CA management console or I can look at individual machines in Internet Settings > Content > Certificates.  I wonder if the machines are actually using these to authenticate on the domain?  It makes sense that the CA is issueing them because of the GPO, but how would I find out if they're really being used?
Question by:Wincit
    LVL 37

    Accepted Solution

    The GPO settings listed are used to allow workstations and servers to trust the Root CA Certificate of a Stand Alone or external CA server. The certificate that you see is the Root CA Certificate, which identifies the server as an acceptable generator for trusted certificates. You'll probably notice that the Root CA Certificate for many companies like GoDaddy and Network Solutions are installed. This allows the computers to have a chain of trust on the certificates that are generated by the CA. The chain of trust means that in order for a computer to accept a certificate without errors, it must trust the server that generated the certificate. In most cases, there are 2 certificates in each chain, the computer certificate, then the root CA certificate. Sometimes you may have subordinate CAs that expand the chain, so you have 3 certificates in the chain, the computer cert, the subordinate cert, and then the root CA. It's a little tricky to wrap your brain around at first, but it makes more sense as you study it. In an Enterprise CA environment, the Root CA Certificate is deployed by Active Directory automatically, so you don't have to have a GPO that has the Root CA Server in it.

    The production network's OCS may not have had its original certificate autoenrolled. If a certificate is enrolled manually, it must be re-enrolled manually when it expires. There are some other issues like permissions that may have prevented the server from pulling a new certificate for itself. I'm not really familiar with OCS yet, so I can't give much advice on that.

    By default, computer certificates are not used for authentication on the domain. You have to configure a Security setting in Group Policy to require signed communications in order for the certificates to be used in domain communications. When signing is required, it just allows server authentication. If you don't have that setting set, there isn't much need to enable it unless you are in a very high security environment. Generally, computer certificates are used in combination with User certificates to allow for certificate based logon. Smartcard logon uses this process to authenticate both the user and computer against the domain, usually for remote communication or for enforcement of 802.1x security.
    LVL 1

    Author Comment

    Thanks for your reply.

    I'll have to research what is recommended - if we should implement certificate based login or use the regular login (isn't that called Kerberos?).  All the networks I've worked in the past have not used certificates for domain authentication.  And appearantly this one doesn't either if I understood you correctly.  The following GPO settings are all disabled in Default Domain Controllers Policy:
    Microsoft network client: Digitally sign communications (always)
    Microsoft network server: Digitally sign communications (always)
    Microsoft network server: Digitally sign communications (if client agrees)

    By the way, that last one seems unnessessary since - if the network client (always) is disabled then from the server prospective, the client will never agree anyway.  Does that sound right to you?

    And in the Default Domain Policy that is applying to member servers and workstations, all these are set to Not Configured - and the "Explain" tab in the policy properties indicates that they default to disabled if no setting is specified.

    So... this means all those computer certificates I see issued are not being used?  If it's determined we don't need certificate based logins, then I could clean up all these issued certificates on the server right?  Or is it best practice to just let them expire?  I'd like to test this on a few PCs before making a mass change.  So I could remove the GPO setting for "Automatic Certificate Request" and then remove the Trusted Root CA on the client machine. Then since I want to see an immediate result for testing (not wait for expiration date) I need to remove it from the CA as the client appears under issued certificates in Certificate Services.  From what I've read, you can't really remove certificates, you have to revoke them.  What's a CRL for? and do you have to generate one everytime you revoke a certificate?
    LVL 1

    Author Closing Comment

    Grade of "B" because there was no response given to my last question.  However, the first response I got contained very accurate information and I was able to resolve my issues.  Just would have liked confirmation on the GPO settings and CRLs.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Do You Know the 4 Main Threat Actor Types?

    Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

    Introduction You may have a need to setup a group of users to allow local administrative access on workstations.  In a domain environment this can easily be achieved with Restricted Groups and Group Policies. This article will demonstrate how to…
    On July 14th 2015, Windows Server 2003 will become End of Support, leaving hundreds of thousands of servers around the world that still run this 12 year old operating system vulnerable and potentially out of compliance in many organisations around t…
    This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
    This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

    737 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    19 Experts available now in Live!

    Get 1:1 Help Now