AD CS Integration Empowers Apple Admins Who Rely on Active Directory

One common way to authenticate a user’s identity is with username and password credentials. Another, especially in enterprise environments, is with Public Key Infrastructure (PKI) certificates (also known simply as digital certificates). 

Active Directory Certificate Services (AD CS) lets IT teams that already use Microsoft Active Directory build PKIs for their organizations and use them to issue digital certificates. Those teams can then deploy those certificates to devices, whose users can then access organization services. For users of Apple devices, the most common use cases for such certificates involve authenticating for Wi-Fi and for VPN.

Unfortunately, making AD CS work in Apple-dominant environments hasn't always been easy. That’s why Kandji is introducing its own AD CS integration. This integration allows Kandji to securely communicate with AD CS so admins can deploy AD CS certificates to the Apple devices they manage.

Here’s an overview of how that integration works and what it can do for you; for more details, read on!

AD CS: What You Need to Know

One advantage of using certificates is that your users don’t need to enter their credentials all the time. Another is that it’s easy to silently distribute certificates to devices enrolled with your organization’s mobile device management (MDM) solution. Similarly, certificates are automatically removed from devices that unenroll from MDM.  

There are several ways for an organization to build a PKI or distribute certificates manually. But AD CS makes it easier for large organizations to distribute them at scale. To understand why you need to understand the two types of certificate authorities (CAs) that manage and issue public-key certificates: Enterprise CAs (such as the one integrated into Active Directory) and standalone CAs.

A standalone CA can operate offline (because it doesn’t need domain access). It can also act as a root for intermediate CAs assigned to it. IT teams can use such intermediate CAs to handle certificates with enrolled devices. However, with standalone CAs, you can’t automate tasks or use templates, so IT has to manage and approve certificates manually.

Enterprise CAs, on the other hand, operate online and support task automation and templates. That means IT can automate enrollment and certificate requests. Microsoft also has its own CAs, which let you implement PKIs, which manage digital certificates and security through encryption.

AD CS for Apple Admins

Although many organizations have adopted cloud-based identity providers (IdPs), many established ones embraced Active Directory years ago and still rely on its on-premises infrastructure for identity and other services. They’ve crafted their workflows around AD, and why not? It’s a powerful solution that makes it easy for IT departments to automatically create and distribute certificates. 

That’s why we built our new AD CS connector: If your organization uses AD, AD CS, and Kandji, you can continue to use and support that infrastructure for as long as you need. 

The big problem this connector solves: Microsoft’s Group Policies (GPOs) are rules applied to certain users in Active Directory. GPOs essentially determine which groups of users and devices get which certificates. In a Microsoft Windows environment, this works great. But in an Apple environment, GPOs just don’t translate.

That’s why Mac admins have had to find alternative methods to push out their configuration policies. Many of those admins suggest that you avoid such binding completely and, instead, use an AD CS Connector that can connect AD CS with your cloud environment. 

Kandji’s AD CS Integration

Kandji’s new Active Directory Certificate Services (AD CS) integration allows Kandji to securely communicate with Microsoft AD CS so you can deploy AD CS certificates to your devices. This works even if your Apple devices aren’t on-premises.

The key to this is the AD CS Connector—a native Windows app that leverages the Microsoft .NET framework and runs directly on an on-premises Windows server. That app uses the WebSocket protocol to establish a persistent real-time secure connection with Kandji; there’s no need to open and maintain specific ports on your network firewall. Additionally, there's no need to configure or maintain any additional web server components, just a Windows server that can communicate with the on-prem server running your AD CS services.

When Kandji needs to issue a certificate to a device enrolled in your Kandji instance, it uses that WebSocket connection to send a certificate request to the AD CS Connector (1). The connector then sends a certificate-signing request to Microsoft AD CS (2). AD CS returns that request back to the AD CS Connector (3), which sends an encrypted credential and certificate payload back to Kandji (4). Finally, Kandji securely sends a configuration profile payload with the certificate to the client device (5).

Check out our support article for more details on how to set up this new integration in your environment.