Learn which hosts and ports are required to manage your Apple devices with Kandji
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.
- Required Domains & Ports
- Active Directory Certificate Services Network Requirements
- Determine Your Organization's Unique Device Domains
- SSL/TLS Inspection
- Apple Required Hosts & Ports
- Communication Flow
- TLS Versions and Cipher Suites
Required Domains & Ports
When creating firewall rules for these ports, outbound traffic will need to be allowed.
US-hosted Region
Domain | Ports | Protocol | OS | Description |
---|---|---|---|---|
kandji-prd.s3.amazonaws.com | 443 | TCP | macOS | Used by macOS devices to download the Kandji Agent & Custom Apps uploaded to your Kandji tenant |
kandji-prd-managed-library-items.s3.amazonaws.com | 443 | TCP | macOS | Used by macOS devices to download Auto Apps |
managed-library.kandji.io | 443 | TCP | macOS | Used by macOS devices to download Auto Apps |
UUID.web-api.kandji.io | 443 | TCP | All | Used to communicate with Kandji via the MDM protocol, and by the Kandji Agent |
UUID.devices.us-1.kandji.io | 443 | TCP | All | Will replace UUID.web-api.kandji.io domain in a future product update for new device enrollments as the domain used MDM Check-In URL and Kandji Agent communication |
subdomain.web-api.kandji.io | 443 | TCP | All | Used to download MDM Enrollment Profile |
subdomain.kandji.io | 443 | TCP | All | Used to access the Kandji web app |
*.iot.kandji.io | 443 | TCP | All | Used for device telemetry communications |
browser-intake-datadoghq.com | 443 | TCP | All | Used for release management and platform monitoring |
events.launchdarkly.com | 443 | TCP | All | Used for release management and platform monitoring |
EU-hosted Region
Domain | Ports | Protocol | OS | Description |
---|---|---|---|---|
kandji-prd-eu.s3.amazonaws.com | 443 | TCP | macOS | Used by macOS devices to download the Kandji Agent & Custom Apps uploaded to your Kandji tenant |
kandji-prd-eu-managed-library-items.s3.amazonaws.com | 443 | TCP | macOS | Used by macOS devices to download Auto Apps |
managed-library.eu.kandji.io | 443 | TCP | macOS | Used by macOS devices to download Auto Apps |
UUID.web-api.eu.kandji.io | 443 | TCP | All | Used to communicate with Kandji via the MDM protocol and by the Kandji Agent |
UUID.devices.eu.kandji.io | 443 | TCP | All | Will replace UUID.web-api.kandji.io domain in a future product update for new device enrollments as the domain used MDM Check-In URL and Kandji Agent communication |
subdomain.web-api.eu.kandji.io | 443 | TCP | All | Used to download MDM Enrollment Profile |
subdomain.eu.kandji.io | 443 | TCP | All | Used to access the Kandji web app |
*.iot.eu.kandji.io | 443 | TCP | All | Used for device telemetry communications |
browser-intake-datadoghq.com | 443 | TCP | All | Used for release management and platform monitoring |
events.launchdarkly.com | 443 | TCP | All | Used for release management and platform monitoring |
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.
- Click Settings on the left-hand navigation bar.
- 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 & 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
TLS 1.3 | No |
TLS 1.2 | Yes* |
TLS 1.1 | Yes |
TLS 1.0 | Yes* |
SSL 3 | No |
SSL 2 | No |
(*) Server negotiated using No-SNI |
Cipher Suites
TLS 1.2 in server preferred order |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLS_RSA_WITH_AES_128_GCM_SHA256 |
TLS_RSA_WITH_AES_128_CBC_SHA256 |
TLS_RSA_WITH_AES_128_CBC_SHA |
TLS_RSA_WITH_AES_256_GCM_SHA384 |
TLS_RSA_WITH_AES_256_CBC_SHA256 |
TLS_RSA_WITH_AES_256_CBC_SHA |
TLS 1.1 in server preferred |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLS_RSA_WITH_AES_128_CBC_SHA |
TLS_RSA_WITH_AES_256_CBC_SHA |
TLS 1.0 in server preferred |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
TLS_RSA_WITH_AES_128_CBC_SHA |
TLS_RSA_WITH_AES_256_CBC_SHA |