Apple-WLAN, Zertifikate, VPN und Proxy mit Sophos Mobile planen

Geltungsbereich: Sophos Mobile in Sophos Fusion (ehemals Sophos Central), iPhone und iPad mit iOS/iPadOS. Diese Orientierung trennt iOS-Geräterichtlinien (Device Policy) von iOS-Benutzerrichtlinien (User Policy). Sie ist keine getestete Schritt-für-Schritt-Konfiguration für einen konkreten Tenant, keine macOS-Anleitung und keine Freigabe zur produktiven Massenverteilung. Betriebssystemversion, Enrollment-Modus, Aufsicht (Supervision), Richtlinientyp und die im eigenen Tenant verfügbaren Funktionen zuerst am Zielgerät prüfen.

⚠️ Verbindung nicht abschneiden: Ein falsches WLAN-/EAP-Zertifikat, eine unerreichbare SCEP-CA, ein fehlerhaftes PAC/WPAD oder ein VPN-Tunnel können auch den Rückkanal für MDM-Aufgaben unterbrechen. Vor Änderungen eine vom geänderten Profil unabhängige Verbindung und einen lokalen Entstörungsweg nachweisen. Ein in der Konsole gespeicherter Rollback erreicht ein offline ausgesperrtes Gerät nicht automatisch.

Zuerst den Verwaltungsmodus unterscheiden

Device Enrollment bedeutet nicht automatisch Supervision (Aufsicht): Automated Device Enrollment beaufsichtigt das Gerät, andere Methoden nicht zwingend. Apple User Enrollment beaufsichtigt es nie und betrifft verwaltete Daten statt das gesamte Privatgerät. Für BYOD gehören Managed Apple Account und Einwilligung zum Vorlauf. Dort gibt es keinen globalen HTTP-Proxy, kein normales geräteweites VPN und keine Proxy-Einstellungen in der verwalteten Wi-Fi-Konfiguration; Sophos kann MAC/UDID/IMEI nicht für eine NAC-Identifikation abfragen.

Sophos begrenzt profilbasiertes User Enrollment auf iOS/iPadOS 17 oder älter; das ist keine generelle Abschaffung des account-driven User Enrollment. Bei Abmeldung werden das verwaltete APFS-Volume und der verwaltete Apple Account auf dem Gerät entfernt; das ist kein allgemeiner WLAN- oder VPN-Rollback. Apple beschreibt Per-App-VPN als mögliche User-Enrollment-Funktion, nicht als Nachweis eines funktionierenden Sophos-App-Zuordnungswegs.

WLAN und Zertifikatskette zusammen planen

BYOD-Pilot vor jeder Änderung isolieren: Für iOS-/iPadOS-Benutzerrichtlinien synchronisiert Sophos Änderungen automatisch bei jeder erneuten Verbindung des Geräts mit Sophos Mobile; ein manuelles Update devices ist dafür nicht nötig. Deshalb eine separate, nur dem freigegebenen BYOD-Testgerät zugewiesene Benutzerrichtlinie verwenden und ihre aktuellen Zuweisungen samt Zielgerätezahl vor dem Bearbeiten und vor Save prüfen. Keine bereits gemeinsam mit produktiven BYOD-Geräten zugewiesene Richtlinie im Pilot ändern. Eine anschliessende Zuweisung an ausgewählte Testgeräte begrenzt nicht die Synchronisierung der Änderung auf anderen Geräten, denen dieselbe Richtlinie bereits zugewiesen ist. Diese Scope-Regel gilt auch für Zertifikatsänderungen und Korrekturen beim Rückbau; die Synchronisierung allein bestätigt weder Netzfunktion noch MDM-Rückweg.

Wer prüft wen? Bei Enterprise-WLAN mit EAP (Authentifizierung zwischen Gerät und Netz) prüft das Gerät Namen und Zertifikatskette des RADIUS-Servers. Bei zertifikatsbasierter Anmeldung prüft RADIUS umgekehrt die ausgestellte Clientidentität. Server-CA und Clientidentität haben also verschiedene Aufgaben. Die in der WLAN-Konfiguration wählbare Identity certificate setzt eine Client certificate-Konfiguration derselben Richtlinie voraus; das Serverzertifikat unter Trusted certificates eine dortige Root certificate-Konfiguration.

Nur fiktive Platzhalter, nicht übernehmen: radius.test.invalid als Servername, Test-CA als vertrauenswürdige Server-CA und CN=Testperson,OU=Pilot,O=Beispiel als X.500-Subject (Felder für die Clientidentität). Alle Werte durch die vom eigenen PKI-/RADIUS-Team bestätigten Namen, CA und Identitätsfelder ersetzen. Am Testgerät prüfen, ob die konfigurierte Serveridentität zur echten Kette passt und RADIUS das ausgestellte Clientzertifikat annimmt. Das Rootzertifikat ist ein X.509-Zertifikat in PEM/DER; ein importiertes Clientzertifikat ist PKCS#12 (.pfx). Ein .pfx-Upload ist nicht automatisch über mehrere Richtlinien wiederverwendbar: Wird das Clientzertifikat in einer anderen Richtlinie benötigt, muss es dort erneut hochgeladen werden. CA-Herkunft, Schlüsselbesitz, Gültigkeit und beabsichtigten Verwendungszweck prüfen. Das Hochladen einer Root-CA beweist kein universelles Vertrauen aller Apps.

Für Root certificate in einer iOS-Geräterichtlinie auf Edit policy über Add configuration > Root certificate die Konfiguration öffnen. Mit Upload a file die X.509-Datei in PEM/DER auswählen und mit Open öffnen. Nach dem Upload zeigt Certificate name den Distinguished Name (DN) des Ausstellers an, nicht die Clientidentität. Mit Apply die Konfiguration speichern, danach auf Edit policy mit Save die Richtlinie speichern. Laut Sophos installiert die Zuweisung der Richtlinie das hochgeladene Rootzertifikat auf dem Gerät. Die Anzeige und das Speichern allein beweisen weder Vertrauen noch Gültigkeit oder erfolgreiche Installation. Für jedes weitere Rootzertifikat ist eine eigene Root certificate-Konfiguration in derselben Richtlinie nötig.

Für Root certificate in einer iOS-Benutzerrichtlinie beschreibt Sophos den Import auf Edit policy über Add configuration > Root certificate. Mit Upload a file die X.509-Datei in PEM/DER auswählen und mit Open öffnen. Nach dem Upload zeigt Certificate name den Distinguished Name des Ausstellers an. Mit Apply die Konfiguration speichern, danach auf Edit policy mit Save die Richtlinie speichern. Für jedes weitere Rootzertifikat eine eigene Root certificate-Konfiguration hinzufügen. Laut Sophos installiert die Zuweisung der Benutzerrichtlinie das Zertifikat auf dem Gerät; innerhalb derselben Richtlinie lässt es sich etwa als EAP-Serverzertifikat im WLAN verwenden. Upload-Anzeige und gespeicherte Richtlinie belegen weder eine erfolgreiche Installation noch Zertifikatsvertrauen oder eine funktionierende WLAN-Anmeldung.

In der Client certificate-Konfiguration der iOS-Geräterichtlinie unter File zuerst Upload a file und danach die PKCS#12-Zertifikatdatei (.pfx) wählen. Unter Certificate name zeigt Sophos Mobile den aus der Zertifikatdatei gelesenen Namen an. Dieser Name allein belegt weder Vertrauen noch Gültigkeit oder eine erfolgreiche Installation.

Vor der SCEP-Konfiguration: Wenn die in Sophos setup konfigurierte SCEP-Anbindung mit den unten genannten Variablen verwendet wird, zuerst den SCEP-Voraussetzungs- und Zertifikatsablauf prüfen: Erreichbarkeit von Sophos Fusion zur CA, regional begrenzte Firewall-Freigaben und für diesen dokumentierten Windows-CA-Weg einen für Challenge-Erstellung und Zertifikats-Enrollment berechtigten Zugang. Vor SCEP das CA-Zertifikat des SCEP-Servers als Root certificate in derselben Richtlinie bereitstellen. Dieses Serververtrauen ist von RADIUS-Serververtrauen und ausgestellter Clientidentität getrennt; Windows ist damit nicht als Voraussetzung jeder direkten SCEP-Implementierung behauptet.

SCEP (Simple Certificate Enrollment Protocol) lässt ein Gerät ein Zertifikat von der CA anfordern. Dafür ist eine erreichbare CA-URL beziehungsweise die korrekt konfigurierte Sophos-SCEP-Proxy-Variable erforderlich. X.500-Subject-Felder und SAN/UPN (zusätzliche Identitätsnamen), Challenge, Wiederholungsparameter für ausstehende Anträge, Schlüssellänge und Nutzungsbits vom PKI-Team auf die eigene CA abstimmen lassen. Für die SCEP-Konfiguration einer iOS-Geräterichtlinie sind dabei diese Entscheidungen wichtig:

• CA-Endpunkt und Name: URL ist die Webadresse des CA-Servers. %_SCEPPROXYURL_% verweist auf die Server-URL im Register SCEP der Seite Sophos setup. CA name ist ein Name, den die CA versteht; er kann beispielsweise zur Unterscheidung von CA-Instanzen dienen. Den von der eigenen CA erwarteten Namen mit dem PKI-Team bestätigen. Das Feld ist nicht die Anzeige Certificate name eines importierten Zertifikats und nicht der beispielhafte Name der vertrauenswürdigen RADIUS-Server-CA.
• Benutzer- oder Geräteidentität: Subject darf Platzhalter für Benutzerdaten oder Geräteeigenschaften enthalten. Sophos nennt CN=%_USERNAME_% für einen Benutzer und CN=%_DEVPROP(SerialNumber)_% für ein iPhone oder iPad. Das sind dokumentierte Syntaxbeispiele, keine für den eigenen Tenant geprüften Werte. Die gewünschte Identität mit dem PKI-Team freigeben und prüfen, ob die Daten verfügbar sind und der Subject nach Ersetzung ein gültiger X.500-Name ist. BYOD: Ein dokumentierter Seriennummern-Platzhalter beweist nicht, dass im User Enrollment eine seriennummerbasierte Identität auflösbar ist; Sophos kann dort Gerätekennungen nicht abfragen. Subject und Ausstellung mit einer Testperson prüfen.
• SAN-Typ und Wert: Unter Type of Subject Alternative Name den vom PKI-Team freigegebenen Typ wählen und den passenden Wert unter Value of Subject Alternative Name eintragen. RFC 822 name bezeichnet eine gültige E-Mail-Adresse. Für diese iOS-SCEP-Konfiguration beschreibt Sophos DNS name als DNS-Namen des CA-Servers und Uniform resource identifier als dessen vollständig qualifizierte URL – nicht als RADIUS-Servernamen oder Challenge-Adresse. AD user logon name ist davon getrennt und bezeichnet den in Active Directory gesetzten UPN. Challenge ist die Webadresse, unter der das Gerät ein Challenge-Passwort vom SCEP-Server erhält. %_CACHALLENGE_% verweist auf die im Register SCEP der Seite Sophos setup konfigurierte Challenge-URL, nicht auf das Passwort selbst. Keine echten Geheimnisse in öffentliche Beispiele oder Tickets übernehmen.
• Ausstehende Anträge: Retries legt die Anzahl erneuter Versuche fest, wenn der Server mit pending antwortet; es ist kein allgemeiner Wiederholungszähler für alle Netzfehler. Retry delay ist der Abstand zwischen diesen Versuchen in Sekunden. Anzahl und Abstand mit dem PKI-Team vereinbaren, nicht mit der Zertifikatserneuerung verwechseln.
• Schlüssel und Verwendungszweck: Key size bezeichnet die Grösse des öffentlichen Schlüssels im ausgestellten Zertifikat und muss mit der auf dem SCEP-Server konfigurierten Grösse übereinstimmen. Certificate usage legt den zulässigen Verwendungszweck fest: Use as digital signature für digitale Signaturen, Use for encryption für Datenverschlüsselung. Die Auswahl muss zu den PKI-Vorgaben und zum Zielservice passen; sie beweist weder eine erfolgreiche WLAN-/VPN-Anmeldung noch die Verschlüsselung des gesamten Geräteverkehrs.

Bei der Policy-Erstellung gibt es das Feld SCEP renewal interval. Intervall, Ablauf, Widerruf und Ersatz mit dem PKI-Team prüfen; ein eingestelltes Intervall garantiert weder erfolgreiche Erneuerung noch Wiederherstellung eines offline gebliebenen Geräts.

Identitätsersetzung in Geräte- und Benutzerrichtlinien: Im obigen Beispiel CN=%_USERNAME_% wird %_USERNAME_% durch Exchange Login des dem Gerät zugewiesenen Benutzers ersetzt, nicht zwingend durch dessen Anzeigenamen und nicht automatisch durch den AD-UPN. Die richtige Benutzerzuordnung und diesen Eigenschaftswert vor Zuweisung prüfen; der ersetzte Subject muss weiterhin ein gültiger, vom PKI-Team freigegebener X.500-Name sein. AD user logon name bleibt das getrennte UPN-Feld.

Für SCEP in einer iOS-Benutzerrichtlinie die Endpunkte getrennt festlegen. URL ist die Webadresse des CA-Servers. Die Variable %_SCEPPROXYURL_% verweist auf die Server-URL im Register SCEP der Seite Sophos setup. Challenge ist die URL zum Abrufen eines Challenge-Passworts vom SCEP-Server, nicht das Passwort selbst. %_CACHALLENGE_% verweist auf die dort im Register SCEP konfigurierte Challenge-URL. Wie bei den oben beschriebenen Antragsparametern zählt Retries nur Wiederholungen nach einer pending-Antwort; Retry delay gibt deren Abstand in Sekunden an. Key size muss der auf dem SCEP-Server konfigurierten Grösse des öffentlichen Schlüssels entsprechen. Diese Parameter mit dem PKI-Team bestätigen; sie sind keine Erneuerungsintervalle und kein Nachweis erfolgreicher Ausstellung.

Enterprise-WLAN und private WLAN-Adresse

Für einen isolierten Geräte-WLAN-Pilot verbindet der folgende Weg die Netzangaben mit der Richtlinienzuweisung. Vorher den unabhängigen Netz- und Rückweg aus dem Pilotabschnitt sichern; keine produktiv zugewiesene Richtlinie bearbeiten.

1. Unter Policies die zum Zielgerät passende Apple-Plattform öffnen, mit Create eine Geräterichtlinie erstellen und Name, Beschreibung sowie Organisationsnamen eintragen. Auf Edit policy mit Add configuration die Wi-Fi-Konfiguration hinzufügen und zum Bearbeiten ihren Namen öffnen. Für Enterprise-WLAN zuerst die benötigten Client- und Rootzertifikate derselben Richtlinie wie oben beschrieben bereitstellen; Apply bei den Rootzertifikat-Konfigurationen ersetzt nicht Save für die gesamte Richtlinie.
2. Unter SSID den vom Netzteam bestätigten WLAN-Namen eintragen und Security type auf die tatsächliche Methode samt Personal-/Enterprise-Variante abstimmen. Personal benötigt das WLAN-Passwort; für Enterprise die unten beschriebenen EAP-, Anmelde- und Vertrauenseinstellungen verwenden. Connect automatically verbindet bei verfügbarem Netz automatisch; Hidden network bezeichnet ein Netz ohne ausgestrahlte SSID. Beide Optionen nur passend zum vorgesehenen Netz wählen, nicht als Sicherheitsnachweis.
3. Alle Konfigurationen prüfen und auf Edit policy mit Save die Richtlinie speichern. Für die anschliessende Zuweisung den Ablauf «Richtlinie erstellen und zuweisen» verwenden: die gespeicherte Pilotrichtlinie wählen, nur die freigegebenen einzelnen Testgeräte markieren und Liste sowie Anzahl vor Finish abgleichen. Die dortigen Termin- und iPadOS-Vorbehalte beachten. Danach Task-/Zuweisungsstatus, tatsächliche WLAN-Anmeldung und MDM-Check-in getrennt nach den unten genannten Prüfkriterien beobachten; Speichern und Zuweisen sind keine bestätigten Verbindungsergebnisse.

Für die Wi-Fi-Konfiguration einer iOS-Geräterichtlinie zuerst Security type passend zum Netz wählen. Bei einer Personal-Variante steht das WLAN-Passwort zur Verfügung. Erst eine Enterprise-Variante bietet Protocols, Authentication und Trusted certificates. Unter Accepted EAP types die vom Gerät akzeptierten Verfahren mit dem RADIUS-Team auf die Netzanmeldung abstimmen. Die oben beschriebenen Client- und Rootzertifikate bleiben an dieselbe Richtlinie gebunden.

Unter Authentication der iOS-Geräterichtlinie sind User der WLAN-Benutzername und Password das WLAN-Passwort für die Anmeldung mit Zugangsdaten. Require password on each connect sendet laut Sophos das Passwort bei jeder Authentifizierung; die Option verspricht keine interaktive Passwortabfrage. Den Zugangsdatenweg und diese Auswahl mit dem RADIUS-Team abstimmen. Für zertifikatsbasierte Anmeldung stattdessen die passende Identity certificate aus einer Client certificate-Konfiguration derselben Geräterichtlinie wählen. Am Testgerät je nach gewähltem Weg die Annahme der Zugangsdaten oder des Clientzertifikats durch RADIUS prüfen; Serveridentität und Vertrauenskette bleiben in beiden Fällen separat zu prüfen.

Bei TTLS bezeichnet Internal identity das Protokoll für die Benutzeranmeldung innerhalb des Tunnels. Das ist nicht die äussere Identität. Für EAP-FAST kann ein Protected Access Credential (PAC) konfiguriert werden; dieses PAC ist kein Proxy-Autokonfigurationsskript. TTLS-Protokoll und gegebenenfalls EAP-FAST-Credential mit dem RADIUS-Team klären und die Anmeldung am Zielgerät prüfen. Ohne diese Klärung den betreffenden EAP-Zweig im Pilot ausklammern.

Bei EAP beide TLS-Grenzen setzen oder beide offenlassen. Sophos beschreibt Outer identity für TTLS, PEAP und EAP-FAST und verlangt eine äussere Identität für TLS 1.3. Dafür keine Benutzernamen oder Geheimnisse verwenden, weil die äussere Identität im Klartext übertragen wird. Eine anonyme äussere Identität mit passendem Realm muss das PKI-/RADIUS-Team bei Bedarf für die Weiterleitung prüfen. Die ausgehandelte Anmeldung und TLS-Version am Testgerät beobachten; die Auswahl allein belegt keine erfolgreiche Verbindung.

Turn off private address lässt das Gerät für dieses WLAN seine Hardware-MAC-Adresse statt einer von iOS erzeugten netzspezifischen Adresse verwenden. Das reduziert die Privatsphäre. Die Option nur verwenden, wenn sich das Gerät über die eigenen Netze hinweg zwingend mit derselben MAC-Adresse identifizieren muss. Laut Sophos funktioniert Synchronized Security nicht mit privaten MAC-Adressen: Sophos Fusion Wireless kennt nur die private Adresse, Sophos Mobile nur die Hardware-Adresse. Das Abschalten allein garantiert aber keine funktionierende Synchronized Security; die Zuordnung und das gewünschte Verhalten im vorgesehenen Netz prüfen. Nicht als BYOD-Workaround für NAC behandeln. Für User Enrollment fehlt Sophos die MAC-Adresse für NAC.

Auch für Wi-Fi in einer iOS-Benutzerrichtlinie unterscheidet Sophos unter Security type zwischen Personal und Enterprise. Personal verwendet das WLAN-Passwort. Protocols, Authentication und Trusted certificates sind nur bei Enterprise verfügbar. Für eine Anmeldung mit Zugangsdaten sind User der WLAN-Benutzername und Password das WLAN-Passwort. Require password on each connect sendet laut Sophos das Passwort bei jeder Authentifizierung. Diese Auswahl mit dem RADIUS-Team abstimmen, nicht als Zusage einer Passwortabfrage verstehen. Bei zertifikatsbasierter Anmeldung stattdessen die passende Identity certificate aus einer Client certificate-Konfiguration derselben Benutzerrichtlinie wählen. Auch das Serverzertifikat unter Trusted certificates braucht eine Root certificate-Konfiguration in dieser Richtlinie. Clientzertifikat und dessen Annahme durch RADIUS nur für den zertifikatsbasierten Anmeldeweg als Prüfkriterium verwenden.

Die oben beschriebenen EAP-Entscheidungen gelten laut der Wi-Fi-Beschreibung auch für diese Benutzerrichtlinie. Accepted EAP types mit der Netzanmeldung abstimmen, bei TTLS das Protokoll unter Internal identity und bei EAP-FAST gegebenenfalls das Protected Access Credential (PAC) klären. Dieses Credential ist kein Proxy-PAC-Skript. Beide TLS-Grenzen setzen oder beide offenlassen. Outer identity ist für TTLS, PEAP und EAP-FAST beschrieben und für TLS 1.3 erforderlich. Die Klartext- und Realm-Hinweise oben beachten. Daraus weder die Verfügbarkeit aller Optionen im eigenen Tenant noch eine erfolgreiche Anmeldung ableiten; der Ausschluss eines verwalteten WLAN-Proxys und der MAC-/NAC-Vorbehalt bei User Enrollment bleiben bestehen.

Proxy und VPN sind verschiedene Eingriffe

• WLAN-Proxy: In der iOS-Geräterichtlinie manuell oder über PAC (Datei mit Proxy-Regeln) konfigurierbar. Bei Apple User Enrollment unterstützt die WLAN-Konfiguration keinen Proxy. Sophos nennt dort WPAD (automatisches Finden eines Proxys) am Access Point und eine vom Benutzer unter den WLAN-Einstellungen auf HTTP-Proxy: Automatisch gestellte Option als möglichen Ausweichweg – nicht als fernverwaltete BYOD-Proxy-Payload. PAC/WPAD, DNS und Erreichbarkeit einzeln testen.
• Globaler HTTP-Proxy: Sophos erlaubt diese iOS-Gerätekonfiguration nur für beaufsichtigte Geräte; manuell mit Server/Port/gegebenenfalls Zugangsdaten oder automatisch mit PAC-URL. Im manuellen Modus ist Server der Name oder die IP-Adresse des HTTP-Proxys und Port dessen Portnummer. Authentication ist der Benutzername für die Verbindung mit dem Proxy-Server, Password das zugehörige Passwort. Weder ein BYOD- noch ein Ausfallsicherheitsversprechen.
• Geräteweites VPN: Die iOS-Geräterichtlinie kennt Verbindungstyp, Server und Authentifizierung; bei Custom SSL/TLS muss die Anbieter-App installiert sein. Diese Konfiguration nicht auf Apple User Enrollment übertragen: Apple erlaubt dort kein normales geräteweites VPN.
• Per-App-VPN: Eigene Konfiguration für ausgewählte Apps, nicht gleichbedeutend mit einem Geräte-VPN. Anbieter-App, Server, Authentifizierung, optionale Zertifikate/Proxy, On-Demand und Domänenregeln für Safari/andere Browser, Kalender, Kontakte und Mail getrennt prüfen. Auch Send all traffic through VPN nach tatsächlichem Geltungsbereich prüfen; aus dem Namen keine universelle App-Isolation oder geräteweite Wirkung ableiten. Sophos-Dokumentation ist hier uneinheitlich: Die User-Policy-Beschreibung enthält Per-App-VPN, aber die App-Zuordnung nennt nur Device Policies als Voraussetzung und Auswahl. Deshalb keinen funktionierenden BYOD-Zuordnungsklickpfad behaupten: im aktuellen Tenant mit Test-App und Testgerät erst nachweisen.

Geräte-VPN: Anbieter, Anmeldung und Verkehrsweg

Die folgenden Angaben gehören zur VPN-Konfiguration einer iOS-Geräterichtlinie, nicht zur Per-App-VPN-Konfiguration oder zu Apple User Enrollment. Verfügbarkeit und Anbieterunterstützung im eigenen Tenant prüfen. Connection name ist der auf dem Gerät angezeigte Name der Verbindung. Unter Server den Hostnamen oder die IP-Adresse des VPN-Servers eintragen; den passenden Endpunkt mit dem VPN-Verantwortlichen bestätigen.

• Bei Connection type den passenden Anbieter beziehungsweise Verbindungstyp wählen. Für eine VPN-Anbieter-App aus dem App Store beschreibt Sophos Custom SSL/TLS. Die App muss installiert sein; unter Identifier (reverse DNS format) ihren Bezeichner im Reverse-DNS-Format eintragen. Wenn der Anbieter eigene Verbindungsparameter vorgibt, die bestätigten Schlüssel und Werte unter Third-party settings als Verbindungseigenschaften erfassen. Keine Schlüssel oder Werte aus anderen Anbieter-Konfigurationen übernehmen.
• User authentication betrifft die Benutzeranmeldung. Account ist das Benutzerkonto der VPN-Verbindung; Group kann eine dafür erforderliche Authentifizierungsgruppe angeben. Bei Password das VPN-Passwort, bei Certificate das VPN-Authentifizierungszertifikat angeben. Ob eine Gruppe nötig ist und welche Identität verwendet wird, mit dem VPN-Verantwortlichen klären. Diese Zugangsdaten sind keine Proxy-Zugangsdaten.
• Device authentication ist davon getrennt. Bei Keys (Shared Secret)/Group name die erforderliche Gruppe unter Group name und den gemeinsamen Schlüssel unter Keys (Shared Secret) angeben. Sophos nennt dazu Use hybrid authentication und Request password, beschreibt auf dieser Seite aber nur eine Auswahl nach Bedarf. Ihre Wirkung und notwendige Auswahl sind hier nicht geklärt; diese beiden Optionen erst nach Bestätigung durch den Anbieter in den Pilot aufnehmen. Bei Certificate das erforderliche Geräte-Authentifizierungszertifikat auswählen. Including user PIN nimmt laut Sophos optional die Benutzer-PIN in die Geräteauthentifizierung auf. Keinen dieser Zweige ohne Prüfung auf jeden Anbieter übertragen und keine echten Schlüssel oder PINs in Tickets festhalten.
• Send all traffic through VPN ist die Einstellung für den gesamten Verkehr über diese VPN-Verbindung. Sophos beschreibt dafür, dass aller Verkehr durch das VPN gesendet wird. Den tatsächlichen Verkehrsweg im gewählten Anbieter-/Tunnelmodus am Testgerät prüfen und den MDM-Rückkanal separat kontrollieren. Das ist kein Nachweis lückenloser Verkehrserfassung oder von App-Isolation.
• Unter Proxy den Proxy dieser VPN-Verbindung festlegen. No proxy bedeutet ohne Verbindungs-Proxy. Bei Manually unter Server and port die Proxy-Adresse und den Port eintragen; Authentication ist der Proxy-Benutzername, Password sein Passwort. Bei Automatic unter Proxy server URL die URL des Servers mit den Proxy-Einstellungen angeben. Diese Auswahl ist weder der WLAN-Proxy noch die globale HTTP-Proxy-Payload; daraus keine Aufsichtsvoraussetzung oder Ausfallsicherung ableiten.
• Provider type unterscheidet die Transportebene, nicht den Anbieter aus Connection type. App proxy transportiert Verkehr im VPN-Tunnel auf Anwendungsebene, Packet tunnel auf Netzwerkebene. App proxy ist damit nicht gleichbedeutend mit Per-App-VPN. Welche Auswahl der Anbieter unterstützt und welchen Verkehr sie tatsächlich erfasst, bleibt am Zielgerät zu prüfen.

Per-App-VPN: Eingaben und Verbindungsstart

Für Per app VPN in einer iOS-Geräterichtlinie beschreibt Sophos folgende Eingaben und Verhaltensweisen; die Wirkung bleibt im Pilot zu prüfen. Diese Angaben lösen den oben genannten Widerspruch bei der User-Policy-App-Zuordnung nicht auf.

Bei Per app VPN sowohl in iOS-Geräterichtlinien als auch in iOS-Benutzerrichtlinien ist Connection name der auf dem Gerät angezeigte Name der Verbindung. Das ist die sichtbare Verbindungsbezeichnung, nicht der Reverse-DNS-Bezeichner der Anbieter-App, die Serveradresse oder das Benutzerkonto.

• Anbieter-App: Hat der VPN-Anbieter eine App im App Store, die die VPN-Verbindung bereitstellt, Custom SSL/TLS wählen. Diese VPN-App muss auf dem Gerät installiert sein; unter Identifier (reverse DNS format) ihren Bezeichner im Reverse-DNS-Format eintragen, nicht den der zu tunnelnden Fach-App.
• VPN-Anmeldung: Server ist der Hostname oder die IP-Adresse des VPN-Servers, Account das Benutzerkonto zur Authentifizierung der Verbindung. Unter User authentication zwischen Password und Certificate wählen und dazu unter Password das VPN-Passwort oder unter Certificate das VPN-Authentifizierungszertifikat angeben. Diese Angaben sind von den Zugangsdaten eines Verbindungs-Proxys getrennt.
• Verbindungsstart: Ist Connect automatically on demand eingeschaltet, aktiviert das Gerät laut Sophos das VPN, wenn die App eine Netzwerkverbindung aufbaut. Ist die Option ausgeschaltet, müssen Benutzer das VPN selbst einschalten. Beide Abläufe am vorgesehenen Testgerät prüfen.
• Verbindungs-Proxy: Proxy kennt No proxy, Manually und Automatic. Bei manueller Konfiguration unter Server and port die gültige Proxy-Adresse und den Port angeben, unter Authentication den Proxy-Benutzernamen und unter Password dessen Passwort. Bei automatischer Konfiguration unter Proxy server URL die URL des Servers mit den Proxy-Einstellungen eintragen. Das ist der Proxy dieser VPN-Verbindung, nicht die globale HTTP-Proxy-Payload.

Für Domains in Safari, Domains in Calendar, Domains in Contacts und Domains in Mail gilt dieselbe Eingabesyntax: eine Domäne, Teildomäne oder ein Hostname pro Zeile. Eine Teildomäne passt, wenn alle durch Punkte getrennten Bestandteile von rechts aus übereinstimmen; führende und abschliessende Punkte werden ignoriert. Eine Zeichenfolge ohne Punkt passt nur zum Host dieses Namens, nicht zu beliebigen Domänen mit dieser Endung. Die zusätzliche Second-Level-Domain-Regel für Kalender, Kontakte und Mail gilt daneben; den passenden Positivtest beschreibt der Pilotabschnitt.

Per-App-VPN in der Benutzerrichtlinie und App-Zuordnung

Die Sophos-Beschreibung von Per app VPN in einer iOS-Benutzerrichtlinie dokumentiert ebenfalls die oben erklärten Eingaben für die installierte VPN-Anbieter-App und deren Reverse-DNS-Bezeichner, die Anmeldung mit Password oder Certificate, den On-Demand-Verbindungsstart, den Verbindungs-Proxy und die Domänensyntax. Diese dokumentierten Gemeinsamkeiten belegen keinen funktionierenden Zuordnungsweg bei Apple User Enrollment.

Die folgenden bedingten Felder dokumentiert Sophos für Per app VPN sowohl in iOS-Geräterichtlinien als auch in iOS-Benutzerrichtlinien. Die Bedingungen gelten für beide Richtlinientypen; Verfügbarkeit und Anbieterunterstützung im eigenen Tenant prüfen:

• Unter Third-party settings lassen sich vom VPN-Anbieter vorgegebene Verbindungseigenschaften erfassen. Das Feld ist nur bei Custom SSL/TLS verfügbar. Mit Add die bestätigten Werte für Key und Value eintragen. Diese Verbindungseigenschaften sind nicht die Managed configuration der zu tunnelnden Fach-App.
• Group bezeichnet die für die Anmeldung erforderliche Gruppe. Das Feld ist nur für Cisco AnyConnect und Cisco Legacy AnyConnect verfügbar. Diese Bedingung nicht auf andere Verbindungstypen übertragen.
• Bei Provider type transportiert App proxy den Verkehr im VPN-Tunnel auf Anwendungsebene, Packet tunnel auf Netzwerkebene. Für Cisco AnyConnect ist diese Einstellung nicht verfügbar. Welche Auswahl der Anbieter unterstützt und welchen Verkehr sie tatsächlich erfasst, am vorgesehenen Testgerät prüfen. Die Transportebene allein beweist weder App-Isolation noch eine geräteweite VPN-Wirkung.

Die Zuordnung einer vorhandenen Verbindung zur Fach-App gehört zum App-Verteilungsablauf im Abschnitt «Verwaltete Konfiguration und App-Verhalten prüfen». Dort ist Per-App-VPN zuweisen ausdrücklich auf vorhandene Geräterichtlinien begrenzt. Die Richtlinienverantwortlichen stellen die passende Verbindung bereit; die App-Verantwortlichen wählen sie in VPN connection used by the app aus. Dieser Verweis löst die oben beschriebene Unsicherheit bei Benutzerrichtlinien nicht auf und gibt keinen ungeprüften BYOD-Zuordnungsweg frei.

Vorab prüfen, im Pilot beobachten, Störungen eingrenzen

1. Inventar und Rückweg: Besitz, Enrollment, Supervision, iOS/iPadOS-Version, betroffene Richtlinie und Zuordnung notieren. Für ein beaufsichtigtes Firmen- und ein freiwilliges BYOD-Testgerät jeweils einen unabhängigen Netzweg (beispielsweise Mobilfunk oder anderes WLAN) und zuständige Kontaktperson festhalten. Ohne diesen Weg keine potentiell sperrende Änderung verteilen. Für Änderungen an iOS-Geräterichtlinien eine nur dem Firmen-Pilotgerät zugewiesene Testrichtlinie verwenden und vor dem Aktualisieren ihre aktuellen Zuweisungen und die Anzahl der Zielgeräte prüfen; keine bereits produktiv zugewiesene Richtlinie für den Pilot ändern.
2. Abhängigkeiten: Erreichbarkeit von DNS, APNs/MDM, CA/SCEP/RA, RADIUS/EAP-Server, PAC/WPAD und VPN-Endpunkt vor und nach der Änderung testen. Zertifikatskette, Servernamen, Ablaufzeit und geplanten Ersatz prüfen; private Schlüssel, Challenges und Zugangsdaten nicht in Tickets kopieren. Eine gültige Policy-Zuweisung allein ist kein Beweis für WLAN- oder VPN-Funktion.
3. Gezielter Pilot: Erst getrennte Testgeräte und minimale Zuweisung. Als Prüfkriterien, nicht als bestätigte Ergebnisse festhalten: Das Gerät akzeptiert die geprüfte RADIUS-Serveridentität und verbindet sich mit dem Enterprise-WLAN. Bei zertifikatsbasierter Anmeldung zusätzlich den Erhalt des Clientzertifikats und dessen Annahme durch RADIUS prüfen; bei einer Anmeldung mit Benutzername und Passwort den vorgesehenen Zugangsdatenweg prüfen. Bei Per-App-VPN den Tunnelverkehr der zugeordneten verwalteten Test-App prüfen; Zugriffe anderer Apps nur dann als Negativtest verwenden, wenn sie weder einer weiteren VPN-Zuordnung unterliegen noch eine konfigurierte Domänenregel treffen. Sind Domänen für Safari/andere Browser, Kalender, Kontakte oder Mail hinterlegt, auch die beabsichtigten Zugriffe auf passende Domänen prüfen und nicht pauschal «andere Zugriffe ohne Tunnel» erwarten. Safari-/Browser-Domänen gesondert prüfen: Für positive Tests mit Kalender, Kontakten und Mail verlangt Sophos zusätzlich, dass die Second-Level-Domain der eingetragenen Domäne mit der des VPN-Servers übereinstimmt; eine anderslautende Domäne ist kein gültiger Positivtest für den Tunnel und ihr Ausbleiben allein kein Nachweis einer fehlgeschlagenen VPN-Verteilung. Domänenregeln im eigenen Tenant prüfen, statt daraus ein ungeprüftes Konfigurationsrezept abzuleiten. Die Wirkung von Send all traffic through VPN im gewählten Anbieter-/Tunnelmodus gesondert am Testgerät prüfen; daraus keine ungeprüfte geräteweite Wirkung oder App-Isolation folgern. Bei User-Policy-Per-App-VPN die tatsächlich verfügbare App-Zuordnung nachweisen oder die Funktion vorerst ausklammern. Für PAC/WPAD den definierten Web-/Proxy-Ausfallpfad beobachten; nach jeder Änderung einen erneuten MDM-Check-in und die tatsächliche Netzfunktion getrennt bestätigen. Bleibt der Check-in aus oder fehlt der unabhängige Netzweg, Pilot stoppen und keine weiteren Geräte zuweisen.
4. Fehler eingrenzen: Bei fehlendem WLAN zuerst SSID und Sicherheitstyp, EAP-Servername und vertrauenswürdige CA prüfen; bei der Anmeldung mit Zugangsdaten Benutzername, Passwort und den vorgesehenen RADIUS-Anmeldeweg, bei zertifikatsbasierter Anmeldung ausgestellte Clientidentität und CA-Erreichbarkeit prüfen; bei Web-Ausfall PAC/WPAD/DNS und Proxy-Zugang; bei App-Ausfall Anbieter-App, Tunnel, Zertifikat und Zuordnung. Aufgabe/Check-in und tatsächliche Verbindung getrennt beobachten. Nicht durch unkontrolliertes Entfernen von Zertifikaten oder Profilen einen zweiten Ausfall auslösen.

Rücknahme ohne Geräte-Reset

Vor dem Pilot eine funktionierende Ersatzrichtlinie und Ersatz-Vertrauenskette mit erreichbarem Netz vorbereiten. Alte CA und Identitätszertifikate erst entfernen, wenn Ersatz am Zielgerät und MDM-Check-in bestätigt sind.

Bei iOS-Geräterichtlinien brauchen Änderungen laut Sophos Update devices: Das erzeugt einen Aktualisierungs-Task für alle Geräte, denen die bearbeitete Richtlinie zugewiesen ist, nicht nur für das Pilotgerät. Deshalb nur die isolierte Pilotrichtlinie nach Prüfung ihrer aktuellen Zielgeräte aktualisieren; eine gezielte Assign policy-Aufgabe an ausgewählte Geräte ist nicht dasselbe wie das Aktualisieren einer gemeinsam zugewiesenen Richtlinie. Der gezielte Task Uninstall policy ist für Device Enrollment vorgesehen, kann aber selbst den Netzweg entfernen. Für iOS-Benutzerrichtlinien auf Geräten mit User Enrollment gibt es nicht diesen Uninstall policy-Task: Sophos bietet stattdessen den gezielten Task Unassign iOS user policy. Auch Aktualisieren oder Zuweisen einer anderen Richtlinie kann je nach Fehlerfall sinnvoll sein. Den gezielten Task nicht mit Unassign für alle Geräte verwechseln.

iPadOS: direkte Aktionen und Task-Typen unterscheiden. Die Richtlinienanleitung erläutert die uneinheitliche Bezeichnung der direkten Aktualisierungs- und Deinstallationswege: Die Typenübersicht nennt iOS/iPadOS, die direkten Anleitungen nur iOS device policies. Deren Klickfolge deshalb nicht ungeprüft auf iPadOS übertragen; den verfügbaren direkten Weg im Tenant und am Pilotgerät klären. Das ist keine Aussage, dass iPadOS-Rücknahme generell undokumentiert oder unmöglich sei: Die iOS/iPadOS-Task-Typen dokumentieren Uninstall policy für Device Enrollment und Unassign iOS user policy für User Enrollment. Der modusabhängige Task-Bundle-Ablauf beschreibt diese Auswahl; Task-Übertragung und tatsächlichen Rücknahmeeffekt weiterhin getrennt prüfen.

Die Rücknahme getrennt an einem erreichbaren Firmen-Testgerät mit Device Enrollment und einem erreichbaren BYOD-Testgerät mit User Enrollment prüfen: auf dem Firmengerät die passende gezielte Uninstall policy-Aufgabe für genau dieses Gerät, auf dem BYOD-Gerät die gezielte Unassign iOS user policy-Aufgabe erproben. Je Gerät Task-/Check-in-Status und tatsächlich synchronisierten Richtlinienzustand bestätigen; danach WLAN-/VPN-Funktion und MDM-Kontakt unabhängig voneinander erneut testen. Weitere Zuweisungen oder Rücknahmen nur auf die tatsächlich geprüften Testgeräte begrenzen, bis beide Rückwege nachgewiesen sind. Ein gespeicherter oder versandter Task erreicht ein offline gesperrtes Gerät nicht automatisch. Dafür braucht es den zuvor geplanten unabhängigen Netzweg und lokalen Entstörungsweg; Unassign für alle Geräte ist keine risikoarme Sofortmassnahme. Weder vollständiges Löschen (Wipe) noch User-Unenrollment ist ein allgemeiner Policy-Rollback.