In this video from ITFreeTraining I will look at the two install options for Active Directory
Certificate Services: Stand alone and Enterprise. The fundamental difference between the two
is one requires Active Directory Domain Services and the other does not. This video will look
at the advantages and features supported depending on which you decide to use in your organization.
As stated, this video will look at the differences between a standalone CA and an enterprise
CA. At its simplest level, the enterprise CA requires domain services and thus must
be a member of the domain. The standalone CA does not require any additional
services to operate. Normally for this reason, a standalone CA will be installed on a server
that is not a member of the domain. It could be installed on a member server if required.
In most cases it will not be because being standalone gives you the option to take the
sever offline and only start it only when required. It is common practice with standalone
root CAs to take them offline when they are not required. In contrast to the enterprise
CA, the CA needs to be online. This does not mean that it has to have 100% uptime and cannot
be taken down for maintenance, but what it does mean is that it should not be taken offline
for extended periods of time. It is not uncommon for standalone root CAs to issue a few certificates
and be taken offline for years at a time. Since an enterprise CA has to be a member
of the domain and uses the Active Directory database, it needs to be online at least most
of the time. Having the enterprise CA online or any CA
online for that matter does present a security risk. The CA contains private keys which if
an attacker was to get hold of would compromise every certificate that was issued below that
CA in the certificate hierarchy. In the case of a standalone root CA, once it is offline
it is easy to protect by placing media in a secure area like a safe or physically locking
up the server. For this reason, the choice of which CA to choose often comes down to
what service it is providing. For a standalone CA, you will most likely
find it used to provide external certificate services. External services means certificates
for users outside the company or directly to the internet. If the CA needs to be accessible
via the internet, a standalone CA is the better choice. If an attacker was to gain access
to the CA, they would not be able to gain access to the domain since the stand alone
CA does not need to be member of the domain. Since an enterprise CA needs to be a member
of the doman it is a better choice for internal networks. Being on an internal network means
that it is not directly accessible on the internet and can also be placed behind a firewall.
This brings up the point, if a standalone CA is easier to protect, why use an enterprise
CA at all? Using an enterprise CA does give you more features at the cost of making it
harder to keep secure. The most noticeable is that a standalone CA can only offer manual
services. This essentially means that all certificates must be approved before they
can be used. In contrast to an enterprise CA, an enterprise CA can use the trust relationship
that is created when a computer is added to the domain. For this reason, an enterprise
CA can use this trust relationship to automatically provide certificate services to clients in
the domain without the certificate needing to be approved first by an administrator.
To put it another way, a client can request a certificate from an enterprise CA and have
it automatically be approved and the client can start using it straight away. In
standalone CA, a client would need to request a certificate and then an administrator
would need to approve the certificate for issuing before the client could start using
it. The last difference is that since a trust
relationship exists when a computer is added to the domain, a certificate that is issued
via an enterprise CA will automatically be trusted by the client receiving the certificate.
With a standalone CA the Certificate Authority must be manually trusted before the certificate
can be used by the client. This does not mean that the client receiving the certificate
from the standalone CA cannot be a member of the domain. What it does mean is that since
the standalone CA is not part of a domain, the domain trust model cannot be used to allow
the client to automatically trust a certificate issued from the standalone CA. If for example,
all your clients were members of a domain and you were using a standalone CA, you could
use group policy to configure all your clients to automatically trust the standalone CA.
The point to remember is that clients receiving certificates from a standalone CA will not
be able to automatically start using the certificates until they are configured to trust the standalone
CA. It is important to understand the differences
between a standalone CA and Enterprise CA so I will now go through an example of each.
In this example, a standalone CA is created. To protect the root standalone CA, a second
subordinate CA is created. In later videos I will cover how subordinate CAs work. For
the present think of it as a CA that can issue certificates on behalf of the root CA to clients.
In order for the subordinate CA to issue certificates, the root CA will issue it a certificate. Once
the certificate is issued, the root CA can be taken offline. You can see how since the
standalone root CA can easily be taken offline when not required, if no additional subordinate
CAs are added to the network, the root standalone CA may be offline permanently and put in a
secure location. Since the root CA contains private keys that are, pardon the pun, the
keys to the network, having it offline protects these keys. The subordinate CA is free to
issue certificates without the root CA being online and does not require access to the
root CA private keys in order to issue certificates. You can see that using a standalone CA how
easy it is to have excellent security. In later videos I will go into more detail about
how a CA can form hierarchies to create certificates. If I were to add the rest of the network in,
you can see how a typical standalone CA deployment would work. The standalone subordinate CA
would be placed on a DMZ or perimeter network that is accessible to the internet. This CA
is not on the internal network so if it were to be attacked, an attacker would not be able
to use this server to access the internal network.
Now a 3rd party can put in a request to have a certificate created on the standalone subordinate
CA. In order for the certificate to be issued, an administrator would need to approve the
certificate before it will be issued. Until this is done, the request will sit in the
pending requests queue on the certificate authority.
You can see that the advantage of using a standalone CA is it is very easy to secure.
The disadvantage is that certificates will need to be approved before they can be issued.
This is because without an approval system, the CA does not know who is asking for the
certificate and if they can be trusted. In cases like the one shown, the 3rd party
will be issued a certificate that will not expire for a descent amount of time. This
cuts down the amount of time an administrator will need to spend approving certificates.
Next let's consider an enterprise CA example where the CA is integrated into the domain.
In this example, a user wants to connect up to a wireless hot spot to connect to the company's
network. In order to secure the wireless hot spot you want to use certificates. When the
user connects to the wireless hotspot, their username and password is checked and a certificate
is issued from the enterprise CA. Certificates can be used for services like
wireless, smartcards and Network Access Protection. Network Access Protection or Nap is a system
that will issue health certificates to clients based on whether the client meets a number
of checks, such as if antivirus is installed. If you use any of these systems, depending
on how large the network is, 100's or even 1000's of certificates could be needed every
day. A standalone CA would not work for such a system because every certificate would need
to be approved by an administrator before it could be issued. For services like wireless,
the user wants to be connected straight away so waiting for an administrator to allow them
access is not practical. In this case, the user can be checked by using
their user name and password to ensure they are who they say they are. Once checked, the
certificate adds security to the connection and the user can use this certificate to access
other systems on the network. The last question you may between a standalone
and enterprise CA is can you combined the two giving you additional security and the
features you want where you want them? The answer is, yes you can. In later videos I
will be setting up a certificate hierarchy that makes use of standalone and enterprise
CA's. To do this you would first install your root
standalone CA. This contains the private keys that form the backbone of your certificate
hierarchy. If these were lost, the root CA certificate would have to be recreated and
every certificate that has been created revoked and reissued.
If I now add the rest of the network, you can see that there is a standalone Subordinate
CA that is located on the DMZ and an Enterprise CA located on the internal network.
Once the CA's are installed, the Root CA needs to create a certificate for each of
these CA's. These certificates would be installed on the standalone CA and the Enterprise CA.
Once these are installed the root CA is not required again unless anther CA needs to be
added to the network. For this reason, after the certificates are issued it can be taken
offline. To protect the root CA, some companies will
install the root CA on removable media like a USB hard disk and then place the root CA
in a safe to protect it. When a new CA is required to be added to the network it is
removed from the safe to create the certificate for the new CA and then placed back in the
safe afterwards. This covers the basics of a Standalone and
Enterprise CA. I hope you have enjoyed this free video from ITFreeTraining. In upcoming
videos I will be explaining more concepts of certificates as well as performing a demonstration
of how a certificate infrastructure like this one can be created and used in your organization.
All our videos are free and available on YouTube so consider subscribing to get the latest
videos. Thanks for watching and see you next time.