iOS 27 im Unternehmen: MDM und TLS vorab testen

Verbindliche TLS-Anforderungen für iOS 27 stehen erst fest, wenn Apple sie für eine Beta, einen Release Candidate oder die finale Version veröffentlicht. Ein iOS-27-MDM-Rollout auf Basis vermuteter Grenzwerte ist fachlich nicht vertretbar, weil ein falsch positives Testergebnis das Enrollment, die App-Installation oder die Statusübermittlung erst während des Rollouts scheitern lassen kann. Dieser Leitfaden trennt deshalb belegte Prüfverfahren von Werten, die erst mit den Unterlagen zur Zielversion feststehen.

Bis eine testbare Zielversion vorliegt, erfasst das Team alle beteiligten Endpunkte und dokumentiert den aktuellen Zustand als Vergleichswert. Die Freigabe erfolgt später mit derselben MDM-Zuweisung, denselben Proxies und den realen Inhaltsservern auf einem Gerät mit der vorgesehenen iOS-Version. So entsteht ein reproduzierbarer Nachweis für die gesamte Verwaltungskette.

Welche Verbindungen muss ein iOS-27-MDM-Test abdecken?

Der Test muss jeden HTTPS-Endpunkt abdecken, den ein Gerät vom ersten Start bis zur Update-Rückmeldung erreicht. Dazu zählen der MDM-Host, Identitäts- und Zertifikatsdienste sowie alle Weiterleitungs- und Inhaltsserver. Der Apple Push Notification Service (APNs) stößt den Kontakt nur an. Den Befehl holt das Gerät anschließend beim MDM-Server ab.

Declarative Device Management (DDM) überträgt Deklarationen und zugehörige Assets über die Verwaltungsinfrastruktur. Automated Device Enrollment verbindet die Geräteaktivierung über Apple Business Manager mit der zugewiesenen MDM-Plattform. Setup Assistant kann zusätzlich einen Identitätsdienst aufrufen.

Konfigurationsprofile können auf SCEP-, ACME-, VPN- oder Authentifizierungsdienste verweisen. Bei intern verteilten Apps kommen Manifest-, Download- und Inhaltsserver hinzu. Ein Redirect kann außerdem einen Host ansprechen, der in der MDM-Konsole nicht sichtbar ist.

Damit liefert ein erfolgreicher Check-in unter einer früheren iOS-Version noch keinen Kompatibilitätsnachweis für die Zielversion.

Warum belegt eine frühere iOS-Version keine Kompatibilität?

Ein erfolgreicher MDM-Check-in bestätigt nur den getesteten Build und den dabei erreichten Netzwerkpfad. Eine spätere Version kann andere Vertrauensregeln anwenden, zusätzliche Endpunkte aufrufen oder Fehler anders behandeln. Diese Unterschiede lassen sich nicht aus einem Test mit iOS 26 ableiten.

Auch eine erfolgreich installierte App deckt nicht automatisch das Manifest, die Anmeldung und später geladene Inhalte ab. Ein bereits aktiviertes Gerät überspringt wiederum Automated Device Enrollment und Teile von Setup Assistant. Jeder Testfall braucht deshalb einen definierten Startzustand und ein erwartetes Ergebnis.

Die vollständige Endpunktliste zeigt anschließend, welche Infrastruktur in jedem Testfall tatsächlich erreicht werden muss.

Wie werden alle MDM-Endpunkte inventarisiert?

Der öffentliche MDM-Host ist nur der Ausgangspunkt. In die Inventur gehören auch Komponenten, die TLS beenden, eine Anfrage weiterleiten oder Dateien für das Gerät bereitstellen. Das betrifft eigene Systeme ebenso wie vertraglich eingebundene Plattformdienste.

Jeder Eintrag erhält eine verantwortliche Systemgruppe, die eingesetzte TLS-Komponente und einen Verweis auf den Testfall. Bei einem Load Balancer oder Reverse Proxy wird zusätzlich festgehalten, ob die Verbindung dort endet oder erneut verschlüsselt zum Backend läuft.

Mit dieser Inventur lässt sich die Testumgebung so aufbauen, dass sie den späteren Netzwerkpfad nicht unbemerkt vereinfacht.

Wie wird die Testumgebung vorbereitet?

Ein zurücksetzbares iPhone oder iPad verhindert, dass Diagnoseprofile und wiederholte Registrierungen produktive Konten beeinträchtigen. Das Gerät verwendet dieselbe MDM-Zuweisung, Proxy-Strecke und Zertifikatsinfrastruktur wie die vorgesehene Zielgruppe. Nur Datenzugriffe und Berechtigungen werden auf ein abgegrenztes Testkonto begrenzt.

Die Dokumentation nennt für jeden Lauf die vollständige Build-Nummer, den Zeitpunkt, die Gerätezuweisung und aktive Diagnoseprofile. Ein für die Zielversion veröffentlichtes Netzwerkdiagnoseprofil wird nur mit den dazugehörigen Auswertungshinweisen verwendet.

Fehlen im Testteam Grundlagen zur Geräteverwaltung, bündelt die Übersicht zu iPhone- und iPad-Schulungen die passenden Themen. Den Nachweis für die eigene MDM- und Netzwerkumgebung ersetzt eine Schulung nicht.

Nach der Baseline beginnt der durchgängige Test aller Verwaltungsabläufe.

Welche MDM-Abläufe gehören in den Gerätetest?

Der Lauf beginnt mit einem definierten Gerätezustand und endet erst nach der letzten erwarteten Statusmeldung. Zeitstempel im Testprotokoll verbinden jeden Arbeitsschritt mit den später ausgewerteten Netzwerkereignissen.

1. Ein zurückgesetztes Gerät durchläuft Automated Device Enrollment und Setup Assistant einschließlich der vorgesehenen Identitätsprüfung
2. Die MDM-Plattform sendet Befehle, während das Gerät Antworten und Statuswerte zurückliefert
3. DDM-Deklarationen und deklarative Assets werden geladen, angewendet und über die vorgesehenen Statuskanäle bestätigt
4. Konfigurationsprofile werden installiert, aktualisiert und entfernt, einschließlich eingebundener Zertifikatsdienste
5. Eine verwaltete App und eine intern verteilte App verwenden ihre realen Manifest-, Download- und Anmeldepfade
6. Ein Software-Update wird über die MDM-Plattform angestoßen und bis zur letzten Statusmeldung verfolgt
7. Eine Wiederherstellung wird getestet, wenn sie zum vorgesehenen Bereitstellungsprozess gehört und für die Zielversion dokumentiert ist

Für jeden Schritt stehen vor dem Lauf das erwartete Ergebnis und die maximal akzeptierte Wartezeit fest. Ein grüner Status in der MDM-Konsole genügt nicht, wenn das Gerät einen Teilvorgang übersprungen hat oder ein Backend die Meldung verspätet verarbeitet.

Erst das Geräteprotokoll zeigt, in welchem Zeitfenster die zugehörigen TLS- und Vertrauensfehler gesucht werden müssen.

Wie werden sysdiagnose und TLS-Befunde ausgewertet?

Die sysdiagnose wird unmittelbar nach dem Testlauf auf dem betroffenen Gerät erstellt. Ausgewertet werden nur Meldungen, die zeitlich und anhand des Hostnamens einem protokollierten Arbeitsschritt zugeordnet werden können. Allgemeine Warnungen ohne Bezug zum Testfall gehören nicht automatisch in die Fehlerliste.

Relevante Befunde betreffen beispielsweise den TLS-Handshake, die Zertifikatsprüfung, eine Weiterleitung oder einen abweichenden Servernamen. Bei einem Redirect wird der tatsächlich erreichte Zielhost erfasst. Die zuerst aufgerufene URL kann technisch fehlerfrei sein, obwohl der nachgelagerte Server die Verbindung abbricht.

Eine sysdiagnose kann Geräte-, Konto- und Netzwerkdaten enthalten. Speicherung, Zugriff und Löschung folgen deshalb den internen Vorgaben für Diagnose- und Personaldaten.

Die zugeordneten URLs lassen sich anschließend einzeln untersuchen, ohne den Gerätetest mit einer reinen Hostprüfung zu verwechseln.

Was zeigt eine ATS-Diagnose mit nscurl?

Das macOS-Werkzeug nscurl führt ATS-Diagnosen gegen eine konkrete URL aus. Ein typischer Aufruf lautet:

nscurl --ats-diagnostics "https://mdm.example.invalid/checkin"

Die reservierte Domain example.invalid ist ein Platzhalter und wird durch den realen Host ersetzt. Der vollständige Aufruf, die macOS-Version und die gesamte Ausgabe gehören zum Befund, damit ein späterer Test dieselben Bedingungen verwendet.

nscurl --ats-diagnostics liefert mehrere Tests mit unterschiedlichen ATS-Konfigurationen. Ein einzelnes PASS ist daher kein allgemeiner Nachweis für iOS 27 MDM und auch keine Bestätigung für den vollständigen Enrollment-Ablauf. Entscheidend ist die Konfiguration, die den veröffentlichten Anforderungen der Zielversion entspricht.

Aus dem Hosttest ergibt sich, welche TLS-, Zertifikats- oder Redirect-Einstellung vor dem nächsten Gerätelauf korrigiert werden muss.

Welche TLS-Einstellungen werden am Server geprüft?

Die Korrektur erfolgt an der Komponente, die TLS für den betroffenen Host tatsächlich beendet. Das kann ein MDM-Server, Load Balancer, Reverse Proxy oder Inhaltsserver sein. Eine Änderung am Backend bleibt wirkungslos, wenn der öffentliche TLS-Handshake bereits am vorgeschalteten Proxy scheitert.

• Die angebotenen TLS-Versionen und Cipher-Suites entsprechen den veröffentlichten Anforderungen der getesteten iOS-Version
• Der angeforderte Hostname ist im Zertifikat enthalten und wird über SNI dem richtigen virtuellen Host zugeordnet
• Die ausgelieferte Zertifikatskette enthält die benötigten Zwischenzertifikate und endet bei einer vertrauenswürdigen Stammzertifizierungsstelle
• Zertifikat, Signaturalgorithmus und Schlüsselparameter erfüllen die Vorgaben der Zielversion
• Weiterleitungen behalten HTTPS bei und führen auf vollständig geprüfte Zielhosts
• TLS-Inspection, Load Balancer und Backend liefern über den realen Gerätepfad dieselbe erwartete Kette

Für eine erste Sichtprüfung der ausgelieferten Zertifikatskette eignet sich auf einem berechtigten Administrationssystem beispielsweise:

openssl s_client -connect mdm.example.invalid:443 -servername mdm.example.invalid -showcerts

Auch dieser Aufruf ersetzt weder ATS noch den Test auf dem Gerät. Nach jeder Änderung folgt derselbe Ablauf mit identischem Testfall und dokumentiertem Build, bevor die Rollout-Freigabe geprüft wird.

MDM-Readiness-Checkliste für den iOS-27-Rollout

• Übernimm die veröffentlichten Anforderungen der Zielversion in eine versionierte Abnahmematrix
• Bestätige jeden inventarisierten Host mit dem vorgesehenen Endpunkttest und einem realen Geräteablauf
• Verifiziere Enrollment, MDM-Befehle, DDM, Profile, App-Verteilung und Software-Updates auf den vorgesehenen Gerätetypen
• Dokumentiere Build-Nummer, Zeitstempel, Diagnoseausgaben und verantwortliche Systemgruppen
• Definiere Rollout-Wellen, messbare Abbruchkriterien, Rücksetzverfahren und Eskalationskontakte
• Wiederhole den gesamten Test mit dem final eingesetzten iOS-Build

Die Freigabeakte verbindet jeden Endpunkt mit einem Gerätetest, einem TLS-Befund und dem zugehörigen iOS-Build. Lege als nächsten Schritt ein zurücksetzbares Testgerät an und protokolliere einen vollständigen Automated-Device-Enrollment-Durchlauf als Baseline.