A primary weakness of password-based authentication is the human element. Passwords can be forgotten, shared, or stolen, making them a nightmare for IT admins. Forgotten passwords can lead to service interruptions and a pile-up of support tickets. Stolen passwords can compromise the entire network because a hacker needs only one set of credentials for network access. 81% of data breaches can be traced back to weak/stolen passwords, and most SMBs will go bankrupt if victimized by a cyber attack.
The alternative to password-based authentication is certificate-based authentication (CBA), which requires a few components like certificate authorities (CAs) and a Public Key Infrastructure (PKI). Microsoft offers their own (CAs) so they can implement a Public Key Infrastructure. PKIs are becoming popular in the network security field because they enable electronic workflows and provide SSL server and email security, just to name a couple.
We will learn how to manage these certificates so you can securely authenticate to WI-Fi, VPN, and more. See how easy it can be by reading what our customers say.
What is AD CS (Active Directory Certificate Services)?
Digital certificates are quickly becoming the network security standard for major enterprises because the abilities of certificates far exceed the abilities of passwords. Passwords are an obsolete form of authentication because there are major vulnerabilities in security and user experience.
Organizations running on Microsoft environments can use a Microsoft CA to leverage Active Directory and Microsoft certificate services to distribute certificates to all your domain-connected devices through group policies. Certificates have proven to be more secure and easier to use than passwords. Microsoft realized this and deployed AD CS to help Microsoft environments take advantage of certificate benefits.
Active Directory Certificate Services (AD CS) is a Windows server designed to issue digital certificates by providing a platform to build and implement a PKI. AD CS is linked to Active Directory, a Windows server that acts as a database.
Deploying Certificates for Windows Environments
Passwords leave large gaps in security and positive user experience, With the right tools, certificates can overcome these flaws. 802.1x authentication is available and simplified with certificates because they authenticate with EAP-TLS, eradicating over-the-air credential theft. Certificates are encrypted, so even if one is compromised, it’s useless for the hacker. Once a device is equipped with a certificate, that device is easier for network admins to identify.
Certificates also make it easier to deploy 802.1x authentication for AD customers migrating to Azure AD (Microsoft Entra ID), which will be discussed further below. In order to deploy certificates, admins need a Public Key Infrastructure (PKI). There are two options for deploying a PKI: building one on-premise or using a managed PKI service.
Microsoft developed Active Directory Certificate Services (AD CS) as a way for their clients to build their own PKI on-premise. Many Windows clients choose this option because they need to integrate their Active Directory so PKIs know who to authenticate. It seems like the logical choice because it’s ostensibly easy to integrate and deploy certificates, but AD CS provides limited network abilities and gives IT departments much more grueling work to complete. Plus, transitioning to cloud computing is out of the question as long as your organization runs on AD CS.
The better option is integrating your Microsoft environment with a managed PKI service because it requires less time to set up and is more cost-effective.
Vulnerabilities of AD CS
It’s understandable why Microsoft clients who want to deploy certificates would choose an on-premise PKI to fully integrate their AD, but in doing so they are adding extra work for their IT department and authenticating with sub-par protocols. In essence, an on-prem PKI is more work and expenses for less security and capabilities.
On-premise PKIs are incredibly expensive to set up because there are so many components to include, each with its own price tag. Enterprises need to pay for hardware and software implementation, maintenance fees, software licensing, secure hardware storage, data backup, disaster recovery, and much more. All of these expenses often come as hidden costs, meaning enterprises aren’t aware of these costs until it’s too late.
All of this planning and setup means that on-premise PKIs take months to fully implement, and we haven’t even discussed personnel. Once an enterprise has decided to deploy an on-prem PKI, it will need to hire and train a team of cryptography and server experts. Training current employees means more work for the IT department and can lead to faster employee burnout. The administrative and HR costs of hiring new employees add up as well. The overall expense of an on-prem PKI makes it an illogical investment.
Dozens of Microsoft clients authenticate with PEAP-MSCHAPv2, which again seems like a no-brainer. However, as we explained already, any authentication protocol that relies on passwords is vulnerable to cyber-attacks because passwords are just too easy to bypass. There is a well-known vulnerability with PEAP-MSCHAPv2’s encryption that allows hackers to steal and decrypt data packets. Once again, the weak point lies with passwords because if a hacker acquires the login credentials from one employee, the entire network could be compromised.
Ensuring every network device is equipped with a certificate is not possible with AD CS. BYODs are out of the question because AD CS isn’t designed to work with non-Windows devices. Enterprises with MDMs resort to manually configuring each device for certificate enrollment, which is a pain for IT admins and risky when left to end-users. Building and maintaining your own PKI through AD CS is time-consuming, difficult, and requires a lot of expertise. If done poorly or mediocrely, it’s cheap for most customers because they’re not using HSMs and other security measures.
Establishing trust is key for online communications between two or more entities. AD CS networks with on-prem PKIs require that the enterprise act as their own Certificate Authority (CA) instead of using a third party CA with a managed PKI. If a certificate is issued by an enterprise-run CA, it’s less likely to be fully trusted by other parties. Enterprises who want to conduct business online will need to pay for and set up additional infrastructure just to make that work.
Microsoft Environments Should Use SecureW2’s Managed PKI
Managed PKIs are far better for Microsoft environments because they do not require the time-consuming implementation and are a fraction of the price of on-prems. Since it’s all on the cloud, there’s no need to overhaul infrastructure, relieving IT departments from the extra workload and saving the enterprises hundreds of thousands of dollars.
Personnel costs are also greatly reduced because enterprises using a managed PKI only need one part-time employee to cover PKI management instead of an expensive team of experts.
Enterprises with MDMs use a managed PKI to ensure every managed device is enrolled with a certificate for network access. Using PKI software allows admins to build powerful Gateway APIs, such as SCEP, to push out configuration policies that automate device configuration and enable automatic certificate enrollment. This saves admins the trouble of manually configuring every device and requires no end user interaction. If you have Microsoft Intune, check out our guide on integrating SCEP to enroll certificates.
Azure AD customers can integrate SecureW2’s software and create a SAML application in Azure and securely authenticate end-users. After clicking a few buttons, the end-user device is equipped with a certificate and granted network access. For more information on integrating Azure AD, check out our article discussing how to issue and manage certificates with Azure.
We provided a short clip showing the process of testing a SAML application:
SecureW2’s managed PKIs authenticate devices with EAP-TLS, the preferred method because both the end user and server are authenticated with certificates. OTA credential theft and man-in-the-middle attacks are useless because authenticating with EAP-TLS ensures that an approved device is connected to the approved server.
Issuing and managing certificates is incredibly straightforward with our GUI interface, something not available with AD CS. Admins have a much easier time configuring certificate templates and group policies, mapping attributes, and securely issuing a certificate to every device.
Networks can deploy 802.1x authentication with confidence because SecureW2’s software comes with EAP-TLS and Cloud RADIUS.
How to Integrate Microsoft CAs with SecureW2
Instead of wasting time and money with an on-prem PKI, Microsoft clients can import their AD CS servers in SecureW2’s software. Our Cloud Connector provides a seamless transition to the cloud and strengthens network security. AD environments no longer have to be tied to an on-prem footprint and can experience the versatility of cloud-based solutions.
Backup CA on AD CS
- Step 1: Open the Certification Authority snap-in. In the console tree, right-click the name of the CA. On the Action menu, point to All Tasks, and click Back up CA.
- Step 2: A popup wizard will be opened (as shown in the figure below). Click Next.
- Step 3: A new screen with Dialogue Box appears as below. Select Private Key and CA certificate. Select a folder in which you want to save the certificate.
- Step 4: When the new screen appears, enter the password twice. Click Finish on the next screen.
Import CA in Cloud Connector
- Step 1: Log in to JoinNow MultiOS Management Portal. Navigate to PKI management -> Certificate Authority and click on Import Certificate Authority.
- Step 2: The basic certificate authority page is displayed. Select the p12 file in Certificate.
- Step 3: Enter Password that was created when exporting the Certificate Authority.
- Step 4: Once completed, ensure the certificate is created in the screen below.
Note: While importing the CA certificate, only SHA-256 or SHA1 are supported as the signature algorithm.
Integrating Microsoft CA’s with SecureW2 Enables More Abilities and Costs Less
Microsoft Windows environments may decide to deploy an on-premise PKI with AD CS to maintain the connection to AD, but they are restricting their networks to sub-par security standards and adding much more work for the IT department. AD CS doesn’t support BYOD onboarding and you can’t easily deploy certificates onto every network device with AD CS.
Manually configuring every device is tedious for the IT department and incredibly risky when left to the end-user. Instead, use SecureW2’s JoinNow Solution software to simplify device onboarding for both BYODs and managed devices by setting up auto-enrollment.
Instead of shelling out thousands of dollars deploying an on-prem PKI, go with SecureW2’s turnkey PKI solutions, saving you the hassle of building a PKI by yourself. Get better versatility, security, and user experience at an affordable price for any enterprise.
