16-inch MacBook Pro
1 Facebook x.com Reddit
Apple services use many ports and connections that may not be immediately available when used in a corporate networks. Here's how to access them on corporate networks.
Security is a major concern when using devices to connect to Apple services, especially on corporate networks.
In the enterprise, security is a top concern due to the fact that companies and organizations are constantly under external pressure from hackers, ransomware, denial of service (DoS), botnets and other attacks.
Apple devices communicate with various services on remote servers. Apple Push Notifications (APN) are one such communication channel.
For example, if you see a Messages or FaceTime alert, you are seeing an Apple push notification.
Unlike some other network services, APN requires a service on the server, which then communicates with Apple's APN servers.
Apple and third-party apps know how to send and receive APNs through these channels for real-time communication.
UNIX, ports and protocols
In the UNIX and Linux operating systems, network layers and applications communicate through ports and sockets.
Think of a socket as a network channel that transfers data between computers. UNIX sockets can use a variety of network protocols, but most communications over the Internet use TCP/IP or UDP.
TCP/IP uses a packet acknowledgment model, whereas UDP sends data without receiving acknowledgments. The acknowledgment or “ack” in TCP/IP ensures reliable communication: if the network layer does not receive an acknowledgment when sending a packet, it waits a certain interval and then resends it.
In TCP, retransmissions continue until an acknowledgment is received or until the application-layer software tells the socket to stop. For example, this could happen after a timeout.
The development of TCP was part of the original ARPANET project of the US Department of Defense, which aimed to create a reliable military communications network capable of withstanding nuclear war. Thus, the TCP/IP protocol knows how to automatically redirect data in the event of a communication failure.
This design made it possible for military equipment to interact even without the participation of a human operator.
UDP, on the other hand, doesn't wait for acknowledgments – it streams data to specific ports, but it doesn't care whether certain destinations receive the packets or not. Hence, UDP is known as the “streaming protocol” because it essentially transmits a continuous stream of data to a specific port.
UDP listeners can simply listen on a specified port to receive a stream of data packets. Most online video and music streaming services use UDP for broadcasting.
For other types of communication, other types of protocols are used. For example, web traffic uses HTTP or HTTPS.
Web security is provided by TLS/SSL and other security features. The “S” in HTTPS means the “S” in SSL (Secure Sockets Layer). Several years ago, SSL was renamed to TLS or Transport Layer Security.
Therefore, the HTTPS protocol is actually HTTP using transport or socket security (encryption).
Each service or protocol uses a numbered port. Ports tell the operating system where to listen for incoming data.
For example, standard HTTP uses port 80. The currently little-used FTP protocol uses port 22.
TCP and UDP are low-level packet protocols, while HTTP/HTTPS, FTP, and others are higher level protocols.
Each “service” or data type has a predefined port number so that network traffic is not mixed upon arrival.
You can change the default ports to your own port numbers. Using custom port numbers is a security measure because hackers often look for certain types of traffic on known ports.
If you change the port number for standard traffic types, hackers will not see that data on the standard port and therefore will have a harder time intercepting it.
When you run an application that uses a network connection, it typically creates a network socket in code on a specific port, and then begins sending and receiving network packets on that port. At the UNIX network layer, incoming and outgoing traffic is directed to each network socket at the application layer as data is sent or received.
Most UNIX networking “stacks” are written in the C programming language for reasons of speed and also because the first full implementation of UNIX sockets—Berkeley Sockets Distribution, or BSD—was written in C. Most current Apple operating systems are written in C. Based on modified versions of BSD called XNU developed by Apple.
Technically, data packets are further broken down into frames at the data link layer, and then finally into bytes at the physical or “physical” layer before they are sent by the network device. But for the most part, you don't have to worry about data links or physical layers.
Frames are used because each physical network technology (Ethernet, fiber, etc.) can use different types of frames.
At the other end of the connection, the bytes and frames are reassembled into packets and sent to the network layer, and then finally to the application layer, where their data is read and used.
Proxy Servers
For many reasons, most organizations use proxy servers as part of their network topology. A proxy server is a server that, for security reasons, acts either as a data forwarder or as part of a firewall.
Proxies can be used to receive requests and then forward those requests to other servers—usually content servers. Proxy servers are also sometimes used in load balancing systems.
Proxy servers are usually (but not always) physically located separately from content servers.
Load balancers act as buffers so that content servers do not become overloaded or stop working due to high traffic load. A typical organization's network topology includes multiple proxy servers, content servers, and load balancers.
Some companies (such as Barracuda, Citrix, Cisco, and others) specialize in selling load balancers that can be configured in racks or banks and then receive and forward external traffic to content server destinations. Large companies often have entire rooms filled with load balancers to distribute network load between servers.
Content servers can be distributed across one or more CDNs or content delivery networks. CDNs are efficiently distributed load balancers that ensure that traffic is routed as efficiently as possible, both from a geographic and performance perspective.
Barracuda Load Balancer 340
Apple Services
Apple provides a number of network services and for this purpose uses many specialized servers and CDN to process network traffic. To do this, it often uses standard or special ports for its servers.
Today, with billions of Apple devices in use every day, the network load on Apple's servers and services is enormous, and to ensure smooth operation, the company must carefully consider how it handles network traffic.
Apple also uses multiple domains to manage devices. Enterprise deployments of Apple devices may be too large to handle manually, which is why Apple provides MDM, or mobile device management, a term that now covers all Apple devices.
Apple doesn't directly provide servers or MDM services—it only defines how they should be configured and deployed—implementation is left up to third parties.
Some Apple service domains support proxies and captive portals, and some do not.
A captive portal is a server or web page that provides authentication (login) to various services in an organization. If you've ever walked into a Starbucks and had to log in to its free Wi-Fi, you're using a captive portal.
For internal corporate use, Apple's MDM defines the concept of enrollment, which is essentially the registration of an Apple device into a specific organization's network. Registration is used to determine which devices are known and recognized on an organization's networks and which are not.
Registration helps security and network administrators detect hostile devices on internal and virtual private networks (VPNs).
Other services provided by Apple work in conjunction with MDM and enrollment and provide various features such as time and region settings, updates, and device shutdown.
For example, the domains time.apple.com and time-ios.apple.com are used to set the date/time and even language for registered devices in all time zones/locations of the globe using network time. Protocol (NTP).
MDM Services
If you enroll or deploy devices on corporate networks using an MDM solution, you will need access at least to APN, registration, external services and software updates.
For APN you will need access to *.push.apple.com on ports 80, 443, 2197 and 5223, and your third party server solutions or APN proxies must be able to communicate via TCP over these ports without restrictions.
If access to these ports is not available, registered users may not receive real-time notifications such as messages, FaceTime, Internet, or software updates. Keep in mind that many organizations choose to use automatic software updates because it greatly reduces the need to manually update software.
Without access to APN ports, automatic software updates may not work.
If you are using Apple School Manager or Apple Business Manager, which use Apple device profiles, you will also need access to iprofiles.apple.com.
To ensure that all of your MDM services are working correctly, talk to your MDM administrators or MDM service providers to ensure that all servers and software are configured correctly.
MDM global HTTP proxy payload
Some organizations only allow web traffic to enter or exit through predefined proxy servers. This topology ensures that all web traffic can be monitored, controlled or blocked using a proxy configuration.
For example, proxy servers can be configured to block all traffic on certain ports, or to allow traffic only on certain ports while denying all traffic on other ports. This reduces the attack surface and minimizes the ability of hackers to penetrate the network.
Proxies can also be used to forward or restrict traffic sent to other servers—sometimes for security, observability, or content delivery reasons.
With APNs, third-party servers essentially act as proxies for Apple's push notification service.
In the APN model, applications first send or listen to their own APN servers and then forward and receive notifications from Apple's APN service.
For organizational HTTP traffic, if you are using an MDM solution, you need to know the Global HTTP Proxy MDM payload settings for MDM-managed devices.
The MDM Global HTTP Proxy payload tells the Apple device how and where to send and receive HTTP data on the proxy server.
For devices with manual authentication (i.e., username and password), you need to ensure that the proxy servers can receive the MDM Global HTTP Proxy payload. For devices with automatic login, you need to provide a PAC file for each server or port you need access to.
Each MDM HTTP proxy payload contains information about the name and identifier, supported operating systems, registration types, and duplication resolution.
MDM HTTP Proxy payloads support hundreds of Apple domains, and your devices must ensure they can provide the correct payload for the required services.
For complete information about HTTP MDM payloads, see View MDM Payloads for Apple Devices in the Apple Platform Deployment Guide on the Apple website.
iCloud from Apple.
CloudKit, App Store, and TestFlight
If you are a developer or administrator of a software deployment in an organization, you also need to be aware of any software that uses Apple's iCloud, CloudKit, or TestFlight apps.
CloudKit is Apple's API for interacting with iCloud database services. If your application uses CloudKit to access remote databases hosted on Apple servers, you will need to ensure that these network services and ports are configured correctly.
Most (but not all) of Apple's CloudKit APIs use port 443, the standard https port.
Without access to port 443, the software cannot send or receive HTTPS web data unless a special port is defined.
There are actually over a dozen CloudKit domains hosted by Apple that you need to know about.
App verification services, receipts, notarization, and Apple security also use port 443, so to run most App Store apps, all your enterprise servers will also need port 443.
When downloading from The App Store uses ASN.1 (Abstract Syntax Notation One) security, and software from the App Store that is not verified using ASN.1 will not work on Apple devices. ASN.1 itself is a broad topic, so we won't go into detail here.
Suffice it to say that when you download or deploy software from the App Store to an Apple device, a sort of encryption handshake occurs that uses ASN.1 to exchange and verify the receipt associated with each application.
Without this receipt check, App Store apps will not work on iOS devices.
For Mac devices, notarization works in a similar way: Apps notarized by Apple also require verification to run.
All of these security checks are performed over the Internet, so your corporate network must be configured to allow them to work.
Touch ID and Face ID also use TCP on port 443 at *.appattest.apple.com for verification.
Apple's TestFlight beta distribution service for pre-release apps also uses port 443.
Other services and firewalls
There are dozens of other Apple services that we haven't mentioned here. These include, but are not limited to:
- Apple Diagnostics
- Apple ID
- Apple Pay
- Encrypted DNS
- Certificate verification
- Siri and search
- Linked Domains
li>
Some corporate networks support firewalls that can allow or deny network traffic based on domain name alone. This configuration is easier for administrators to manage, but it provides less granular control over which servers the client can communicate with.
If your organization's firewalls allow domain-level access and filtering, you can allow access to all remote Apple services. This is achieved by allowing all Apple subdomains to pass through the firewall using the wildcard domain *.apple.com.
This is because all Apple remote services use servers in domains ending in “apple.com”.
If your firewalls do not allow domain-level filtering and only support IP-level configuration, you may want to allow all outbound connections to Apple servers at 17.0.0.0/8, since all of 17.0.0.0/8 is blocked. assigned to Apple.
For a complete list of domains, services, ports, protocols, and supported Apple devices, see the support page. Using Apple products on corporate networks.
This page lists most public services, the domains, the ports and protocols they use, and the devices and operating systems that are supported by each.
Not all Apple devices are supported by all services.
Additional Documentation
There are several other Apple documents on deployment and networking that you should check out. These include:
- If your Apple devices are not receiving Apple push notifications
- Choose an MDM solution
- Apple platform deployment
If you are a developer, you should also read the “Registering an app with an APN” and “Sending notification requests to an APN” sections in the User Notifications section of Apple's developer documentation.
This document also contains information on how to configure APN servers.
To ensure you deploy Mac apps securely, read “Notarize macOS Software Before Distributing It” in Apple's developer security documentation.
Enterprise networking and device management are complex topics. We've covered just some of what you need to know to use Apple devices on corporate networks.
We also haven't touched on profiles here – files that Apple devices use to verify and install software and provide network security.
In future articles, we will discuss deployment and MDM in more detail, as well as firewalls, protocols, and network information in more detail.
