Jamf et RADIUS : Authentification WiFi par certificat pour les flottes d'appareils Apple

Ce guide de référence technique fournit aux responsables IT, architectes réseau et CTO les étapes concrètes pour déployer l'authentification WiFi 802.1X par certificat pour les flottes d'appareils Apple via Jamf Pro et RADIUS. Il couvre le flux de provisionnement de certificats SCEP, la structure des profils de configuration WiFi, les exigences d'intégration RADIUS et des scénarios de mise en œuvre réels en entreprise et dans le secteur de la santé. Ce guide est essentiel pour toute organisation cherchant à éliminer les vulnérabilités WiFi liées aux mots de passe, à réduire la charge du support technique et à se conformer aux normes d'accès réseau PCI DSS et GDPR.

📖 9 min de lecture📝 2,102 mots🔧 2 exemples❓ 3 questions📚 9 termes clés

🎧 Écouter ce guide

Voir la transcription

Welcome to the Purple Technical Briefing. I'm your host, and today we're diving into a critical infrastructure topic for enterprise Apple environments: deploying certificate-based WiFi authentication using Jamf Pro and RADIUS.

If you're an IT manager, network architect, or venue operations director, you know the pain of password-based WiFi. Users change their Active Directory passwords, and suddenly their iPhones, iPads, and MacBooks drop off the network. Helpdesk tickets spike. Security is compromised because passwords can be shared, phished, or intercepted.

The enterprise-grade solution is 802.1X EAP-TLS. That's certificate-based authentication. No passwords. The device authenticates itself using a cryptographic certificate. And when you're managing a fleet of Apple devices, the industry standard way to deploy those certificates and the corresponding WiFi configurations is through Mobile Device Management — specifically Jamf Pro.

Let's break down the architecture. At the edge, you have your enterprise Access Points. Behind them, your RADIUS server — maybe FreeRADIUS, Cisco ISE, or Microsoft NPS. And managing the devices, you have Jamf Pro.

The magic happens through a protocol called SCEP — Simple Certificate Enrollment Protocol. SCEP allows Jamf to tell an Apple device: go and talk to this Certificate Authority and get yourself a unique certificate.

Here's the step-by-step flow. First, you configure a Configuration Profile in Jamf Pro. This profile contains two crucial payloads. The first is the SCEP payload. This tells the macOS or iOS device the URL of your SCEP server and provides a dynamic challenge password. The device generates a Certificate Signing Request — or CSR — and sends it to the SCEP server. The SCEP server validates the challenge, signs the certificate, and issues it back to the device.

Now the device has a unique, identity-bound certificate. But it needs to know what to do with it. That's where the second payload comes in: the WiFi payload. In Jamf, you configure the WiFi payload for WPA2 or WPA3 Enterprise. You select EAP-TLS as the accepted EAP type. And crucially, you link this WiFi payload to the SCEP payload you just created. You're telling the device: when you connect to the corporate SSID, use the certificate you got from this SCEP process to authenticate.

When the user walks into the office, the MacBook sees the SSID. It initiates an 802.1X connection. The Access Point passes the request to the RADIUS server. The RADIUS server and the MacBook exchange certificates to establish mutual trust. The RADIUS server validates the MacBook's certificate against the Certificate Authority. If it's valid, not revoked, and matches the required policies, the RADIUS server sends an Access-Accept message to the Access Point, and the device is on the network. Seamlessly. Zero user interaction.

Let's talk about implementation pitfalls. The number one issue we see is certificate trust chain failures. For EAP-TLS to work, the Apple device must trust the RADIUS server's certificate, and the RADIUS server must trust the device's certificate. In your Jamf WiFi profile, you must explicitly define the trusted server certificate names and include the Root CA certificate in the profile. If you miss this, iOS and macOS will silently fail the connection, or prompt the user to manually trust the certificate — which defeats the entire purpose of MDM deployment.

Another common pitfall is the initial SCEP enrollment challenge. If the device is trying to get its SCEP certificate over the very WiFi network it needs the certificate to access, you have a chicken-and-egg problem. You need an onboarding network, or the devices need to receive their profiles via Ethernet or cellular data before hitting the corporate WiFi.

Now, let's look at a real-world scenario. A major hospital network was deploying five thousand iPads for clinical staff. They were using PEAP with usernames and passwords. Every ninety days, Active Directory passwords expired. The morning after expiration, hundreds of nurses couldn't access patient records because their iPads dropped off the WiFi. By moving to Jamf-managed SCEP and EAP-TLS, they eliminated password rotations for network access entirely. The certificates were valid for a year, and Jamf automatically renewed them at thirty days out via SCEP. Helpdesk tickets for WiFi dropped by eighty-five percent.

Let me give you the rapid-fire Q and A. Question: Can I use PEAP with Jamf instead of EAP-TLS? Technically yes, but you lose the key benefit of passwordless authentication. EAP-TLS is the recommended standard. Question: Do I need an internal CA, or can I use a public CA? For RADIUS authentication, an internal CA is strongly recommended because you control the issuance and revocation of device certificates. Question: What happens when a device is unenrolled from Jamf? The certificate should be revoked at the CA level, and the RADIUS server should check the Certificate Revocation List to deny access.

So, what are the key takeaways? First: move away from PEAP and passwords. EAP-TLS is the gold standard for Apple fleets. Second: leverage Jamf Pro's dynamic SCEP payloads to issue unique, device-bound certificates without manual intervention. Third: ensure your certificate trust chains are explicitly defined in your configuration profiles to prevent silent failures. Fourth: plan your onboarding network carefully — devices need a path to the SCEP server before they can join the secure WiFi. And fifth: use device-based certificates for shared hardware, and user-based certificates for one-to-one deployments.

That's our technical deep-dive on Jamf and RADIUS for today. For more detailed configuration steps and architecture diagrams, refer to the full written guide on the Purple platform. Thanks for listening.

Résumé exécutif

La gestion de l'accès WiFi sécurisé pour une flotte d'appareils Apple en entreprise représente un défi opérationnel et de sécurité majeur lorsqu'on s'appuie sur l'authentification traditionnelle par mot de passe. Les utilisateurs modifient leurs identifiants Active Directory, et immédiatement leurs iPhones, iPads et MacBooks perdent la connexion au réseau — générant des tickets de support, perturbant les flux de travail et exposant l'organisation à des attaques basées sur les identifiants.

Pour les responsables IT, architectes réseau et CTO des hôtels, chaînes de vente au détail, stades et organisations du secteur public, la solution est l'authentification 802.1X par certificat utilisant EAP-TLS. En exploitant Jamf Pro pour distribuer des certificats cryptographiques uniques via SCEP (Simple Certificate Enrollment Protocol) et en l'intégrant à un serveur RADIUS, les organisations peuvent bénéficier d'un accès WiFi fluide et sans mot de passe pour chaque appareil Apple géré. Ce guide propose une approche pratique et neutre vis-à-vis des fournisseurs pour déployer l'authentification par certificat WiFi Jamf RADIUS, garantissant une sécurité robuste, la conformité aux normes telles que PCI DSS et GDPR, et une réduction mesurable des coûts de support.

Analyse technique approfondie

L'architecture 802.1X EAP-TLS

Le fondement de l'authentification WiFi par certificat est la norme IEEE 802.1X combinée au protocole EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). Pour une introduction détaillée à la norme 802.1X elle-même, consultez notre guide sur l' Authentification 802.1X : Sécuriser l'accès réseau sur les appareils modernes .

Contrairement au PEAP (Protected EAP), qui repose sur un nom d'utilisateur et un mot de passe, l'EAP-TLS exige que l'appareil client et le serveur d'authentification prouvent leur identité à l'aide de certificats numériques. Cette authentification mutuelle est ce qui fait de l'EAP-TLS la référence absolue pour les déploiements en entreprise. Le modèle à trois parties se compose des éléments suivants.

Composant	Rôle	Exemples
Supplicant	L'appareil Apple demandant l'accès au réseau	MacBook, iPhone, iPad
Authentificateur	L'équipement de bordure réseau qui applique le contrôle d'accès	Point d'accès WiFi, WLC
Serveur d'authentification	Valide les certificats et autorise l'accès	FreeRADIUS, Cisco ISE, Microsoft NPS

Le point d'accès agit comme un gardien, bloquant tout le trafic jusqu'à ce que le serveur RADIUS envoie un message Access-Accept. C'est le cœur du modèle de contrôle d'accès au réseau basé sur les ports (PNAC) IEEE 802.1X.

SCEP et Jamf Pro : Distribution de certificats à grande échelle

Le défi de l'EAP-TLS à grande échelle est la distribution des certificats. Installer manuellement un certificat unique sur 500 iPads n'est pas une opération viable. C'est là que l'intégration Jamf Pro et SCEP Jamf devient le levier critique.

Le SCEP (Simple Certificate Enrollment Protocol) est un protocole léger qui permet à un appareil de demander et de recevoir automatiquement un certificat signé d'une autorité de certification (CA). Jamf Pro agit comme l'orchestrateur, poussant un profil de configuration vers chaque appareil Apple. Ce profil contient une charge utile SCEP qui ordonne à l'appareil de contacter le serveur SCEP, fournit un mot de passe de défi dynamique et spécifie les attributs de certificat requis — tels que le Subject Alternative Name (SAN), qui est généralement mappé sur l'adresse MAC ou le numéro de série de l'appareil.

Le mécanisme de mot de passe de défi dynamique est particulièrement important. Dans un déploiement SCEP intégré à Jamf, Jamf génère un mot de passe de défi unique à usage unique pour chaque appareil. Cela garantit que seuls les appareils enrôlés dans Jamf Pro — et donc gérés par l'entreprise — peuvent obtenir avec succès un certificat de la CA. Il s'agit d'un contrôle de sécurité critique qui empêche les appareils non autorisés de s'enrôler.

Attributs RADIUS pour l'authentification des appareils Apple

Lorsque le serveur RADIUS reçoit une requête Access-Request du point d'accès, il évalue plusieurs attributs pour prendre sa décision d'autorisation. Pour les déploiements Apple 802.1X, les attributs RADIUS les plus pertinents sont les suivants.

Attribut RADIUS	Description	Pertinence Apple
`User-Name` (Attr 1)	L'identité présentée par le supplicant	Généralement le Subject CN ou SAN du certificat
`NAS-IP-Address` (Attr 4)	L'IP du point d'accès	Utilisé pour les politiques spécifiques aux points d'accès
`Called-Station-Id` (Attr 30)	Le BSSID et le SSID du point d'accès	Permet l'application de politiques basées sur le SSID
`EAP-Message` (Attr 79)	Le paquet EAP encapsulé	Contient les données du handshake TLS
`Tunnel-Type` (Attr 64)	Spécifie le type d'assignation VLAN	Utilisé pour l'assignation dynamique de VLAN post-auth
`Tunnel-Medium-Type` (Attr 65)	Spécifie le support du tunnel	Requis pour le marquage VLAN 802.1Q
`Tunnel-Private-Group-Id` (Attr 81)	L'ID du VLAN à assigner	Permet la segmentation réseau basée sur les rôles

L'attribut Tunnel-Private-Group-Id est particulièrement puissant dans les déploiements en entreprise. En renvoyant différents ID de VLAN basés sur les attributs du certificat (ex: département, type d'appareil), le serveur RADIUS peut segmenter dynamiquement le réseau sans nécessiter de SSID distincts.

Guide de mise en œuvre

Le déploiement de l'authentification WiFi Apple par certificat via Jamf Pro suit une séquence structurée. S'écarter de cet ordre est la cause principale des échecs de déploiement.

Étape 1 : Établir votre infrastructure d'autorité de certification

Avant de toucher à Jamf, votre infrastructure CA doit être en place. Pour les environnements Microsoft, il s'agit généralement d'Active Directory Certificate Services (AD CS) avec le rôle Network Device Enrollment Service (NDES), qui agit comme serveur SCEP. Pour les environnements non-Microsoft, les options incluent EJBCA, HashiCorp Vault PKI ou des CA basées sur le cloud telles qu'AWS Private CA.

Assurez-vous que votre hiérarchie CA est claire : une CA racine (Root CA) conservée hors ligne, et une ou plusieurs CA émettrices qui signent les certificats des appareils. Le serveur RADIUS aura besoin de son propre certificat signé par cette même hiérarchie CA.

Étape 2 : Configurer la charge utile SCEP dans Jamf Pro

Naviguez vers Ordinateurs (ou Appareils mobiles) > Profils de configuration > Nouveau. Ajoutez une charge utile Certificat et sélectionnez SCEP comme source de certificat. Les champs critiques sont les suivants.

URL : Le point de terminaison SCEP (ex: http://ndes.votredomaine.com/certsrv/mscep/mscep.dll).
Nom : Un nom descriptif qui apparaîtra dans le trousseau d'accès de l'appareil.
Objet (Subject) : Le nom distinctif (DN) du certificat. Utilisez des variables Jamf telles que CN=$COMPUTERNAME pour les ordinateurs ou CN=$JSSID pour les appareils mobiles.
Subject Alternative Name (SAN) : Définissez le type de SAN sur RFC 822 Name avec la valeur $MACADDRESS@votredomaine.com, ou DNS Name avec $COMPUTERNAME.votredomaine.com. C'est ce que le serveur RADIUS lira pour identifier l'appareil.
Type de défi : Sélectionnez Dynamique pour utiliser le proxy SCEP intégré de Jamf, qui génère des mots de passe de défi par appareil.
Taille de la clé : 2048 bits RSA minimum. 4096 bits est recommandé pour les nouveaux déploiements.
Utilisation de la clé : Activez à la fois Signature et Chiffrement.

Étape 3 : Configurer la charge utile WiFi

Dans le même profil de configuration, ajoutez une charge utile Wi-Fi. Les paramètres clés pour Apple 802.1X sont les suivants.

SSID : Le nom exact de votre SSID sécurisé d'entreprise.
Type de sécurité : WPA2 Enterprise ou WPA3 Enterprise (recommandé si le matériel le supporte).
Protocoles — Types EAP acceptés : Sélectionnez uniquement TLS. Désélectionnez PEAP, TTLS et tous les autres types pour imposer exclusivement l'EAP-TLS.
Authentification — Certificat d'identité : Sélectionnez la charge utile SCEP créée à l'étape 2. C'est le lien critique entre le certificat et la connexion WiFi.
Confiance — Noms de certificats de serveurs approuvés : Saisissez le Common Name (CN) exact du certificat de votre serveur RADIUS (ex: radius.votredomaine.com). C'est l'élément de configuration le plus souvent oublié.
Confiance — Certificats approuvés : Téléchargez le certificat de la CA racine et de toute CA intermédiaire ayant signé le certificat du serveur RADIUS.

Étape 4 : Configurer le serveur RADIUS

Sur votre serveur RADIUS, créez une politique réseau qui correspond aux attributs de certificat définis dans Jamf. Pour Microsoft NPS, cela signifie créer une Politique de demande de connexion qui correspond au SSID via l'attribut Called-Station-Id, et une Politique réseau qui valide le certificat par rapport à votre CA et assigne éventuellement un VLAN via les attributs Tunnel.

Pour FreeRADIUS, configurez le module eap pour utiliser tls et pointez vers votre certificat CA, le certificat du serveur et la clé privée. Le fichier users ou le backend SQL doit être configuré pour faire correspondre le SAN du certificat avec votre inventaire d'appareils.

Étape 5 : Définir le périmètre et déployer le profil

Dans Jamf Pro, définissez le périmètre du profil de configuration pour les groupes d'appareils appropriés — par exemple, tous les appareils du Smart Group "Flotte d'entreprise". Le profil sera poussé automatiquement via MDM. Les appareils en ligne le recevront en quelques minutes ; les appareils hors ligne le recevront lors de leur prochaine connexion.

Bonnes pratiques

Implémentez WPA3 Enterprise dès que possible. Le WPA3 Enterprise avec le mode 192 bits offre une force cryptographique accrue utilisant GCMP-256 et HMAC-SHA-384, offrant une protection nettement plus forte que le WPA2 Enterprise. Pour les environnements de l' Hôtellerie et les organisations de Santé manipulant des données sensibles, cette mise à niveau devient de plus en plus une exigence de conformité plutôt qu'une simple bonne pratique.

Exploitez les certificats basés sur l'appareil pour le matériel partagé. Pour les appareils partagés — tels que les iPads de point de vente, les tablettes de conciergerie d'hôtel ou les appareils cliniques — utilisez des certificats liés à l'appareil plutôt qu'à l'utilisateur. Cela garantit que l'appareil se connecte au réseau dès le démarrage, avant toute session utilisateur, permettant au MDM, aux mises à jour d'applications et aux notifications push de fonctionner correctement. C'est une considération critique pour les déploiements dans le Commerce de détail où les appareils peuvent être partagés entre plusieurs équipes.

Intégrez l'accès réseau à votre posture de sécurité globale. Alors que le personnel utilise le 802.1X pour un accès interne sécurisé, assurez-vous que vos réseaux publics sont gérés via une solution robuste de Guest WiFi pour maintenir une séparation claire du trafic. Combiner l'authentification du personnel par certificat avec le WiFi Analytics offre une visibilité complète sur le comportement des appareils authentifiés et l'activité du réseau invité.

Automatisez le renouvellement des certificats. Configurez la charge utile SCEP dans Jamf pour déclencher un renouvellement automatique lorsqu'un certificat est à 14 ou 30 jours de son expiration. Cela évite le scénario où un appareil perd silencieusement l'accès au réseau parce que son certificat a expiré pendant la nuit. Dans Jamf Pro, cela se contrôle via le paramètre Renewal Threshold dans la charge utile SCEP.

Maintenez une liste de révocation de certificats (CRL) ou un répondeur OCSP. Lorsqu'un appareil est déclassé, volé ou retiré de Jamf, son certificat doit être révoqué au niveau de la CA. Configurez votre serveur RADIUS pour vérifier le point de terminaison CRL ou OCSP à chaque tentative d'authentification. Sans cela, un appareil volé avec un certificat valide peut toujours s'authentifier sur le réseau.

Pour plus de contexte sur les décisions relatives aux infrastructures réseau modernes, le guide Les avantages clés du SD WAN pour les entreprises modernes fournit des informations utiles sur la manière dont l'authentification par certificat s'intègre aux architectures SD-WAN.

Dépannage et atténuation des risques

Le problème de provisionnement de l'œuf et de la poule. Les appareils ont besoin d'une connexion réseau pour atteindre le serveur SCEP et télécharger leur certificat, mais ils ont besoin du certificat pour rejoindre le WiFi sécurisé. C'est le bloqueur de déploiement le plus courant. Les stratégies d'atténuation recommandées sont : le provisionnement via Ethernet à l'aide d'adaptateurs USB-C ou Lightning vers Ethernet ; l'utilisation des données cellulaires sur les iPhones et iPads compatibles ; ou la création d'un SSID d'enrôlement temporaire et restreint avec des règles de pare-feu n'autorisant que le trafic SCEP et MDM.

Échecs EAP-TLS silencieux sur macOS. Si la chaîne de confiance est incomplète, macOS peut échouer silencieusement à se connecter sans afficher d'erreur explicite dans l'interface utilisateur. La seule indication se trouve dans le journal système. Utilisez log stream --predicate 'subsystem == "com.apple.network"' pour capturer les événements d'authentification en temps réel. Vérifiez toujours que le tableau Trusted Server Certificate Names dans le profil Jamf correspond exactement au CN du certificat du serveur RADIUS.

Timeout RADIUS lors d'événements à forte charge. Dans des environnements tels que les stades ou les centres de conférence, des demandes d'authentification simultanées provenant de centaines d'appareils peuvent submerger le serveur RADIUS. Atténuez cela en déployant RADIUS en paire haute disponibilité, en ajustant le paramètre max_requests dans FreeRADIUS et en vous assurant que le serveur RADIUS dispose de suffisamment de CPU et de mémoire pour la charge d'authentification attendue. Pour les déploiements dans de grands sites, consultez nos conseils sur la Définition des points d'accès sans fil : Votre guide ultime 2026 pour les considérations de planification de capacité.

Incohérence des attributs de certificat. Si le SAN dans le certificat de l'appareil ne correspond pas à ce que la politique réseau RADIUS attend, l'authentification échouera. C'est particulièrement courant lors de la migration d'une CA à une autre, ou lorsque les variables Jamf se résolvent différemment de ce qui était prévu. Testez toujours avec un seul appareil et inspectez les journaux du serveur RADIUS pour confirmer la chaîne d'identité exacte présentée avant le déploiement sur toute la flotte.

ROI et impact commercial

Le passage à l'authentification par certificat WiFi Jamf RADIUS apporte une valeur commerciale mesurable sur plusieurs dimensions.

Métrique	Résultat typique
Réduction des tickets de support	Réduction de 60 à 85 % des demandes liées au WiFi
Temps d'enrôlement par appareil	Réduit de 15-30 minutes à moins de 2 minutes (zero-touch)
Risque d'incident de sécurité	Quasi-élimination des attaques WiFi basées sur les identifiants
Posture de conformité	Répond aux exigences PCI DSS 1.3 et aux contrôles réseau de l'Article 32 du GDPR
Cycle de vie des certificats	Le renouvellement automatisé élimine la gestion manuelle des certificats

Le principal moteur de ROI est l'élimination des interruptions liées à la rotation des mots de passe. Dans une flotte de 500 appareils où 10 % des appareils perdent la connexion chaque trimestre à cause de changements de mots de passe, et où chaque incident nécessite 20 minutes de temps IT, les économies de coûts de support annuel peuvent à elles seules justifier l'investissement dès la première année.

Pour les opérateurs de Transport et les grands sites événementiels, l'argumentaire commercial est renforcé par la capacité à appliquer une assignation dynamique de VLAN — garantissant que les appareils opérationnels, les appareils du personnel et les systèmes de gestion sont automatiquement segmentés sans reconfiguration manuelle du réseau.

Termes clés et définitions

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)

The most secure 802.1X authentication method, requiring both the client device and the RADIUS server to authenticate each other using digital certificates. No password is exchanged or transmitted.

When IT teams need to eliminate password-based WiFi and enforce strict device compliance, EAP-TLS is the mandatory standard. It is the only EAP type that provides mutual authentication.

SCEP (Simple Certificate Enrollment Protocol)

A protocol that allows devices to securely and automatically request digital certificates from a Certificate Authority using a challenge-response mechanism.

Essential for scaling certificate deployments via Jamf Pro without requiring IT staff to manually install certificates on thousands of devices. Jamf's dynamic SCEP proxy generates per-device challenge passwords.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol providing centralised Authentication, Authorisation, and Accounting (AAA) management for devices connecting to a network service.

The central decision engine that tells the WiFi Access Point whether a Jamf-managed device is allowed on the network, and optionally which VLAN to assign.

Configuration Profile

An XML file (.mobileconfig) deployed by Jamf Pro that contains one or more payloads to manage settings on Apple devices, including certificates, WiFi, VPN, and restrictions.

This is the vehicle used to push the SCEP settings, WiFi SSID configuration, and certificate trust chain to the iPhone, iPad, or Mac.

CSR (Certificate Signing Request)

A block of encoded text generated by the Apple device containing the public key and identity information, sent to the Certificate Authority to apply for a signed digital certificate.

The first step in the SCEP process. The device generates the CSR locally, ensuring the private key never leaves the device — a fundamental principle of PKI security.

Subject Alternative Name (SAN)

An extension to an X.509 certificate that allows multiple identity values to be associated with the certificate, such as email addresses, DNS names, IP addresses, or MAC addresses.

Crucial for RADIUS authentication. The RADIUS server reads the SAN to identify the device or user. In Jamf deployments, the SAN is typically set to the device's MAC address or the user's UPN.

Root CA (Certificate Authority)

The top-most certificate in a PKI hierarchy, the private key of which is used to sign subordinate CA certificates. The Root CA certificate must be trusted by all parties in the authentication chain.

Must be deployed to Apple devices via Jamf so they trust the certificates presented by the RADIUS server during the EAP-TLS handshake. Without it, the handshake fails.

IEEE 802.1X

An IEEE standard for port-based Network Access Control (PNAC), providing an authentication mechanism to devices wishing to attach to a LAN or WLAN before network access is granted.

The overarching framework that blocks network traffic at the Access Point until the RADIUS server validates the Jamf-provisioned certificate. All enterprise WiFi security is built on this standard.

Dynamic VLAN Assignment

A RADIUS feature that assigns a connecting device to a specific VLAN based on policy attributes returned in the Access-Accept message, using RADIUS Tunnel attributes 64, 65, and 81.

Enables network segmentation without multiple SSIDs. A single corporate SSID can automatically place clinical iPads on VLAN 20, executive MacBooks on VLAN 30, and guest devices on VLAN 100.

Études de cas

A 500-bed hospital needs to deploy 1,200 shared iPads for clinical staff. They currently use PEAP with Active Directory credentials, resulting in hundreds of disconnected devices every 90 days when passwords expire. How should they redesign their authentication architecture?

The hospital should migrate to EAP-TLS using device-based certificates managed through Jamf Pro. The implementation involves four key steps. First, deploy AD CS with the NDES role to act as the SCEP server, issuing certificates from a dedicated 'Clinical Device' certificate template. Second, configure a Jamf Configuration Profile with a SCEP payload using $MACADDRESS as the SAN, and a WiFi payload targeting the clinical SSID with EAP-TLS only, explicitly trusting the RADIUS server certificate. Third, configure Microsoft NPS with a Network Policy that matches the 'Clinical Device' certificate template and assigns devices to the Clinical VLAN (Tunnel-Private-Group-Id = 20). Fourth, set the SCEP renewal threshold to 30 days to ensure automatic certificate renewal without IT intervention. Devices should be provisioned via Ethernet during the initial rollout to resolve the onboarding network challenge.

Notes de mise en œuvre : This approach eliminates the 90-day password rotation issue entirely. By using device-based certificates rather than user-based, the iPads remain connected to the network even when sitting on a charging cart, ensuring they receive critical MDM updates and push notifications before a clinician picks them up. The dynamic VLAN assignment via RADIUS ensures clinical devices are automatically placed on the correct network segment, meeting HIPAA network segmentation requirements without manual configuration.

A creative agency with 300 MacBooks is moving to a new office. They want zero-touch WiFi provisioning — new MacBooks should automatically connect to the secure corporate SSID when unboxed by end-users at their desks, with no IT intervention. How do they achieve this?

The agency must combine Apple Automated Device Enrollment (ADE) with Jamf Pro and a carefully sequenced Configuration Profile. During the macOS Setup Assistant, the MacBook connects to the internet via a temporary open onboarding SSID (restricted by firewall to permit only Apple activation, Jamf MDM, and SCEP traffic). It contacts Apple, recognises it belongs to the agency via ADE, and automatically enrolls in Jamf Pro. Jamf Pro immediately pushes a pre-staged Configuration Profile containing the SCEP payload and the corporate WiFi payload. The SCEP enrollment completes over the onboarding SSID, the certificate is installed in the Keychain, and the WiFi payload activates. The MacBook then automatically transitions to the secure 802.1X corporate SSID. From the user's perspective, they simply complete the Setup Assistant and the laptop is on the corporate network.

Notes de mise en œuvre : This scenario highlights the critical importance of the onboarding network in zero-touch deployments. The SCEP payload and WiFi payload must be in the same Configuration Profile and scoped to the Prestage Enrollment group so they are pushed immediately upon MDM enrollment — before the user reaches the desktop. If the profile is scoped to a Smart Group that requires the device to be fully enrolled first, there may be a delay during which the device has no network access, breaking the zero-touch experience.

Analyse de scénario

Q1. You have deployed a Jamf Configuration Profile with a SCEP payload and a WiFi payload to 50 MacBooks. The SCEP certificates are successfully installed in the Keychain, but the MacBooks are prompting users with a 'Verify Certificate' dialogue when attempting to connect to the corporate SSID. What configuration element is missing or incorrect?

💡 Astuce :Think about what information the Apple device needs to automatically trust the RADIUS server's identity without user interaction.

Afficher l'approche recommandée

The WiFi payload in the Jamf Configuration Profile is missing either the 'Trusted Server Certificate Names' entry (which must exactly match the CN in the RADIUS server's certificate), or the Root CA and Intermediate CA certificates that signed the RADIUS server's certificate are not included in the profile's Trust payload. Without explicit trust defined by the MDM, macOS and iOS require the user to manually verify and accept the RADIUS server's certificate during the EAP-TLS handshake. Both fields must be populated: the Trusted Certificates array (containing the CA chain) and the Trusted Server Certificate Names array (containing the RADIUS server's CN).

Q2. A retail chain wants their point-of-sale iPads to connect to the secure corporate WiFi immediately upon boot, before any staff member logs into the POS application. The current deployment uses user certificates tied to individual employee UPNs. Devices frequently fail to connect at the start of a shift. What is the root cause and what is the correct architectural change?

💡 Astuce :Consider when different types of certificates become available to the iOS network stack relative to the user authentication lifecycle.

Afficher l'approche recommandée

The root cause is that user certificates (tied to a UPN) are stored in the user's keychain and are only accessible after the user has authenticated to the device. At boot or at the iOS lock screen, the user keychain is locked, so the WiFi stack cannot access the certificate to perform EAP-TLS. The correct architectural change is to switch to device certificates, where the SAN is set to the device's MAC address or serial number. Device certificates are stored in the system keychain, which is accessible at boot time before any user logs in. The RADIUS Network Policy must be updated to match device certificates rather than user certificates, and the Jamf SCEP payload must be updated to use device-level variables such as $MACADDRESS or $SERIALNUMBER as the SAN.

Q3. Your organisation uses Microsoft NPS as the RADIUS server. You are configuring a new Jamf SCEP payload for 200 MacBooks. The NPS Network Policy is configured to require that the certificate's Subject Alternative Name matches a computer account in Active Directory. What SAN value should you configure in the Jamf SCEP payload, and what format does NPS expect?

💡 Astuce :NPS computer certificate authentication requires the SAN to match the computer's identity in Active Directory in a specific format.

Afficher l'approche recommandée

For NPS computer certificate authentication, the SAN must be set to the DNS Name type with the value $COMPUTERNAME.yourdomain.com (using the Jamf variable for the computer's hostname). NPS expects the SAN DNS Name to match the computer's fully qualified domain name (FQDN) as it appears in Active Directory. Alternatively, if using the User Principal Name SAN type, the format should be host/$ COMPUTERNAME@YOURDOMAIN.COM . The NPS Network Policy's condition should be set to match the 'Client Certificate SAN' attribute. Ensure the MacBooks are bound to Active Directory, or that the computer names in Jamf match the computer objects in AD, otherwise the NPS lookup will fail even if the certificate is valid.

Points clés à retenir

✓EAP-TLS is the gold standard for enterprise WiFi authentication — it eliminates passwords entirely and requires both the device and the RADIUS server to prove their identity using digital certificates.
✓Jamf Pro automates certificate distribution to Apple fleets at scale using the SCEP protocol, with dynamic per-device challenge passwords ensuring only managed devices can enrol.
✓A successful Jamf WiFi deployment requires two linked payloads in a single Configuration Profile: a SCEP payload to obtain the certificate, and a WiFi payload that references that certificate as the identity.
✓The most common deployment failure is an incomplete certificate trust chain — the Jamf WiFi profile must explicitly include the Root CA and specify the RADIUS server's CN in the Trusted Server Certificate Names field.
✓Device-based certificates (SAN = MAC address) are essential for shared hardware, ensuring network connectivity at boot before any user logs in.
✓Plan the onboarding network carefully — devices need a network path to the SCEP server before they can receive their certificate and join the secure 802.1X SSID.
✓Automated certificate renewal (configured at 30 days before expiration) and immediate revocation upon device decommissioning are non-negotiable operational requirements for a secure, resilient deployment.