Jamf und RADIUS: Zertifikatsbasierte WiFi-Authentifizierung für Apple-Geräteflotten

This technical reference guide provides IT managers, network architects, and CTOs with actionable steps to deploy certificate-based 802.1X WiFi authentication for Apple device fleets using Jamf Pro and RADIUS. It covers the full SCEP certificate provisioning workflow, WiFi configuration profile structure, RADIUS integration requirements, and real-world implementation scenarios from healthcare and enterprise environments. The guide is essential for any organisation seeking to eliminate password-based WiFi vulnerabilities, reduce helpdesk overhead, and achieve compliance with PCI DSS and GDPR network access standards.

📖 9 Min. Lesezeit📝 2,102 Wörter🔧 2 Beispiele❓ 3 Fragen📚 9 Schlüsselbegriffe

🎧 Diesen Leitfaden anhören

Transkript anzeigen

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.

Executive Summary

Die Verwaltung eines sicheren WiFi-Zugangs für eine Flotte von Apple-Geräten in einer Unternehmensumgebung stellt eine erhebliche betriebliche und sicherheitstechnische Herausforderung dar, wenn man sich auf herkömmliche passwortbasierte Authentifizierung verlässt. Benutzer ändern ihre Active Directory-Anmeldeinformationen, und sofort verlieren ihre iPhones, iPads und MacBooks die Netzwerkverbindung – was Helpdesk-Tickets generiert, Arbeitsabläufe stört und das Unternehmen für anmeldedatenbasierte Angriffe anfällig macht.

Für IT-Manager, Netzwerkarchitekten und CTOs in Hotels, Einzelhandelsketten, Stadien und Organisationen des öffentlichen Sektors lautet die Lösung zertifikatsbasierte 802.1X-Authentifizierung mittels EAP-TLS. Durch die Nutzung von Jamf Pro zur Verteilung eindeutiger kryptografischer Zertifikate über SCEP (Simple Certificate Enrollment Protocol) und die Integration mit einem RADIUS-Server können Unternehmen einen nahtlosen, passwortlosen WiFi-Zugang für jedes verwaltete Apple-Gerät erreichen. Dieser Leitfaden bietet einen praktischen, herstellerneutralen Ansatz für die Bereitstellung der Jamf RADIUS WiFi-Zertifikatsauthentifizierung, der robuste Sicherheit, die Einhaltung von Standards wie PCI DSS und GDPR sowie eine messbare Reduzierung des Support-Aufwands gewährleistet.

Technischer Deep-Dive

Die 802.1X EAP-TLS-Architektur

Die Grundlage der zertifikatsbasierten WiFi-Authentifizierung ist der IEEE 802.1X-Standard in Kombination mit dem EAP-TLS-Protokoll (Extensible Authentication Protocol-Transport Layer Security). Eine detaillierte Einführung in den 802.1X-Standard selbst finden Sie in unserem Leitfaden zur 802.1X-Authentifizierung: Sicherung des Netzwerkzugriffs auf modernen Geräten .

Im Gegensatz zu PEAP (Protected EAP), das auf Benutzername und Passwort basiert, erfordert EAP-TLS, dass sowohl das Client-Gerät als auch der Authentifizierungsserver ihre Identität mithilfe digitaler Zertifikate nachweisen. Diese gegenseitige Authentifizierung macht EAP-TLS zum Goldstandard für Unternehmensbereitstellungen. Das Drei-Parteien-Modell besteht aus den folgenden Komponenten.

Komponente	Rolle	Beispiele
Supplicant	Das Apple-Gerät, das Netzwerkzugriff anfordert	MacBook, iPhone, iPad
Authenticator	Das Netzwerk-Edge-Gerät, das die Zugriffskontrolle durchsetzt	WiFi Access Point, WLC
Authentifizierungsserver	Validiert Zertifikate und autorisiert den Zugriff	FreeRADIUS, Cisco ISE, Microsoft NPS

Der Access Point fungiert als Gatekeeper und blockiert den gesamten Datenverkehr, bis der RADIUS-Server eine Access-Accept-Nachricht sendet. Dies ist der Kern des portbasierten Network Access Control (PNAC)-Modells nach IEEE 802.1X.

SCEP und Jamf Pro: Skalierbare Zertifikatsverteilung

Die Herausforderung bei EAP-TLS in großem Maßstab ist die Zertifikatsverteilung. Die manuelle Installation eines eindeutigen Zertifikats auf 500 iPads ist kein praktikabler Vorgang. Hier wird die Integration von Jamf Pro und SCEP Jamf zum entscheidenden Faktor.

SCEP (Simple Certificate Enrollment Protocol) ist ein schlankes Protokoll, das es einem Gerät ermöglicht, automatisch ein signiertes Zertifikat von einer Zertifizierungsstelle (Certificate Authority, CA) anzufordern und zu empfangen. Jamf Pro fungiert als Orchestrator und pusht ein Konfigurationsprofil auf jedes Apple-Gerät. Dieses Profil enthält einen SCEP-Payload, der das Gerät anweist, den SCEP-Server zu kontaktieren, ein dynamisches Challenge-Passwort bereitstellt und die erforderlichen Zertifikatsattribute spezifiziert – wie den Subject Alternative Name (SAN), der typischerweise der MAC-Adresse oder Seriennummer des Geräts zugeordnet wird.

Der Mechanismus des dynamischen Challenge-Passworts ist besonders wichtig. In einer Jamf-integrierten SCEP-Bereitstellung generiert Jamf für jedes Gerät ein eindeutiges, einmaliges Challenge-Passwort. Dies stellt sicher, dass nur in Jamf Pro registrierte – und somit unternehmensseitig verwaltete – Geräte erfolgreich ein Zertifikat von der CA erhalten können. Dies ist eine kritische Sicherheitskontrolle, die verhindert, dass sich nicht autorisierte Geräte registrieren.

RADIUS-Attribute für die Apple-Geräteauthentifizierung

Wenn der RADIUS-Server einen Access-Request vom Access Point erhält, wertet er mehrere Attribute aus, um seine Autorisierungsentscheidung zu treffen. Für Apple 802.1X-Bereitstellungen sind die folgenden RADIUS-Attribute am relevantesten.

RADIUS-Attribut	Beschreibung	Apple-Relevanz
`User-Name` (Attr 1)	Die vom Supplicant präsentierte Identität	Typischerweise der Subject CN oder SAN des Zertifikats
`NAS-IP-Address` (Attr 4)	Die IP des Access Points	Wird für AP-spezifische Richtlinien verwendet
`Called-Station-Id` (Attr 30)	Die BSSID und SSID des APs	Ermöglicht SSID-basierte Richtliniendurchsetzung
`EAP-Message` (Attr 79)	Das gekapselte EAP-Paket	Enthält die TLS-Handshake-Daten
`Tunnel-Type` (Attr 64)	Spezifiziert den VLAN-Zuweisungstyp	Wird für die dynamische VLAN-Zuweisung nach der Authentifizierung verwendet
`Tunnel-Medium-Type` (Attr 65)	Spezifiziert das Medium für den Tunnel	Erforderlich für 802.1Q VLAN-Tagging
`Tunnel-Private-Group-Id` (Attr 81)	Die zuzuweisende VLAN-ID	Ermöglicht rollenbasierte Netzwerksegmentierung

Das Attribut Tunnel-Private-Group-Id ist in Unternehmensbereitstellungen besonders leistungsstark. Durch die Rückgabe unterschiedlicher VLAN-IDs basierend auf den Zertifikatsattributen (z. B. Abteilung, Gerätetyp) kann der RADIUS-Server das Netzwerk dynamisch segmentieren, ohne dass separate SSIDs erforderlich sind.

Implementierungsleitfaden

Die Bereitstellung der WiFi-Zertifikatsauthentifizierung für Apple über Jamf Pro folgt einer strukturierten Abfolge. Ein Abweichen von dieser Reihenfolge ist die Hauptursache für fehlgeschlagene Bereitstellungen.

Schritt 1: Aufbau Ihrer Certificate Authority-Infrastruktur

Bevor Sie Jamf konfigurieren, muss Ihre CA-Infrastruktur eingerichtet sein. In Microsoft-Umgebungen sind dies typischerweise die Active Directory Certificate Services (AD CS) mit der Rolle Network Device Enrollment Service (NDES), die als SCEP-Server fungiert. Für Nicht-Microsoft-Umgebungen umfassen die Optionen EJBCA, HashiCorp Vault PKI oder cloudbasierte CAs wie AWS Private CA.

Stellen Sie sicher, dass Ihre CA-Hierarchie klar ist: eine Root-CA, die offline gehalten wird, und eine oder mehrere Issuing-CAs, die Gerätezertifikate signieren. Der RADIUS-Server benötigt ein eigenes Zertifikat, das von derselben CA-Hierarchie signiert wurde.

Schritt 2: Konfiguration des SCEP-Payloads in Jamf Pro

Navigieren Sie zu Computer (oder Mobilgeräte) > Konfigurationsprofile > Neu. Fügen Sie einen Zertifikat-Payload hinzu und wählen Sie SCEP als Zertifikatsquelle. Die kritischen Felder sind wie folgt.

URL: Der SCEP-Endpunkt (z. B. http://ndes.yourdomain.com/certsrv/mscep/mscep.dll).
Name: Ein aussagekräftiger Name, der im Schlüsselbund des Geräts angezeigt wird.
Subject: Der Distinguished Name des Zertifikats. Verwenden Sie Jamf-Variablen wie CN=$COMPUTERNAME für Computer oder CN=$JSSID für Mobilgeräte.
Subject Alternative Name (SAN): Setzen Sie den SAN-Typ auf RFC 822 Name mit dem Wert $MACADDRESS@yourdomain.com oder DNS Name mit $COMPUTERNAME.yourdomain.com. Dies liest der RADIUS-Server, um das Gerät zu identifizieren.
Challenge-Typ: Wählen Sie Dynamisch, um den integrierten SCEP-Proxy von Jamf zu verwenden, der gerätespezifische Challenge-Passwörter generiert.
Schlüsselgröße: Mindestens 2048-Bit RSA. 4096-Bit wird für neue Bereitstellungen empfohlen.
Schlüsselverwendung: Aktivieren Sie sowohl Signatur als auch Verschlüsselung.

Schritt 3: Konfiguration des WiFi-Payloads

Fügen Sie im selben Konfigurationsprofil einen Wi-Fi-Payload hinzu. Die wichtigsten Einstellungen für Apple 802.1X sind wie folgt.

SSID: Der genaue Name Ihrer sicheren Unternehmens-SSID.
Sicherheitstyp: WPA2 Enterprise oder WPA3 Enterprise (empfohlen, sofern die Hardware dies unterstützt).
Protokolle — Akzeptierte EAP-Typen: Wählen Sie nur TLS. Deaktivieren Sie PEAP, TTLS und alle anderen Typen, um ausschließlich EAP-TLS zu erzwingen.
Authentifizierung — Identitätszertifikat: Wählen Sie den SCEP-Payload aus, den Sie in Schritt 2 erstellt haben. Dies ist die entscheidende Verbindung zwischen dem Zertifikat und der WiFi-Verbindung.
Vertrauen — Namen der vertrauenswürdigen Serverzertifikate: Geben Sie den genauen Common Name (CN) des Zertifikats Ihres RADIUS-Servers ein (z. B. radius.yourdomain.com). Dies ist der am häufigsten übersehene Konfigurationspunkt.
Vertrauen — Vertrauenswürdige Zertifikate: Laden Sie die Root-CA und alle Intermediate-CA-Zertifikate hoch, die das Zertifikat des RADIUS-Servers signiert haben.

Schritt 4: Konfiguration des RADIUS-Servers

Erstellen Sie auf Ihrem RADIUS-Server eine Netzwerkrichtlinie, die mit den in Jamf definierten Zertifikatsattributen übereinstimmt. Für Microsoft NPS bedeutet dies die Erstellung einer Verbindungsanforderungsrichtlinie, die die SSID über das Attribut Called-Station-Id abgleicht, und einer Netzwerkrichtlinie, die das Zertifikat gegen Ihre CA validiert und optional ein VLAN über die Tunnel-Attribute zuweist.

Konfigurieren Sie für FreeRADIUS das eap-Modul so, dass es tls verwendet, und verweisen Sie auf Ihr CA-Zertifikat, Serverzertifikat und den privaten Schlüssel. Die users-Datei oder das SQL-Backend sollte so konfiguriert sein, dass der SAN des Zertifikats mit Ihrem Gerätebestand abgeglichen wird.

Schritt 5: Zuweisung und Bereitstellung des Profils

Weisen Sie das Konfigurationsprofil in Jamf Pro den entsprechenden Gerätegruppen zu – zum Beispiel allen Geräten in der Smart Group "Corporate Fleet". Das Profil wird automatisch über MDM gepusht. Geräte, die online sind, erhalten es innerhalb von Minuten; Geräte, die offline sind, erhalten es beim nächsten Check-in.

Best Practices

Implementieren Sie WPA3 Enterprise, wo immer möglich. WPA3 Enterprise mit 192-Bit-Modus bietet eine verbesserte kryptografische Stärke durch GCMP-256 und HMAC-SHA-384 und bietet einen deutlich stärkeren Schutz als WPA2 Enterprise. Für Gastgewerbe -Umgebungen und Gesundheitswesen -Organisationen, die sensible Daten verarbeiten, wird dieses Upgrade zunehmend zu einer Compliance-Anforderung und nicht nur zu einer Best Practice.

Nutzen Sie gerätebasierte Zertifikate für gemeinsam genutzte Hardware. Verwenden Sie für gemeinsam genutzte Geräte – wie Point-of-Sale-iPads im Einzelhandel, Hotel-Concierge-Tablets oder klinische Geräte – gerätegebundene anstelle von benutzergebundenen Zertifikaten. Dies stellt sicher, dass sich das Gerät beim Booten mit dem Netzwerk verbindet, bevor sich ein Benutzer anmeldet, sodass MDM-Check-ins, App-Updates und Push-Benachrichtigungen ordnungsgemäß funktionieren. Dies ist ein kritischer Aspekt für Einzelhandel -Bereitstellungen, bei denen Geräte schichtübergreifend genutzt werden.

Integrieren Sie den Netzwerkzugriff in Ihre umfassendere Sicherheitsstrategie. Während Mitarbeiter 802.1X für den sicheren internen Zugriff nutzen, sollten Sie sicherstellen, dass Ihre öffentlich zugänglichen Netzwerke über eine robuste Guest WiFi -Lösung verwaltet werden, um eine klare Trennung des Datenverkehrs aufrechtzuerhalten. Die Kombination von zertifikatsbasierter Mitarbeiterauthentifizierung mit WiFi Analytics bietet vollständige Transparenz sowohl über das Verhalten authentifizierter Geräte als auch über die Gastnetzwerkaktivitäten.

Automatisieren Sie die Zertifikatserneuerung. Konfigurieren Sie den SCEP-Payload in Jamf so, dass eine automatische Erneuerung ausgelöst wird, wenn ein Zertifikat innerhalb von 14 bis 30 Tagen abläuft. Dies verhindert das Szenario, in dem ein Gerät stillschweigend den Netzwerkzugriff verliert, weil sein Zertifikat über Nacht abgelaufen ist. In Jamf Pro wird dies über die Einstellung Erneuerungsschwellenwert (Renewal Threshold) im SCEP-Payload gesteuert.

Pflegen Sie eine Certificate Revocation List (CRL) oder einen OCSP-Responder. Wenn ein Gerät außer Betrieb genommen, gestohlen oder aus Jamf abgemeldet wird, muss sein Zertifikat auf CA-Ebene widerrufen werden. Konfigurieren Sie Ihren RADIUS-Server so, dass er bei jedem Authentifizierungsversuch den CRL- oder OCSP-Endpunkt überprüft. Ohne dies kann sich ein gestohlenes Gerät mit einem gültigen Zertifikat weiterhin am Netzwerk authentifizieren.

Für weiteren Kontext zu modernen Netzwerkinfrastrukturentscheidungen bietet der Leitfaden Die zentralen SD-WAN-Vorteile für moderne Unternehmen nützliche Informationen darüber, wie sich die zertifikatsbasierte Authentifizierung in SD-WAN-Overlay-Architekturen integriert.

Fehlerbehebung & Risikominderung

Das Henne-Ei-Bereitstellungsproblem. Geräte benötigen eine Netzwerkverbindung, um den SCEP-Server zu erreichen und ihr Zertifikat herunterzuladen, aber sie benötigen das Zertifikat, um dem sicheren WiFi beizutreten. Dies ist der häufigste Blocker bei der Bereitstellung. Die empfohlenen Minderungsstrategien sind: Bereitstellung über Ethernet mit USB-C- oder Lightning-zu-Ethernet-Adaptern; Nutzung von Mobilfunkdaten auf iPhones und mobilfunkfähigen iPads; oder Erstellung einer temporären, eingeschränkten Onboarding-SSID mit Firewall-Regeln, die nur SCEP- und MDM-Verkehr zulassen.

Stille EAP-TLS-Fehler unter macOS. Wenn die Vertrauenskette unvollständig ist, schlägt die Verbindung unter macOS möglicherweise stillschweigend fehl, ohne dass ein aussagekräftiger Fehler in der Benutzeroberfläche angezeigt wird. Der einzige Hinweis findet sich im Systemprotokoll. Verwenden Sie log stream --predicate 'subsystem == "com.apple.network"', um Echtzeit-Authentifizierungsereignisse zu erfassen. Überprüfen Sie immer, ob das Array Namen der vertrauenswürdigen Serverzertifikate im Jamf-Profil exakt mit dem CN im Zertifikat des RADIUS-Servers übereinstimmt.

RADIUS-Timeout bei Hochlastereignissen. In Umgebungen wie Stadien oder Konferenzzentren können gleichzeitige Authentifizierungsanfragen von Hunderten von Geräten den RADIUS-Server überlasten. Mildern Sie dies ab, indem Sie RADIUS in einem Hochverfügbarkeitspaar bereitstellen, den Parameter max_requests in FreeRADIUS anpassen und sicherstellen, dass der RADIUS-Server über ausreichend CPU und Arbeitsspeicher für die erwartete gleichzeitige Authentifizierungslast. Für Bereitstellungen an großen Veranstaltungsorten lesen Sie unseren Leitfaden Wireless Access Points Definition: Ihr ultimativer Leitfaden 2026 für Überlegungen zur Kapazitätsplanung.

Nichtübereinstimmung von Zertifikatsattributen. Wenn der SAN im Gerätezertifikat nicht mit den Erwartungen der RADIUS-Netzwerkrichtlinie übereinstimmt, schlägt die Authentifizierung fehl. Dies kommt besonders häufig vor, wenn von einer CA zu einer anderen migriert wird oder wenn Jamf-Variablen anders als erwartet aufgelöst werden. Testen Sie immer mit einem einzelnen Gerät und überprüfen Sie die RADIUS-Serverprotokolle, um die genaue präsentierte Identitätszeichenfolge zu bestätigen, bevor Sie den Rollout auf die gesamte Flotte durchführen.

ROI und geschäftliche Auswirkungen

Der Übergang zur Jamf RADIUS WiFi-Zertifikatsauthentifizierung liefert messbaren geschäftlichen Mehrwert in mehreren Dimensionen.

Metrik	Typisches Ergebnis
Reduzierung von Helpdesk-Tickets	60–85 % Rückgang bei WiFi-bezogenen Supportanfragen
Onboarding-Zeit pro Gerät	Reduziert von 15–30 Minuten auf unter 2 Minuten (Zero-Touch)
Risiko von Sicherheitsvorfällen	Nahezu vollständige Eliminierung von anmeldedatenbasierten WiFi-Angriffen
Compliance-Status	Erfüllt PCI DSS Anforderung 1.3 und GDPR Artikel 32 Netzwerkkontrollen
Zertifikatslebenszyklus	Automatisierte Erneuerung eliminiert die manuelle Zertifikatsverwaltung

Der wichtigste ROI-Treiber ist die Eliminierung von Unterbrechungen durch Passwortrotationen. In einer Flotte von 500 Geräten, in der jedes Quartal 10 % der Geräte aufgrund von Passwortänderungen aus dem Netzwerk fallen und jeder Vorfall 20 Minuten IT-Zeit zur Behebung erfordert, können allein die jährlichen Einsparungen bei den Supportkosten die Implementierungsinvestition innerhalb des ersten Jahres rechtfertigen.

Für Transport -Betreiber und große Veranstaltungsorte wird der Business Case durch die Möglichkeit der Durchsetzung einer dynamischen VLAN-Zuweisung weiter gestärkt – dies stellt sicher, dass Betriebsgeräte, Mitarbeitergeräte und Managementsysteme automatisch segmentiert werden, ohne dass eine manuelle Netzwerkrekonfiguration erforderlich ist.

Schlüsselbegriffe & Definitionen

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.

Fallstudien

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.

Implementierungshinweise: 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.

Implementierungshinweise: 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.

Szenarioanalyse

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?

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

Empfohlenen Ansatz anzeigen

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?

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

Empfohlenen Ansatz anzeigen

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?

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

Empfohlenen Ansatz anzeigen

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.

Wichtigste Erkenntnisse

✓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.