Using Kandji on Enterprise Networks

Learn which hosts and ports are required to manage your Apple devices with Kandji

Overview

Some organizations may create Enrollment Only networks or put Proxies in place to limit access to the public internet. In these situations, it is important to ensure that your Apple devices can communicate with Apple's networks and Kandji to complete enrollment and management tasks.

• Learn which hosts and ports are required to manage your Apple devices with Kandji
  • Overview
  • Required Domains & Ports
    • US-hosted Region
    • EU-hosted Region
  • Active Directory Certificate Services Network Requirements
  • Determine Your Organization's Unique Device Domains
  • SSL/TLS Inspection
  • Apple required hosts and ports
  • Communication Flow
  • TLS Versions and Cipher Suites
    • Protocols
    • Cipher Suites

Required Domains & Ports

When creating firewall rules for these ports, outbound traffic will need to be allowed.

US-hosted Region

EU-hosted Region

The UUID preceding .web-api.kandji.io is unique to every Kandji tenant. To find your company's unique URL reference the following section.

Active Directory Certificate Services Network Requirements

For more information about the Active Directory Certificate Services integration, please see the AD CS overview support article.

Determine Your Organization's Unique Device Domains

Your unique device domains are used by enrolled devices in order to communicate with Kandji via the MDM protocol and the Kandji Agent for macOS.

You can view these unique domains by logging into your tenant and following these steps.

1. Click Settings on the lower left-hand corner. 
2. On the General tab, you will see the Device Domains panel, these two domains are used by devices for MDM and Agent communication.
   

To determine the specific Domain being used by an individual Mac computer, you can run the following command in Terminal. 

system_profiler SPConfigurationProfileDataType | awk -v FS='(https://|/mdm)' '/CheckInURL/ {print $2}'

SSL/TLS Inspection

The Kandji macOS Agent leverages a common best practice of certificate pinning to ensure that it will only communicate with trusted servers and prevent its traffic from being intercepted and inspected (MITM attack prevention).

This may pose a challenge if your network or proxy administrator is decrypting all SSL/TLS traffic by default. Please ask your network administrator to exempt the 2 device domains in your tenant from inspection.

Please note that even if you deploy your content filter's CA as a trusted root CA to your macOS devices; SSL/TLS inspection will still cause the Kandji Agent to not communicate with Kandji. 

Apple required hosts and ports

Apple has outlined their service's hosts and ports in this guide. 

Apple Support: Use Apple products on enterprise networks

Communication Flow

Below is a diagram demonstrating the standard flow of communication between Kandji, APNs, and managed Apple devices.

TLS Versions and Cipher Suites

Per Apple's Platform Security guide, built-in apps and services on macOS, iOS, tvOS, and iPadOS devices will automatically prefer cipher suites with perfect forward secrecy. This is also true in the case where a developer uses a high-level networking API such as CFNetwork. The Kandji agent leverages these high-level networking APIs.

We encourage you to read Apple's Platform Security Guide in order to better understand these features, especially the TLS network security section, which can be found here.

Apple Platform Security guide: TLS network security

As previously mentioned, the domain used for MDM and agent communication is unique to your tenant (UUID.web-api.kandji.io) you can inspect this domain using a tool such as Qualys SSL Server Test to understand which ciphers are currently supported by Kandji. You can see a brief overview below.

Protocols