In order to use certificates for authentication, a security trend caused by the inadequacies of password-based authentication, a public key infrastructure (PKI) must be in place. Active Directory Certificates Services (AD CS) is Microsoft’s on-premise PKI solution and while it has been around for some time, there can still be a lot of confusion around the set-up process.
Here are the top 3 mistakes to look out for when setting up AD CS Certificate Templates.
Using AD CS Default Certificate Templates
The first step in creating your AD CS certificate template should always be to plan out which templates are necessary. It is essential to make sure your original templates are configured correctly as these templates are designed to be the mold you use to duplicate other templates. You can only modify the duplicates and must leave the original templates alone.
Furthermore, enterprise administrators are able to manage certificate templates by default. To change this, you need to create a security group and adjust role separations so only admins you have approved can have access. Once security groups have been established, admins can configure various policies to apply to AD CS certificates and exert control over how the network functions.
Not creating security groups leaves an opening for a threat to access the network and issue themselves any certificate or create their own “wildcard” certificate which can be applied to a domain and all its subdomains.
Using Active Directory
Using Active Directory may sound like an obvious choice, as AD CS only works natively when AD is the directory, but it can limit you with all the disadvantages that come with using an on-premise service.
Active Directory can come with a ton of hidden costs due to hardware and annual maintenance fees. Not to mention, hiring a team of experts who sparse in number and most certainly not cheap.
These expenses can add up quickly, and can be easily avoided by using cloud based services such as G-suite, Okta or Azure AD, which can simplify managing everything connecting to your AD. While AD CS does not natively support integration with the new wave of Cloud IdPs, managing your Microsoft CA with a cloud-based Enterprise PKI like SecureW2 allows you to support any SAML or LDAP Identity Provider and move away from your legacy AD.
Not Considering Recent PKI Technologies
AD CS predates Windows server 2008, and receives minimal updates and support from Microsoft making using AD CS much more costly and troublesome than other PKI solutions.
Cloud technology has progressed tremendously allowing organizations to take advantage of PKI that don’t require any additional hardware to be set up, eliminating any infrastructure cost associated with on-premise maintenance.
Cloud PKI’s also eliminate the need for hiring a team of expensive experts as they can easily be managed by just one part-time administrator. AD CS also lacks any certificate delivery mechanisms, which can further increase the IT load for proper deployment. SecureW2 solves this with the #1 Rated Certificate Deliver Platform, providing self-service clients for every OS so that end users can easily set up their own devices for certificates. It also comes with Gateway APIs that can be integrated with any MDM, or our IoT Platform, so that managed devices can be silently auto-enrolled for certificates.
SecureW2’s Managed PKI comes with all the infrastructure setup, takes less than an hour to integrate with an existing infrastructure, and doesn’t require any prior security or cryptographic experience. If you’re interested in learning more, check out our pricing page and see how our cost effective solutions can enhance your network’s security today.
