Preparing PKI in a Windows Active Directory Environment

If you’re installing and implementing internet access for an internal windows based network then there’s two important factors you should consider.  Firstly  it’s important to ensure that your perimeter is protected and access is only allowed through a single point.  This might seem trivial but it’s actually crucial to ensure that the network can be controlled.  Any network which has thousands of individual clients accessing the internet directly and not through a proxy is going to be almost impossible to protect.

The second aspect relates to the overall client and server security – ensure that your windows environment has the Active directory enabled.  This will also allow you to implement the Microsoft Windows PKI.   From Windows 2003 onwards this is already included and PKI is preconfigured in the Windows 2003 schema whether you wist to implement it or not.

If you are considering using Windows PKI then remember although the active directory is a pre-requisite for a straightforward installation, it does not require a domain functional level or even a functioning forest to operate in.   In fact the only configuration you require in the later versions of Windows is to change the Cert Publishers group which is needed in any multi-domain.  This group is pre-populated as a domain local group in each domain in an Active directory forest by default.

This is how PKI is implemented, you can allow any enterprise level certificate authority (CA) the rights to publish certificates to any user object in the current forest or to the  Contact  object in foreign forests.   Remember to enable the relative permissions by adding the CA’s computer account to each domain’s Cert Publisher group.  This is essential as the scope of this group has changed from a global group to a domain local group, but this allows the group to include members of the computer accounts from outside the domain.  This means that you can add computers and user groups for external access by including an external gateway.  For example if you wanted to proxy BBC streams and cache them you could include the proxy server in this group in order to minimize authentication traffic.

You are unable to currently deploy the Windows Server Enterprise CAs in Non- Active Directory environments. This is because the Certificate Authority requires the existence of the AD in order to store configuration information and certificate publishing.  You can install Windows Server PKI in a non-AD environment , however each CA in the PKI hierarchy must be standalone.  This is workable in smaller environments but can be a real challenge to configure communications in large or distributed networks across many network subnets.  Trying to ensure that the right Certificate Authority is assigned across a multinational network is difficult without the Active Directory.  Remember you may have clients and servers requesting authentication from different networks in a UK company you might have a client desktop with an Irish IP address seeking authentication from a London based standalone CA in a different domain.