Skip to main content
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, Windows, and Android devices can communicate with platform services and Iru to complete enrollment and management tasks.
When creating firewall rules for these ports, outbound traffic will need to be allowed.

Global Web App Access

Regardless of region, all Iru tenants access the web app through a single global domain: subdomain.iru.com.
The region-specific tables below also list subdomain.kandji.io and subdomain.eu.kandji.io as web app access domains. These are legacy hostnames that route to the same Iru service.
Your data remains isolated within its assigned region. When the app loads, a lookup is performed against a globally available service (the Identity Service) to determine your tenant’s region. All subsequent API calls are then routed to region-specific load balancers accordingly. For details on signing in and accessing your tenant, see Getting Started.

Required Domains & Ports

Domains shared across all regions

The following domains are required for all tenants regardless of region:
Domain Ports Protocol OS Description
browser-intake-datadoghq.com443TCP AllUsed for release management and platform monitoring
events.launchdarkly.com443TCP AllUsed for release management and platform monitoring
updater.iru.com443TCP AllUsed for Iru Access downloads and updates
*.c.lencr.org443TCP AllUsed for Let’s Encrypt certificate validation via Certificate Revocation Lists (CRLs).

Region-specific domains

US-hosted region domains

Domain Ports Protocol OS Description
UUID.web-api.kandji.ioUUID.devices.us-1.kandji.io443TCP AllUsed for MDM Check-In and Kandji Agent communication. Replace UUID with your tenant’s value. See Determine your unique device domains for how to find your UUID and domains.
kandji-prd.s3.amazonaws.com443TCP macOSUsed by macOS devices to download the Kandji Agent & Custom Apps uploaded to your Iru tenant
iru-prd-managed-library-items.s3.amazonaws.com443TCP macOSUsed by macOS devices to download Auto Apps
managed-library.kandji.io443TCP macOSUsed by macOS devices to download Auto Apps
subdomain.web-api.kandji.io443TCP AllUsed to download Mobile Device Management (MDM) Enrollment Profile
subdomain.kandji.iosubdomain.iru.com443TCP AllUsed to access the Iru web app
subdomain.gateway.kandji.comsubdomain.gateway.iru.com443TCP AllUsed by Iru web app to access Iru APIs.
*.iot.kandji.io443TCP AllUsed for device telemetry communications
windows-agent.kandji.io443TCP WindowsUsed to install and upgrade the Kandji Agent on Windows
subdomain.id.iru.comsubdomain.id.connect.iru.comsubdomain.id.devices.iru.comsubdomain.id.gateway.iru.com443TCP AllAccess point for the Iru Identity API service serving US tenants. Within the Iru web app, it is used universally across all tenants, independent of Iru Workforce Identity licensing

Determine Your Unique Device Domains

Your unique device domains are used by enrolled devices in order to communicate with Iru via the MDM protocol and the Kandji Agent. US region examples:
  • UUID.web-api.kandji.io
  • UUID.devices.us-1.kandji.io
EU region examples:
  • UUID.web-api.eu.kandji.io
  • UUID.devices.eu.kandji.io
The UUID is unique to your tenant. You can view your tenant’s domains by logging into your tenant and following these steps:
1

Open Organization

Click your name at the bottom of the left navigation, then select Organization.
2

View Device Domains

Under Endpoint, you will see the Device Domains panel. These two domains are used by devices for MDM and Agent communication.

Find device domain on a Mac

To determine the specific domain being used by an individual Mac computer, run the following command in Terminal:
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 Iru.

Platform-Specific Network Requirements

Apple Required Hosts & Ports

Apple devices require access to various Apple services for proper enrollment and management. For comprehensive Apple network requirements, refer to Apple’s official guide: Configure devices to work with APNs.
Destination Host Ports Purpose
Apple network (17.0.0.0/8)TCP/443Device activation and fallback if devices can’t reach APNs on port 5223
Apple network (17.0.0.0/8)TCP/5223Primary communication with Apple Push Notification service (APNs)
Apple network (17.0.0.0/8)TCP/443 or 2197Send notifications from device management service to APNs

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. The domains used for MDM and Kandji Agent communication are unique to your tenant. See Determine Your Unique Device Domains for how to find yours. You can inspect your tenant’s domains using a tool such as Qualys SSL Server Test to understand which ciphers are currently supported by Iru.

Supported TLS Protocols

Iru supports the following TLS protocol versions:
Protocol Supported Notes
TLS 1.2 YesServer negotiated using No-SNI
TLS 1.1 Yes
TLS 1.0 YesServer negotiated using No-SNI
TLS 1.3 No
SSL 3 No
SSL 2 No

Cipher Suites

  • 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_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_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