Sophos Mobile: Richtlinien für Apple User Enrollment einordnen

Zuerst den Verwaltungsmodus prüfen: Die iOS user policy in Sophos Mobile ist für iPhones und iPads mit Apple User Enrollment bestimmt. Diese Registrierung richtet sich an private Geräte (BYOD). Sie ist nicht der Verwaltungsmodus Apple Device Enrollment, bei dem Sophos Mobile das ganze Gerät verwaltet; ebenso wenig ist sie Automated Device Enrollment (ADE) über Apple Business. Dort automatisch registrierte iPhones und iPads sind betreut (supervised). Ein betreutes Gerät kann nicht per Apple User Enrollment registriert werden. Einstellungen aus einer iOS device policy oder einer ADE-Anleitung deshalb nicht ungeprüft auf eine Benutzerrichtlinie übertragen.

Was die Trennung tatsächlich bedeutet

Apple User Enrollment nutzt neben dem privaten Apple Account einen verwalteten Apple Account. Geschäftliche Daten liegen in einem verwalteten APFS-Volume; dazu gehören verwaltete Apps und App-Daten, ein verwalteter Schlüsselbund sowie Daten des verwalteten Apple Accounts. Beim Abmelden aus Sophos Mobile entfernt iOS dieses verwaltete Volume vom Gerät. Das ist nicht dasselbe wie die Zusage, dass ein Admin das gesamte private Gerät zurücksetzen oder persönliche Inhalte lesen kann. Sophos Mobile kann bei dieser Registrierungsart persönliche Daten sowie Gerätekennungen wie UDID, IMEI und MAC-Adresse nicht abfragen; wegen der fehlenden MAC-Adresse steht NAC für diese Geräte nicht zur Verfügung.

Vor dem Einsatz klären, ob das Gerät wirklich im User-Enrollment-Modus registriert ist und ob der Benutzer einen verwalteten Apple Account für die Registrierung hat. Die profilbasierte Variante ist laut Sophos nur bis iOS/iPadOS 17 verfügbar; neuere Rollouts nicht auf einen alten Profilablauf stützen. Die Apple-User-Enrollment-Anleitung führt durch Identitäten, Tenant-Vorbereitung und den passenden Registrierungsweg; dieser Artikel bleibt eine Entscheidungshilfe für die anschliessende Benutzerrichtlinie.

Diese MDM-Verwaltung benötigt Sophos Mobile Device Management oder die kombinierte Lizenz Sophos Mobile; Sophos Mobile Threat Defense allein deckt diesen Zweig nicht ab. Die tatsächliche Berechtigung im vorgesehenen Tenant vor der Zuweisung anhand der Mobile-Lizenzprüfung abgleichen.

Richtlinien nach Aufgabe auswählen

Gerätecode: Wenn die Konfiguration Password policies einem Gerät im Verwaltungsmodus Apple User Enrollment zugewiesen wird, verlangt Sophos für den Gerätecode eine sechsstellige PIN und untersagt PINs mit wiederholten oder aufeinanderfolgenden Ziffern (laut Sophos zum Beispiel 555555 und 987654). Das betrifft auch den privaten Gerätezugang. Sophos Mobile kann einen vergessenen Gerätecode nicht zurücksetzen. Erfüllt das Gerät bei Zuweisung dieser Konfiguration die Kennwortanforderungen nicht, beginnt laut Sophos eine 60-minütige Frist. Während dieser Frist fordert das Gerät bei jedem Öffnen des Home-Bildschirms zum Ändern des Gerätecodes auf. Nach Ablauf der Frist lassen sich unter Umständen keine Apps mehr starten, einschliesslich integrierter und persönlicher Apps. Diese Konfiguration nicht als harmlose Arbeitsbereichsregel behandeln und nicht ohne vorherige Benutzerkommunikation ausrollen.
Geschäftliche Konten: Email account fügt Exchange Online oder Exchange Server zu Apple Mail hinzu; dieses Konto ist verwaltet. IMAP/POP konfiguriert eingehenden und ausgehenden Mailserver separat. Google account fügt ein Google-Konto zur Mail-App hinzu; bei der Zuweisung muss der Benutzer seine Google-Zugangsdaten eingeben. CalDAV und CardDAV betreffen Kalender- beziehungsweise Kontaktesynchronisation. Server, Ports, Authentisierung und TLS müssen zum tatsächlichen Dienst passen; Beispiel-URLs sind keine universellen Sollwerte. Sowohl %_USERNAME_% als auch %_EMAILADDRESS_% kommen in Email account und IMAP/POP vor, je nach Feld mit unterschiedlicher Funktion. Für beide Konfigurationen müssen die Benutzerfelder Exchange Login und Email Address in Sophos Fusion gepflegt sein.
Exchange-Verbindung: In Email account ist User die Anmeldekennung, Email address dagegen die Adresse des Kontos. Für Exchange Online ist die Anmeldekennung normalerweise die E-Mail-Adresse; %_EMAILADDRESS_% übernimmt dafür Email Address des dem Gerät zugewiesenen Benutzers. Für Exchange Server nennt Sophos unter User %_USERNAME_%; die allgemeine Platzhalterhilfe ordnet diesen Wert Exchange Login desselben Benutzers zu. Unter Email address übernimmt %_EMAILADDRESS_% die Konto-Adresse aus Email Address. Weder der sichtbare Benutzername noch ein korrekt aussehender Platzhalter belegt eine passende Anmeldung. Zuerst Cloud und Authentisierung unterscheiden. Ohne OAuth nennt Sophos unter Server name für die weltweite Microsoft-365-Cloud outlook.office365.com. Diesen Host nicht auf andere Microsoft-365-Clouds übertragen; deren Endpunkte gesondert klären. Bei Exchange Server die Server-URL eintragen, bei Verwendung des Sophos Mobile EAS proxy stattdessen dessen URL. Domain bleibt für Exchange Online leer; bei Exchange Server gehört dort die Domäne des Benutzerkontos hinein. Turn on OAuth 2.0 sieht eine Anmeldung mit Microsoft-Zugangsdaten vor. Bei OAuth bleibt Server name laut Sophos leer, weil der Exchange-Host automatisch ermittelt wird. Die Ausnahme ist ein eingetragener OAuth authorization endpoint: Dann entfällt diese automatische Ermittlung und die Mailserver-URL muss in Server name stehen. Den Autorisierungs- und den OAuth token endpoint nur eintragen, wenn der Authentisierungsanbieter dies verlangt. Ein leeres Password bedeutet laut Sophos, dass der Benutzer das Passwort am Gerät eingeben muss. Es ist kein Ausweichweg zu Basic Authentication oder App-Passwörtern für Exchange Online EAS; Microsoft dokumentiert deren Wegfall. Die ausgewertete Microsoft-Dokumentation nennt zudem eine Einschränkung für die native iOS-Mail-App in Gallatin und empfiehlt dort Outlook mobile. Daraus folgt keine Freigabe für Apple Mail in allen Clouds.
Exchange-Transport und Zertifikate: SSL/TLS sichert laut Sophos die Verbindung zum Exchange-Server mit SSL oder TLS, abhängig von der Serverunterstützung; Sophos empfiehlt, die Checkbox zu aktivieren. Für den Einsatz eine nach den eigenen Sicherheitsvorgaben zulässige TLS-Verbindung und deren Zertifikatsvertrauen prüfen, nicht die Checkbox als Verbindungsnachweis werten. Identity certificate betrifft bei einer entsprechend vorgesehenen Authentisierung die Verbindungsidentität zum Exchange-Server. Davon getrennt ermöglicht Enable S/MIME verschlüsselte Nachrichten; Signing certificate und Encryption certificate dienen der Nachrichtensignatur beziehungsweise -verschlüsselung. Vor der Auswahl müssen die jeweils benötigten Zertifikate als PKCS #12 (.pfx) unter Client certificate > File > Upload a file in derselben Richtlinie hochgeladen sein. Andere Richtlinien benötigen einen erneuten Upload; automatische Wiederverwendung nicht voraussetzen. Diese Zertifikatszweige sind keine Pflicht für jedes Exchange-Konto. Allow user to send unencrypted emails lässt den Benutzer für jede ausgehende Nachricht wählen, ob er sie verschlüsselt; diese Wahl ist keine TLS-Einstellung.
Exchange-Synchronisation: Die fünf Optionen steuern unterschiedliche Kontodaten: Synchronize calendar → Calendar (Termine und Besprechungen), Synchronize contacts → Contacts, Synchronize mail → Mail, Synchronize notes → Notes und Synchronize tasks → Reminders (Aufgaben). Je Bereich gibt es eine separate Änderungsberechtigung: User can change calendar synchronization, User can change contacts synchronization, User can change mail synchronization, User can change notes synchronization beziehungsweise User can change tasks synchronization. Sie erlaubt dem Benutzer, die zugehörige Synchronisation ein- oder auszuschalten. Datenumfang und Änderungsrecht deshalb getrennt festlegen; das Aktivieren der Synchronisation ist nicht schon die Erlaubnis, sie am Gerät zu ändern.
Google-Konto: Google email address enthält die vollständige E-Mail-Adresse des Google-Kontos. User name ist hier der Name des Benutzers für ausgehende Nachrichten, nicht die Anmeldekennung eines Mailservers. Die Exchange-Login-Zuordnung aus anderen Konfigurationen nicht auf dieses Feld übertragen.
IMAP/POP-Verbindung: Account type wählt für eingehende Nachrichten IMAP oder POP. User display name ist der Anzeigename für ausgehende Nachrichten; die IMAP/POP-Hilfe nennt dafür %_USERNAME_% und beschreibt den Wert als Namen des dem Gerät zugewiesenen Benutzers. Die allgemeine Sophos-Platzhalterhilfe ordnet denselben Platzhalter dagegen ausdrücklich dem Benutzerfeld Exchange Login zu. Für %_EMAILADDRESS_% nennt sie Email Address; dieser Platzhalter gehört hier in Email address, die Adresse des Kontos. Damit ist die dokumentierte Feldzuordnung benannt, aber die unterschiedliche Beschreibung von %_USERNAME_% nicht als Produktverhalten aufgelöst. Nicht annehmen, dass der Platzhalter einen davon unabhängigen persönlichen Anzeigenamen liefert. Vor Verwendung prüfen, ob der gepflegte Exchange-Login-Wert als ausgehender Anzeigename geeignet ist. Für eingehenden und ausgehenden Mailserver jeweils User name als Verbindungskennung und Authentication type als Anmeldemethode festlegen; Password ist jeweils nur nötig, wenn der Server es verlangt. Mit Use same password as for incoming email kann das ausgehende Konto das eingehende Passwort übernehmen. Das setzt weder gleiche Benutzernamen noch gleiche Ports, Anmeldemethoden oder Transportoptionen voraus. Beide Richtungen haben eine eigene SSL/TLS-Option. Laut Sophos sichert sie die jeweilige Verbindung mit SSL oder TLS, abhängig von der Serverunterstützung. Für den Einsatz ist in beiden Richtungen eine nach den eigenen Sicherheitsvorgaben zulässige TLS-Verbindung nötig; die Optionen belegen weder Zertifikatsvertrauen noch erfolgreiche Anmeldung oder Mailübertragung.
S/MIME bei IMAP/POP: Wer Nachrichtenverschlüsselung benötigt, kann laut Sophos mit Enable S/MIME verschlüsselte Nachrichten senden und empfangen. Für Signing certificate und Encryption certificate müssen die Zertifikate vor der Auswahl in der Konfiguration Client certificate derselben Richtlinie hochgeladen sein. Allow user to send unencrypted emails lässt den Benutzer für jede ausgehende Nachricht wählen, ob er sie verschlüsselt. Diese optionale Nachrichtenverschlüsselung ist von SSL/TLS für den Transport getrennt; hier sind weder Zertifikatsvertrauen noch die Kompatibilität mit Empfängern geprüft.
CalDAV-Konto: In der Benutzerrichtlinie ist Account name der Anzeigename des Kontos auf dem Gerät, nicht die Anmeldekennung. Server bezeichnet den Hostnamen oder die IP-Adresse des CalDAV-Servers; User name und Password sind die Zugangsdaten für das CalDAV-Konto. Falls der Server es verlangt, trägt man unter Principal URL die Principal-URL der Kalenderressource ein. Sie bezeichnet die benötigte Kalenderressource und ist nicht mit dem Servernamen oder dem Anzeigenamen des Kontos gleichzusetzen. Die Option SSL/TLS sichert die Verbindung zum CalDAV-Server laut Sophos mit SSL oder TLS, abhängig davon, was der Server unterstützt. Sophos empfiehlt, diese Checkbox zu aktivieren. Für den Einsatz muss der Dienst eine nach den eigenen Sicherheitsvorgaben zulässige TLS-Verbindung unterstützen; die Checkbox allein bestätigt weder Zertifikatsvertrauen noch eine erfolgreiche Anmeldung oder Synchronisation.
CardDAV-Konto: Account name ist der Anzeigename auf dem Gerät; User name und Password sind die Zugangsdaten des CardDAV-Kontos. Server enthält den Hostnamen oder die IP-Adresse des CardDAV-Servers; der Port muss zu diesem Dienst passen. Falls der Server es verlangt, unter Principal URL die Principal-URL der Kontaktressource eintragen. Diese Ressourcenadresse ist nicht der Servername oder der Anzeigename des Kontos. Laut Sophos sichert SSL/TLS die Verbindung mit SSL oder TLS, abhängig von der Serverunterstützung; Sophos empfiehlt, die Checkbox zu aktivieren. Für den Einsatz muss der Dienst eine nach den eigenen Sicherheitsvorgaben zulässige TLS-Verbindung unterstützen. Die Checkbox allein belegt weder Zertifikatsvertrauen noch erfolgreiche Anmeldung oder Kontaktesynchronisation.
Mail-Datenfluss: Ein verwaltetes Mail-Konto allein und das verwaltete APFS-Volume garantieren keine vollständige Isolation. Bei Email account und IMAP/POP gesondert prüfen, ob Allow move das Verschieben von Nachrichten in andere Konten oder Antworten/Weiterleiten über ein anderes Konto ermöglicht, ob Allow recent address syncing zuletzt verwendete Adressen über iCloud auf andere Geräte synchronisiert und ob Use in Mail only die Verwendung als sendendes Konto aus anderen Apps beschränkt. Bei IMAP/POP zusätzlich Allow Mail Drop als eigenen Datenfluss prüfen. Keine dieser Optionen allein als belegte DLP-Garantie behandeln.
Datenfluss: Restrictions enthält getrennte Dokumentregeln für die Richtung verwaltet → nicht verwaltet und nicht verwaltet → verwaltet, für das Lesen verwalteter Kontakte durch nicht verwaltete Apps sowie für Zwischenablage und iCloud-Synchronisierung. Für die dokumentierte Trennung verwalteter Mail-Anhänge sind ein verwaltetes Konto und verwaltete Apps nötig. Wird die Regel für Dokumente innerhalb verwalteter Apps/Konten ausgeschaltet, sind die beiden folgenden Optionen (Kontaktfreigabe und Dokumentregel für nicht verwaltete Apps/Konten) deaktiviert. Kontakte aus verwalteten Konten können dann laut Sophos mit nicht verwalteten Apps geteilt werden. Mit Force AirDrop documents to be used as unmanaged documents wird AirDrop laut Sophos als nicht verwaltetes Ziel behandelt; die Option ist keine pauschale AirDrop-Sperre. Sind beide Dokumentregeln aus, hat die Zwischenablage-Beschränkung keine Wirkung. Gewünschte Richtung, Kontaktfreigabe, iCloud-Synchronisierung und beobachtbaren Datenfluss am Testgerät getrennt prüfen; keine pauschale Datenisolationszusage.
Gerätefunktionen und Privatsphäre: Restrictions > Device enthält auch Entscheidungen, die die Nutzung des privaten Geräts betreffen. Allow screen capture erlaubt Screenshots des Bildschirms; diese Fähigkeit ist von den Dokumentfreigaberegeln getrennt und keine DLP-Garantie. Wird Allow Siri ausgeschaltet, sind laut Sophos Siri, Sprachbefehle und Diktieren nicht nutzbar. Wird nur Allow Siri while device is locked ausgeschaltet, muss der Benutzer das Gerät vor der Siri-Nutzung durch Eingabe seines Passworts entsperren. Force local translation verhindert für Übersetzungen die Verbindung zu Siri-Servern, nicht pauschal jede Datenübermittlung. Force Wrist Detection verlangt die Handgelenkerkennung auf einer gekoppelten Apple Watch. Force pairing password for outgoing AirPlay requests verlangt ein Kopplungspasswort auf den anderen Geräten, die eine AirPlay-Anfrage von diesem Gerät empfangen; es ist keine generelle AirPlay-Sperre.
Sperrbildschirm und Safari: Mit Allow Control Center on lock screen, Allow Notification Center on lock screen und Allow Today view on lock screen entscheidet man getrennt über Kontrollzentrum, Mitteilungszentrale und Heute-Ansicht bei gesperrtem Bildschirm. Ist die jeweilige Checkbox ausgeschaltet, ist der betreffende Bereich laut Sophos im gesperrten Zustand nicht verfügbar. Unter Restrictions > Applications hält Force fraud warning die Safari-Sicherheitseinstellung für Warnungen beim Besuch einer mutmasslichen Phishing-Webseite dauerhaft eingeschaltet; das ist eine Warnvorgabe, keine Garantie, dass Phishing-Seiten blockiert werden. Diese Geräte- und Browserentscheidungen vor einer Zuweisung mit dem Benutzer abstimmen und ihre gewünschte Wirkung im freigegebenen Pilot prüfen; weder Defaults noch eine hier getestete Wirkung sind damit zugesagt.
Diagnosedaten und Backups: Unter Restrictions steuert Allow diagnostic data to be sent to Apple die Übermittlung von Diagnoseinformationen an Apple. Ist die Checkbox ausgeschaltet, werden diese Informationen laut Sophos nicht an Apple gesendet. Force encrypted backups verlangt laut Sophos, dass Benutzer ihre Backups in iTunes verschlüsseln. Diese dokumentierte Vorgabe nicht auf sämtliche Backup-Verfahren oder iCloud-Backups ausweiten; sie ersetzt auch kein Backup-/Aufbewahrungskonzept. Die Diagnoseoption ist keine Zusage, dass jede andere Datenübermittlung unterbunden wird.
Kerberos-SSO: Single sign-on beschreibt Kerberos-SSO für Drittanbieter-Apps; die dokumentierte Konfiguration gilt nur bis iOS 26 beziehungsweise iPadOS 26. Kerberos principal name enthält den Principal-Namen; bleibt das Feld leer, muss ihn der Benutzer laut Sophos eingeben. Den Kerberos-Realm unter Realm in Grossbuchstaben eintragen. Die Liste URLs enthält die URL-Präfixe, die für die Kerberos-Authentisierung über HTTP übereinstimmen müssen. Einträge müssen mit http:// oder https:// beginnen; fehlt am Ende ein /, ergänzt Sophos Mobile ihn. Für das URL-Matching ist ein einzelner Stern (*) als Platzhalter für beliebige Werte zulässig. App IDs enthält die Bundle-IDs der Apps: entweder als exakte Werte oder als Präfixe mit .* am Ende. Diese Regeln bestimmen den Zielbereich der Konfiguration; wie URL- und App-ID-Abgleich miteinander verknüpft sind, beschreibt die Quelle nicht. Sie belegen keine erfolgreiche Anmeldung am Gerät.
Drucker: AirPrint fügt Drucker zur Druckerliste hinzu. IP-Adresse und Ressourcenpfad müssen zum Druckdienst passen; Port bezeichnet den Port, an dem der AirPrint-Drucker Verbindungen annimmt. Mit Force TLS werden AirPrint-Verbindungen laut Sophos durch TLS gesichert. Portwert und TLS-Unterstützung müssen zum jeweiligen Druckdienst passen; daraus folgt weder ein Standardport noch eine Zusage für Zertifikatsvertrauen oder erfolgreiches Drucken.
Web Clip: Web Clip legt einen Schnellzugriff auf dem Home-Bildschirm an. Unter URL darf laut Sophos nur bei einem reinen Domainnamen das Präfix https:// fehlen. In allen anderen Fällen ist die vollständige URL nötig, etwa bei einem Pfad, einer Portangabe oder einem eigenen URL-Schema. Full screen öffnet die URL laut Sophos als Web-App im Vollbild, nicht als installierte native App. Show external pages in full-screen bestimmt, ob beim Wechsel zu anderen Webseiten das Vollbild erhalten bleibt; ist die Checkbox ausgeschaltet, erscheint der Browser. Unter Browser app stehen die auf den verwalteten iPhones und iPads installierten Apps zur Auswahl. Device default verwendet den auf dem Gerät eingestellten Standardbrowser. Ist die ausgewählte App auf einem Gerät nicht verfügbar oder kann sie keine Webseiten öffnen, wird der Web Clip laut Sophos in Safari geöffnet. Die Auswahl garantiert deshalb weder einen bestimmten Browser noch einen Kioskmodus oder die Erreichbarkeit des Ziels. Ein nicht entfernbarer Web Clip kann laut Sophos erst durch Entfernen der installierenden Richtlinie verschwinden; daher diese Option nicht ohne Rückweg planen.

Verwaltete Apps und Per-App-VPN: keine Kurzschlüsse

Eine verwaltete App ist nicht einfach jede App auf dem privaten Gerät. Für User Enrollment beschreibt Sophos nur Apps, die über Apple Business erworben wurden: Die Verteilung erfolgt über Sophos Mobile oder über eine Zuweisung zum verwalteten Apple Account. Ist dieselbe App bereits privat installiert, lässt sie sich nicht zusätzlich als verwaltete App installieren. Eine vom Benutzer entfernte verwaltete App bleibt bei einer erneuten Installation verwaltet. Mail, Notes und Calendar können dagegen Daten sowohl des privaten als auch des verwalteten Accounts halten; ihre Daten nicht allein aus dem App-Namen klassifizieren.

Apple erlaubt die AppLayerVPN-Payload bei User Enrollment; diese Plattformfreigabe belegt nicht, dass Sophos Mobile eine Verbindung aus einer Benutzerrichtlinie einer App zuweisen kann. Sophos führt VPN pro App (englische Hilfe: Per app VPN) als Konfiguration einer iOS-Benutzerrichtlinie auf und verlinkt von dort eine Anleitung zur App-Zuweisung. Diese nennt jedoch als Voraussetzung eine oder mehrere Geräterichtlinien mit VPN pro App und beschreibt die auswählbaren Verbindungen ausschliesslich als Konfigurationen aus Geräterichtlinien; zugleich verlinkt sie zurück auf die iOS-Benutzerrichtlinie. Zwischen der Benutzerrichtlinien-Seite und der auf Geräterichtlinien beschränkten Zuweisungsbeschreibung besteht damit eine ungeklärte Spannung in der Dokumentation, kein Nachweis für widersprüchliches Produktverhalten. Ob eine Verbindung aus einer Benutzerrichtlinie im App-VPN-Selektor bei Apple User Enrollment tatsächlich verfügbar ist, bleibt ungeklärt. Dieser Entwurf enthält deshalb weder die Aufforderung, eine solche Verbindung einer App zuzuweisen, noch eine Klickfolge oder eine VPN-Wirkungszusage; für privat installierte Apps ist daraus ebenfalls keine VPN-Zuweisung abzuleiten. Eine spätere Betriebsanweisung setzt die unabhängige Bestätigung im freigegebenen User-Enrollment-Tenant voraus: passend lizenzierte verwaltete App, Verfügbarkeit der Benutzerrichtlinien-Konfiguration im Selektor, On-Demand-Verhalten, tatsächlicher appbezogener Datenweg und Entfernung der Zuordnung. Das Feld Alle Daten über VPN übertragen (englische Hilfe: Send all traffic through VPN) im Per-App-Profil belegt keine geräteweite VPN-Führung.

Konten für einen begrenzten Pilot vorbereiten

Für Email account und IMAP/POP zuerst den tatsächlich dem Gerät zugewiesenen Benutzer prüfen. In Sophos Fusion unter My Environment > Users & Groups > Users die richtige Person öffnen und über Edit die Felder Exchange Login und Email Address prüfen beziehungsweise pflegen, dann Save wählen. Aus Active Directory importierte Kontodetails lassen sich dort nicht ändern. In diesem Fall die Werte mit der zuständigen Verzeichnisadministration klären, statt ein zweites Benutzerobjekt anzulegen. Diese dokumentierte AD-Einschränkung nicht pauschal auf alle Entra-ID-Identitäten übertragen. Bei IMAP/POP zusätzlich prüfen, ob der Exchange-Login-Wert als ausgehender Anzeigename geeignet ist; die unterschiedliche Platzhalterbeschreibung oben bleibt ungeklärt.

Die Richtlinienerstellung und gezielte Zuweisung beschreiben den gemeinsamen Ablauf. Dabei ausdrücklich eine iOS & iPadOS user policy wählen, die benötigten Konfigurationen bearbeiten und speichern. Für einen gesondert autorisierten Pilot eine isolierte Richtlinie und nur die freigegebenen Geräte verwenden. Vor jeder Änderung die bisherigen Einstellungen und sämtliche Zuweisungen dieser Richtlinie festhalten: Eine gemeinsam zugewiesene Richtlinie ist kein Einzelgeräte-Test. Benutzerrichtlinien synchronisieren bei jeder Verbindung mit Sophos Mobile automatisch; weder Update devices noch der Terminbildschirm der direkten Geräterichtlinienzuweisung ist dafür zu übernehmen.

Die folgenden Kontrollen sind geplante Abnahmekriterien, keine hier beobachteten Geräteergebnisse. Nur freigegebene Testkonten und Testdaten ohne Kundendaten einsetzen; den gewünschten Datenumfang vor der Zuweisung festlegen.

Exchange und IMAP/POP: Am richtigen Konto die tatsächlich aufgelöste Konto-Adresse, Anmeldekennung und bei IMAP/POP den ausgehenden Anzeigenamen mit dem Plan vergleichen. Anmeldung, zulässige TLS-Verbindung und Zertifikatsvertrauen gesondert bestätigen. Den Empfang einer Testnachricht und ihre ausgehende Zustellung getrennt prüfen, statt nur die Kontoanzeige als Erfolg zu werten. Bei Exchange die gewählten Synchronisationsbereiche in den zugehörigen Apps und die separat erlaubten Benutzeränderungen prüfen. Gewünschte erlaubte und gesperrte Mail-Datenflüsse mit Testdaten beobachten. Nur bei vorgesehenem Zertifikatseinsatz zusätzlich Verbindungsidentität beziehungsweise S/MIME-Signatur, Verschlüsselung und Empfängerkompatibilität prüfen.
CardDAV: Das angelegte Konto und die vorgesehene Kontaktressource abgleichen. Einen eindeutig erkennbaren Testkontakt aus der freigegebenen Serverressource auf dem Gerät erwarten und dessen Inhalt vergleichen. Eine Gegenrichtung nur prüfen, wenn sie für den konkreten Dienst vorgesehen und freigegeben ist; keine universelle Schreib- oder bidirektionale Synchronisationszusage. Fehlt der Kontakt oder erscheint er im falschen Konto, zuerst Konto-/Ressourcenzuordnung, Server und Port, danach Zugangsdaten und eine gegebenenfalls erforderliche Principal URL prüfen. Bei Verbindungs- oder Vertrauensfehlern zusätzlich TLS-Unterstützung und Zertifikatsvertrauen klären; nicht zur Diagnose die Transportabsicherung abschalten.

Bei falscher Identität, Authentisierungs-, Transport- oder Datenflussabweichungen die Ausweitung stoppen und mit Dienst- beziehungsweise Mobile-Verantwortlichen klären. Ein Status wie Applied, eine neue Richtlinienversion oder ein aktueller Verbindungstermin ersetzt keine dieser Kontoprüfungen.

Änderungen und Rücknahme nach Verwaltungsmodus planen

Für eine Korrektur nennt die allgemeine Policy-Hilfe bei Benutzerrichtlinien das Bearbeiten der Richtlinie oder die Zuweisung einer anderen. Bei einer geplanten Wiederherstellung die dokumentierten vorherigen Payload-Einstellungen verwenden und nach der nächsten Verbindung und Synchronisation Konto- und Datenzustand erneut beobachten. Das ist kein belegter verlustfreier Rückweg.

Die direkte Aktion Devices > [Gerät] > Policies > Uninstall ist laut Deinstallationsanleitung auf bestimmte Geräterichtlinien beschränkt, nicht für die iOS user policy vorgesehen. Das bedeutet nicht, dass es keine unterstützte Rücknahmeaufgabe gibt: Für User Enrollment dokumentiert Sophos im Aufgabenpaket-Ablauf ausdrücklich Unassign iOS user policy. Dort unter Select source > Policies die geprüfte Benutzerrichtlinie auswählen und das Paket nur an die freigegebenen Zielgeräte übertragen. Uninstall policy gehört bei iOS/iPadOS zum Device-Enrollment-Modus; das breite Unassign der allgemeinen Deinstallationsanleitung betrifft alle Geräte mit der betreffenden Zuweisung und ist kein gezielter Pilot-Rückweg.

Vor einer solchen Aufgabe richtige Richtlinie, Zielgeräte und vorhandene Konten/Kontakte festhalten sowie benötigte Arbeitsdaten über den genehmigten Weg sichern. Danach Aufgaben-/Synchronisationsstand und den tatsächlichen Konto-, Kontakt- und Datenzustand vergleichen; den vorgesehenen Erhalt benötigter Daten gesondert prüfen. Bei Abweichung stoppen und eskalieren, nicht durch Unenroll, Wipe oder Gruppenlöschung nachhelfen. Ein erfolgreicher Auftrag allein bestätigt weder vollständige Payload-Entfernung noch Datenbewahrung.

Vor einer Freigabe offen

Vor einem produktiven Rollout fehlen eine Einwilligung der betroffenen Person, ein abgestimmtes Backup-/Aufbewahrungskonzept und ein Test mit einem dafür freigegebenen Gerät: Registrierungsmodus, OS-Version, Edition/Lizenz, App-Lizenz und -Verwaltungsstatus, Konten und vorhandene Daten erfassen. Für einen vergessenen Gerätecode einen Eskalationsweg statt eines nicht verfügbaren Sophos-Resets vereinbaren; nach Ablauf der dokumentierten 60-Minuten-Frist können auch private Apps blockiert sein. Dokument- und Mail-Datenflüsse sowie VPN-Verkehr nur anhand beobachtbarer Ergebnisse freigeben.

Die Rücknahme ist payloadweise zu testen, nicht aus dem Entfernen einer Richtlinienzuweisung abzuleiten: Konten und App-Status nach Policy-Entzug prüfen; für einen nicht entfernbaren Web Clip die installierende Richtlinie einbeziehen; bei verwalteten Apps auch Deinstallation beziehungsweise Lizenzentzug und den Zustand einer erneut installierten App prüfen. Vorab festlegen, welche Geschäftsdaten erhalten bleiben müssen und wie sie ausserhalb des Geräts gesichert werden. Eine Abmeldung entfernt das verwaltete APFS-Volume samt dort liegenden Geschäftsdaten; sie ist kein verlustfreier Rollback, auch wenn persönliche Gerätedaten dadurch nicht pauschal gelöscht werden. Hier wurden weder Tenant noch iPhone/iPad getestet, keine Reihenfolge der Rücknahme praktisch bestätigt und keine Payload-Wirkung technisch abgenommen. Eine dokumentarische Freigabe dieses Artikels ist von der technischen Abnahme eines produktiven Rollouts zu trennen; sie bestätigt keine Wirkung im Tenant oder auf dem Gerät. Insbesondere Codezwang, Dokumentfreigaben und VPN-Zuweisung nicht ohne diese technische Abnahme als produktive Anleitung verwenden.