Sophos Mobile: macOS-Konnektivität per Geräte- oder Benutzerrichtlinie verwalten

Dieser Artikel behandelt Sophos-Mobile-Richtlinien auf verwalteten Macs, nicht die allgemeine Einrichtung von Apple-WLAN/VPN und nicht Sophos Endpoint, ZTNA oder die Konfiguration einer Sophos Firewall. Für Clientinstallation und Firewall-Remote-Access statt Mobile-Policy siehe Sophos Connect auf macOS. Geräte- und Benutzerkontext sind getrennt: dieselben Konfigurationsnamen bedeuten nicht, dass Identität, Zertifikatszugriff und Zeitpunkt der Anwendung austauschbar sind. Eine Profilzuweisung allein beweist keine funktionierende Verbindung.

Voraussetzungen: erst Managementweg und Rückweg sichern

• Erforderliche MDM-Lizenz: Für die Verwaltung von Macs ist Sophos Mobile Device Management erforderlich, entweder als eigenständige Lizenz oder enthalten in der gebündelten Lizenz Sophos Mobile. Sophos Mobile Threat Defense allein reicht nicht aus: Diese Lizenz deckt die Verwaltung von Sophos Intercept X for Mobile und Sophos Chrome Security ab, nicht das Mac-MDM. Vor der Richtlinienerstellung die entsprechende MDM-Berechtigung im Tenant prüfen.
• Prüfen, dass der Mac in Sophos Mobile registriert ist, welche macOS-Version und welche Richtlinien bereits zugewiesen sind und ob für die benötigte Funktion ein Gerät oder ein bestimmter Benutzer verwaltet werden soll. Macs haben in Sophos Mobile nur einen Managementmodus, aber Geräte-, deklarative und Benutzerrichtlinien. Apple User Enrollment für private iPhones/iPads ist kein macOS-Enrollment-Modus. Bei manueller Mac-Registrierung muss der zu verwaltende Benutzer die Registrierung durchführen und für das Registrierungsprofil ein Administratorpasswort eingeben; bei automatischer Registrierung über Apple Business unter Assign user to device prüfen, ob No (keine Benutzerzuordnung bei der Registrierung) oder Yes - LDAPS authentication gewählt ist. Die Benutzerzuordnung nicht aus der Geräte-Policy ableiten.
• Geräte-Richtlinien gelten für alle Benutzer des Macs. Benutzer-Richtlinien gelten für den lokal registrierenden Benutzer sowie für von Sophos Mobile bekannte Netzwerkbenutzer aus dem externen LDAP-Verzeichnis des Self Service Portal. Wird in der Geräte-Richtlinie ein Mac mit derselben AD-Domäne wie das Self Service Portal verbunden, wird die Benutzer-Richtlinie auf alle dort anmeldenden AD-Benutzer angewandt. Das vor einer breiten Zuweisung mit den vorgesehenen Konten prüfen.
• Zusätzlich zur Enrollment-Geräterichtlinie kann einem Mac eine weitere Geräte-, eine deklarative und eine Benutzerrichtlinie zugewiesen werden. Vor jeder Payload-Änderung Ziel-Macs, betroffene Benutzer und Gruppen sowie sämtliche Zuweisungen der bestehenden Richtlinie erfassen: eine bereits über den Pilot hinaus zugewiesene Richtlinie niemals für den Pilot ändern. Vorhandene Wi-Fi-, VPN-, Proxy- und Zertifikatspayloads samt Besitzer dokumentieren; widersprüchliche Einstellungen werden grundsätzlich nach dem restriktiveren Wert behandelt, mit Sondervorrang deklarativer Softwareupdate-/App-Konfiguration. Bestehende Profile nicht durch unkontrollierte zusätzliche Zuweisungen überlagern.
• Vorabprüfung nur für macOS 26 mit Benutzerrichtlinie: Beim Status Failed to apply the policy frühere zugewiesene Restrictions-Konfigurationen und deren Verlauf als mögliche Ursache prüfen: Der überholte Schlüssel Allow Time Machine kann in einer älteren zugewiesenen Richtlinie fortbestehen, obwohl er in den Konfigurationsoptionen nicht mehr sichtbar ist. Nicht verlangen, ihn in der aktuellen Oberfläche zu finden. Bei entsprechendem Verdacht Pilot und Bewertung der WLAN-/VPN-/Zertifikatspayloads dieser Benutzerrichtlinie stoppen: Laut Sophos kann dann die gesamte Benutzerrichtlinie nicht angewandt werden, nicht nur die Einschränkung. Die kontrollierte Bereinigung und erneute Prüfung mit den Verantwortlichen für macOS-Sicherheits- und Datenschutzrichtlinien abstimmen; keine gemeinsam genutzte Produktionsrichtlinie stillschweigend ändern. Das ist kein genereller Fehler aller macOS-26-Macs oder der Geräterichtlinien.
• Einen unabhängigen Zugang zum Pilot-Mac bereithalten (zum Beispiel funktionierendes alternatives Netz und lokalen Administrationszugang). SSID, RADIUS-/VPN-Endpunkt, DNS, PKI-Vertrauenskette, Zertifikatsablauf, PAC-/Proxy-Erreichbarkeit und gegebenenfalls Drittanbieter-VPN-App vorab mit den jeweiligen Betreibern klären. Zugangskennwörter und .pfx-Dateien nicht in Tickets oder öffentliche Ablagen übernehmen. Produkt-/Lizenz-/OS-Freigaben für die konkrete Umgebung im Tenant prüfen; die Konfigurationsseiten nennen keine universelle Freigabe für jede macOS-Version.

Auswahl: welche Richtlinie und welche Abhängigkeit?

Bei manuell eingerichtetem Global HTTP proxy mit Zugangsdaten gehört der Proxy-Benutzername in Authentication, das zugehörige Proxy-Kennwort in Password. Authentication ist hier ein Benutzernamenfeld, keine Auswahl des Authentifizierungsverfahrens. Ob Zugangsdaten benötigt werden, mit dem Proxy-Betreiber klären; die Kennwörter nicht in Tickets oder öffentliche Ablagen übernehmen.

Wi-Fi: Netz und Authentisierung festlegen

Die folgenden Feldbeschreibungen geben die dokumentierten Sophos-Einstellungen wieder, keinen am Mac getesteten Verbindungserfolg. Connect automatically verbindet den Mac automatisch, wenn das WLAN verfügbar ist. Hidden network kennzeichnet ein Netz, das seine SSID nicht aussendet. Die Auswahl muss zum Zielnetz passen; eine versteckte SSID ist keine Sicherheitsfreigabe.

Security type legt das Sicherheitsverfahren und die Variante Personal oder Enterprise fest. Beides mit dem WLAN-Betreiber abstimmen. Bei Personal gehört das WLAN-Kennwort in Password. Bei Enterprise stehen Protocols für die Authentifizierungsprotokolle und Authentication für die Client-Authentisierung zur Verfügung:

• Unter Protocols > Accepted EAP types die EAP-Typen festlegen, die der Mac zur Authentisierung akzeptiert, passend zum RADIUS-Dienst. Für EAP-FAST lässt sich eine Protected Access Credential (PAC) konfigurieren. Diese PAC ist keine Proxy-Auto-Config-Datei. Bei TTLS wählt Internal identity das Protokoll für die Benutzer-Authentisierung innerhalb des Tunnels, nicht den Benutzernamen.
• Falls das gewählte Enterprise-Verfahren Benutzername und Kennwort verwendet, unter Authentication > User den WLAN-Benutzernamen und unter Password das WLAN-Kennwort eintragen. Die Richtlinienzuordnung zu einem Benutzer ersetzt diese Angaben nicht. Require password on each connect bedeutet laut Sophos, dass das Kennwort bei jeder Authentisierung gesendet wird. Daraus weder eine Kennwortabfrage noch eine bestimmte Speicherung oder Klartextübertragung des Kennworts ableiten. Zertifikatsbasierte Verfahren nicht pauschal um ein Kennwort ergänzen.

Outer identity ist eine Platzhalteridentität, mit der EAP die Authentisierung startet, ohne die eigentlichen Benutzer-Zugangsdaten offenzulegen. Sie wird im Klartext übertragen. Deshalb weder den tatsächlichen Benutzernamen noch sensible Angaben verwenden. Benötigt der RADIUS-Dienst eine Realm-basierte Weiterleitung, muss die Platzhalteridentität den mit dem Betreiber vereinbarten Realm enthalten. Ohne diese Weiterleitung kann eine einfache Identität wie anonymous genügen. Die unten genannten EAP- und TLS-1.3-Bedingungen bleiben dabei massgebend.

Wichtig bei Wi-Fi Enterprise: Für Identity certificate verlangt Sophos Mobile zuvor eine Client certificate-Konfiguration in derselben Policy; für Trusted certificates zuvor eine Root certificate-Konfiguration. Das Wi-Fi-Payload hat zudem ein eigenes Feld Proxy für manuelle Einstellungen oder PAC; es ist nicht mit Global HTTP proxy identisch. Das Client-Zertifikat ist auch anderen Konfigurationen derselben Policy zugänglich, nicht anderen Policies; dort erneut hochladen. Apple beschreibt auf Plattformebene, dass eine SCEP-Identität einem Dienst im selben Konfigurationsprofil zugeordnet werden kann; das konkrete Wi-Fi-EAP-TLS-Beispiel von Apple verwendet allerdings ein AD-Zertifikat. Das belegt nicht, dass Sophos Mobile eine SCEP-Identität in seinem Wi-Fi-Feld Identity certificate anbietet oder eine entsprechende Verknüpfung ausliefert: Die Sophos-Wi-Fi-Hilfe nennt stattdessen die Client-certificate-Konfiguration als Voraussetzung. Keine SCEP-Abhängigkeit für Erstzuweisung oder produktives WLAN planen. Eine solche Variante nur nach Nachweis der tatsächlichen Bindung im eigenen Tenant, auf dem verwalteten Pilot-Mac und durch erfolgreiche EAP-/RADIUS-Anmeldung als Betriebsweg erwägen; wenn weder Auswahl noch ausgelieferte Bindung nachweisbar ist, diesen Weg stoppen. Bei EAP-TTLS/PEAP/EAP-FAST die Outer identity ohne sensible Benutzerdaten setzen; bei TLS 1.3 ist sie laut Sophos erforderlich. TLS-Minimum und -Maximum nur gemeinsam setzen oder beide leer lassen.

VPN: Anbieter, Authentisierung und Proxy abstimmen

Connection name ist der Verbindungsname, den der Benutzer auf dem Mac sieht, nicht der Richtlinienname. Die Sophos-Feldliste nennt unter Connection type die Optionen Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point und Custom SSL/TLS. Custom SSL/TLS ist für Anbieter vorgesehen, deren App im App Store die VPN-Verbindung bereitstellt. Diese Liste ist keine Freigabe jeder Anbieter-/macOS-Kombination. Die benötigte App muss bereits installiert sein; ihren tatsächlichen Reverse-DNS-Identifier mit dem Anbieter klären.

Die folgenden Optionen nur verwenden, soweit der gewählte Verbindungstyp und Anbieter sie anbieten und benötigen. Gibt der Anbieter eigene Verbindungseigenschaften vor, unter Third-party settings mit Add jeweils Key und Value eintragen. Keine Eigenschaften aus einem anderen VPN übernehmen. Group ist eine allenfalls benötigte Gruppe für die VPN-Authentisierung, keine Gerätegruppe für die Richtlinienzuweisung.

Benutzer- und Geräte-Authentisierung getrennt mit dem VPN-Betreiber festlegen:

• Unter User authentication zwischen Password und Certificate wählen. Das zugehörige Feld Password enthält das VPN-Kennwort, Certificate das Zertifikat für die VPN-Benutzer-Authentisierung.
• Bei Device authentication = Keys (Shared Secret)/Group name erscheinen Group name, Keys (Shared Secret), Use hybrid authentication und Request password. Die vom Betreiber vorgegebenen Authentisierungsangaben in Group name und Keys (Shared Secret) eintragen. Use hybrid authentication und Request password nur nach dessen Anforderungen wählen, nicht als pauschalen Verbindungsfix.
• Bei Device authentication = Certificate erscheinen Certificate und Including user PIN. Das benötigte Gerätezertifikat aus der Liste Certificate auswählen. Including user PIN bezieht die Benutzer-PIN in die Geräte-Authentisierung ein. Die Quelle legt weder Abfragezeitpunkt noch Speicherung der PIN fest.

VPN-Kennwörter und Shared Secrets wie die übrigen Zugangsdaten schützen. Die Zertifikatsfelder belegen weiterhin keinen SCEP-Verknüpfungsweg; die tatsächliche Identität und Authentisierung sind im vorgesehenen Benutzer-/Gerätekontext zu prüfen.

Unter dem VPN-eigenen Proxy bedeutet No proxy, dass für diese Verbindung kein Proxy eingerichtet wird. Bei Manually erscheinen Server and port, Authentication und Password. Dort Proxy-Adresse und Port sowie, falls benötigt, Proxy-Benutzername und Proxy-Kennwort eintragen. Authentication ist auch hier das Benutzernamenfeld. Bei Automatic erscheint Proxy server URL für die URL des Servers mit den Proxy-Einstellungen. Das ist eine Einstellung dieser VPN-Verbindung, keine Änderung an Global HTTP proxy.

Provider type unterscheidet App proxy, einen VPN-Tunnel auf Anwendungsebene, von Packet tunnel, einem VPN-Tunnel auf Netzwerkebene. Die passende Option mit dem Anbieter abstimmen. Daraus keinen Split- oder Volltunnel ableiten; dafür bleiben die Verkehrsplanung und die DNS-/Routenprüfung im Pilot erforderlich.

SCEP: Endpunkte, Identität und Schlüssel prüfen

Unter URL steht die Webadresse des CA-Servers. %_SCEPPROXYURL_% verweist auf die Server-URL im Register SCEP der Seite Sophos setup. Challenge ist die Webadresse, über die ein Challenge-Kennwort vom SCEP-Server bezogen wird, nicht das Kennwort selbst. %_CACHALLENGE_% verweist auf die Challenge-URL im selben Register. CA name muss ein Name sein, den die CA versteht; er kann beispielsweise verschiedene CA-Instanzen unterscheiden. Den passenden Wert mit der PKI abstimmen, keinen universellen Namen oder eine Pflicht zur Eingabe voraussetzen.

Für einen zusätzlichen Subject Alternative Name zuerst unter Type of Subject Alternative Name den Typ wählen und danach unter Value of Subject Alternative Name den Wert eintragen. Sophos beschreibt RFC 822 name als gültige E-Mail-Adresse, DNS name als DNS-Namen des CA-Servers und Uniform resource identifier als vollständig qualifizierte URL des CA-Servers. Diese CA-Server-Beschreibungen nicht stillschweigend durch allgemeine SAN-Annahmen ersetzen. Typ und Wert mit der PKI für den vorgesehenen Zertifikatszweck klären; sie beweisen keine Wi-Fi-/VPN-Identitätsbindung. Falls eine AD-Benutzeridentität verwendet wird, bezeichnet AD user logon name den in AD hinterlegten User logon name, also den User Principal Name (UPN). SAN und AD-Angaben sind keine pauschale Voraussetzung jedes Mac-Zertifikats.

Retries legt die Anzahl Wiederholungen fest, wenn der SCEP-Server mit pending antwortet. Retry delay ist der Abstand zwischen diesen Wiederholungen in Sekunden. Das ist kein Erneuerungsintervall und keine Zusage, dass die Ausstellung nach dieser Wartezeit gelingt. 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. Auch die SCEP-Konfiguration hat Allow export from keychain. Damit können Benutzer den privaten Schlüssel des Zertifikats aus dem Schlüsselbund exportieren. Wie beim hochgeladenen Client-Zertifikat nur bei ausdrücklich freigegebenem Bedarf aktivieren.

SCEP und Schlüssel: Die Endpunktvariablen beziehen sich auf die oben beschriebenen SCEP-Einstellungen. Der Subject-Wert muss nach Ersetzung der Platzhalter ein gültiger X.500-Name sein: CN=%_USERNAME_% steht für einen Benutzer, CN=%_DEVPROP(SerialNumber)_% für einen Mac. Nicht aus der Wahl einer Benutzerrichtlinie auf eine passende Geräteidentität schliessen. CA-Trust, Zertifikatslaufzeit, Schlüsselausfuhr sowie Ablaufdatum und Verfahren zur erneuten Ausstellung vor der ersten Abhängigkeit prüfen; Root-Zertifikate sind kein Ersatz für ein Client-Zertifikat. Für mehrere Roots jeweils eine eigene Root-certificate-Konfiguration hinzufügen.

Weitere Geräte-Payloads: AirPrint trägt Drucker-IP und Resource path (beispielsweise ipp/print) in die AirPrint-Liste ein. Directory service verbindet den Mac bei Richtlinienzuweisung mit einer AD-Domäne; Join-Konto benötigt Rechte zum Hinzufügen von Computern, die OU muss stimmen. Warnung: Änderungen an UID-, User-GID- oder Group-GID-Mapping können Benutzern den Zugriff auf zuvor erzeugte Dateien nehmen. Mapping nicht als Netztest ändern; AD-Beitritt und seine Rücknahme separat mit AD-/Mac-Verantwortlichen planen.

Directory service: Konten, Home-Verzeichnis und Berechtigungen festlegen

Unter General settings die Angaben für den AD-Beitritt mit den AD-Verantwortlichen abstimmen:

• Domain host name enthält den DNS-Hostnamen der AD-Domäne, der der Mac beitreten soll. Hier gehört weder die Adresse eines DNS-Servers noch der separat unter Preferred DC server festgelegte Domänencontroller hinein.
• AD administrator name und Password enthalten den Namen und das Kennwort des Kontos, mit dem die Verbindung zum AD-Server hergestellt wird. Dieses Join-Konto muss Geräte zur AD-Datenbank hinzufügen dürfen. Das Kennwort nicht in Tickets oder öffentliche Ablagen übernehmen.
• Organizational unit legt die Organisationseinheit (OU) in AD fest, in der der beitretende Computer hinzugefügt wird. Den freigegebenen OU-Wert mit den AD-Verantwortlichen abstimmen; das Feld bestimmt weder Benutzer- oder Gruppenzuordnung noch Home-Verzeichnis.

Vor dem AD-Beitritt mit den AD-/Mac-Verantwortlichen entscheiden, ob ein lokales Home-Verzeichnis mit mobilem Konto oder ein reines Netzwerk-Home benötigt wird. Wird Create mobile account gewählt, erstellt macOS das Konto bei der ersten Anmeldung mit Verbindung zum AD-Server; danach ist die Anmeldung mit AD-Zugangsdaten auch ohne Verbindung zu diesem Server möglich. Mit Require confirmation before creating a mobile account entscheidet der Benutzer, ob das mobile Konto angelegt wird – seine Erstellung ist dann nicht garantiert. Für mobile Konten ist Force local home folder erforderlich: Das Benutzerprofil liegt auf dem Startvolume. Wird diese Option deaktiviert, werden reine Netzwerk-Home-Verzeichnisse verwendet. Mobile Konten deshalb nicht pauschal für jeden Mac aktivieren. Wird Use UNC path from Active Directory verwendet, bindet macOS das im AD-Benutzerkonto hinterlegte Home-Verzeichnis ein; das passende Mount-Protokoll unter Network protocol mit den Verantwortlichen abstimmen und den Zugriff im Pilot prüfen.

Default user shell legt die Kommandozeilen-Shell des Benutzers fest. Bleibt das Feld leer, wird laut Sophos /bin/bash verwendet. Das ist ein dokumentierter Feldstandard, nicht die Übernahme eines unbestimmten macOS-Standards; die gewünschte Shell mit den Mac-Verantwortlichen abstimmen.

Unter Mapping werden AD-Attribute den folgenden macOS-Kennungen zugeordnet:

• UID attribute ordnet ein AD-Attribut der eindeutigen Benutzerkennung in macOS zu.
• User GID attribute ordnet ein AD-Attribut der primären Gruppenkennung eines macOS-Benutzerkontos zu.
• Group GID attribute ordnet ein AD-Attribut der Gruppenkennung eines macOS-Gruppenkontos zu. Diese Zuordnung verleiht keine lokalen Administratorrechte; dafür ist Domain administrator groups zuständig.

Vor der Zuweisung die bestehenden und freigegebenen Zuordnungen mit den AD-/Mac-Verantwortlichen abgleichen. Kein universelles AD-Attribut oder sicheres Leerfeld für diese Mappings voraussetzen. Die oben beschriebene Gefahr für den Zugriff auf vorhandene Dateien bleibt bei späteren Änderungen bestehen.

Unter Administrative vor der Zuweisung folgende Entscheidungen freigeben lassen:

• Preferred DC server legt den AD-Domänencontroller fest, den macOS zuerst kontaktiert. Bleibt das Feld leer, wählt macOS den Controller anhand der AD-Standortinformationen und der Reaktionsfähigkeit der Controller. Die Wahl mit dem AD-Team abstimmen; ein Eintrag bedeutet keine ausschliessliche Bindung an diesen Controller.
• Restrict DDNS begrenzt die Netzwerkschnittstellen, für die macOS Dynamic DNS verwendet. Standardmässig nutzt macOS DDNS für alle Netzwerkschnittstellen. Für eine Begrenzung die BSD-Namen der vorgesehenen Schnittstellen eintragen und nach jedem Eintrag Enter drücken. Sophos nennt en0 als Beispiel für einen eingebauten Ethernet-Port; daraus nicht die passende Schnittstelle jedes Macs ableiten. Die tatsächlichen Schnittstellen am Pilot-Mac ermitteln und die gewünschten DNS-Registrierungen mit dem AD-/DNS-Team abstimmen. Die Einstellung begrenzt DDNS, sie deaktiviert keine Schnittstelle und keinen VPN-Tunnel.
• Kennwortrotation des Computerkontos: Password trust interval in days betrifft das AD-Computerkonto, nicht das Benutzerkennwort. Ein leeres Feld bedeutet einen automatischen Wechsel alle 14 Tage; 0 unterbindet automatische Änderungen. Das Intervall mit dem AD-Betrieb abstimmen; 0 nicht als schnellen Verbindungsfix setzen.
• LDAP-Schutz: Für Packet signing / Packet encryption gilt eine gemeinsame Beschreibung: Allow überlässt macOS, ob die LDAP-Verbindungen signiert und/oder verschlüsselt werden; Disable schaltet beides aus; Require verlangt stets Signierung und Verschlüsselung; SSL/TLS verwendet stets LDAP über SSL/TLS. Daraus nicht ableiten, dass jeder Wert in beiden Feldern verfügbar ist: Die tatsächlichen Auswahlmöglichkeiten im Tenant prüfen und den geforderten Schutz mit dem AD-Team festlegen. Den Schutz nicht für einen erfolgreichen Login herabsetzen.
• Anmeldegrenze: Multi-domain authentication ermöglicht Benutzern aus allen Domänen des AD-Forests die Anmeldung. Das ist eine Erweiterung des Anmeldeumfangs, nicht die oben beschriebene Anwendung der Self-Service-Portal-Benutzerrichtlinie. Bei Namespace = Forest sind gleichnamige Benutzer aus verschiedenen Domänen möglich; die Anmeldung erfolgt als DOMAIN\name. Bei Domain ist die Namespace-Unterstützung ausgeschaltet und die Anmeldenamen müssen eindeutig sein. Zulässige Domänen und Konten vorab festhalten; die Namenswahl ersetzt keine Freigabe des Anmeldeumfangs.
• Lokale Administratorrechte: Mitglieder der unter Domain administrator groups eingetragenen AD-Gruppen erhalten Administratorrechte auf dem Mac. Das ist von den Rechten des Join-Kontos zum Hinzufügen eines Computers zu unterscheiden. Nur freigegebene Gruppen als DOMAIN\group eintragen und die Gross-/Kleinschreibung beachten. Für den Pilot festhalten, welche Konten Standardbenutzer bleiben und welche lokale Administratorrechte erhalten sollen.

Pilot zuweisen und Wirkung prüfen

1. Zuerst den Pilot abgrenzen: Inventar der namentlich vorgesehenen Macs und betroffenen Benutzer, Gruppenmitgliedschaft, vorhandene Richtlinientypen und Zuweisungen sowie funktionierenden Alternativzugang prüfen. Bei einer bestehenden Richtlinie sämtliche zugewiesenen Geräte und Gruppen feststellen; ist sie auch ausserhalb des Pilots zugewiesen oder ist der Wirkungsumfang unklar, nicht bearbeiten. Vor einem Ersatz der bisherigen macOS-Geräte- oder Benutzerrichtlinie alle Payloads und Abhängigkeiten vergleichen und den gleichartigen Rückweg für genau diese Zielgeräte vorbereiten. Auch eine Gruppenzuweisung nur verwenden, wenn ihre Mitgliedschaft und künftige Erweiterung kontrolliert sind; sonst Einzelgeräte wählen.
2. In Policies > macOS über Create eine neue, isolierte Testrichtlinie des passenden Typs erstellen; eine Kopie nur als eigenständige neue Richtlinie ohne übernommene Zuweisungen verwenden. Vor dem ersten Payload-Eingriff verifizieren, dass diese Testrichtlinie keinem Gerät und keiner Gruppe ausserhalb des freigegebenen Pilots zugewiesen ist. Die produktive, breit zugewiesene Richtlinie unverändert lassen. Namen, Beschreibung und Organisationsname setzen; mit Add configuration > Root certificate für Wi-Fi Enterprise zuerst die Root-Konfiguration anlegen. Dort Upload a file wählen, das vorbereitete öffentliche X.509-Root-Zertifikat in PEM- oder DER-Kodierung auswählen und Open anklicken. Nach dem Upload mit Apply die Root-Konfiguration speichern. Bei Zertifikatsauthentisierung danach Client certificate in derselben Richtlinie anlegen. In dieser Client-certificate-Konfiguration unter File die Aktion Upload a file wählen und die vorbereitete PKCS-#12-Datei (.pfx) auswählen. Allow export from keychain nur aktivieren, wenn die Ausfuhr des privaten Schlüssels ausdrücklich erforderlich ist. Danach Wi-Fi konfigurieren. VPN-/Proxy-Konfigurationen nur nach ihren eigenen Abhängigkeiten ergänzen. SCEP gegebenenfalls separat konfigurieren: Die allgemeine Sophos-Anleitung zur Richtlinienerstellung nennt bei hinzugefügtem SCEP ein SCEP renewal interval auf Richtlinienebene, aber die macOS-SCEP-Feldlisten enthalten kein solches Konfigurationsfeld. Ob das Richtlinienintervall im gewählten macOS-Typ tatsächlich verfügbar ist, im Tenant prüfen; Ablaufdatum und Verfahren zur erneuten Ausstellung mit der PKI klären. SCEP nicht ohne eigenen Nachweis als Quelle für das Wi-Fi-Feld Identity certificate behandeln. Zum Abschluss auf Edit policy mit Save die Richtlinie speichern; Pilot-Scope, Payloads und ursprünglichen Stand für den Rückweg festhalten.
3. Das blaue Dreieck der isolierten Testrichtlinie und Assign wählen, unter Select devices ausschliesslich die inventarisierten Pilot-Macs beziehungsweise die zuvor geprüfte und begrenzte Gerätegruppe wählen und Finish. Vor Abschluss die ausgewählten Ziele nochmals gegen das Inventar prüfen; anschliessend tatsächliche Zuweisungen kontrollieren und bei unerwarteter Zielgruppe stoppen. Die Auswahl in diesem Schritt schützt nicht vor Änderungen an einer zuvor bereits breit zugewiesenen Richtlinie. Der macOS-Pfad hat hier keinen Now-/Date-Scheduler für die Zuweisung.
4. Am Pilot-Mac unter System Settings / System Preferences > Profiles die zugewiesenen Profile im richtigen Kontext kontrollieren. Eine Änderung der Geräte-Richtlinie wirkt beim nächsten Gerätesync; die Benutzer-Richtlinie bei der nächsten Anmeldung des betroffenen Benutzers. Eine Änderung an macOS-Richtlinien benötigt keinen iOS-typischen manuellen Update devices-Schritt. Zuweisungs-/Taskstatus plus lokale Profilanzeige protokollieren, aber nicht als Funktionstest werten.
5. Wirkung statt nur Profilstatus: Mit vorgesehenem Benutzer WLAN-SSID, Verbindung und für Enterprise-EAP die erwartete Serververtrauenskette und verwendete Client-Identität mit dem RADIUS-/PKI-Team abgleichen. VPN aktiv aufbauen und DNS/Routen sowie erreichbare und nicht erreichbare Ziele gegen Split-/Volltunnel-Plan prüfen; bei Proxy/PAC einen realen HTTP(S)-Zugriff und Authentifizierungsweg testen. Zertifikate nach Fingerprint, Gültigkeit und Verwendungszweck im zutreffenden Schlüsselbund prüfen. Zusätzlich einen zweiten Benutzer testen, wenn die Geräte- oder AD-weite Wirkung relevant ist. AirPrint-Testdruck und AD-Anmeldung nur falls diese Payloads tatsächlich eingeführt werden. Bei Directory service die erste Online-Anmeldung mit einem freigegebenen AD-Konto und den Zugriff auf das gewählte lokale oder Netzwerk-Home prüfen; bei UNC-Nutzung auch die erwartete Einbindung. Falls ein mobiles Konto vorgesehen ist, dessen tatsächliche Erstellung samt allfälliger Benutzerbestätigung prüfen und danach ohne Verbindung zum AD-Server erneut anmelden. Den unabhängigen lokalen Zugang dabei erhalten. Mit dem AD-/DNS-Team den tatsächlich kontaktierten Domänencontroller und die tatsächlichen DDNS-Registrierungen gegen die vereinbarte Auswahl und den Schnittstellenumfang prüfen. Bei unerwartetem Controller oder DNS-Eintrag den Rollout stoppen und die Ursache mit diesen Verantwortlichen klären. Zusätzlich die erwarteten Standardbenutzer-/Administratorrechte kontrollieren und, wo die Anmeldegrenze dies verlangt, mit einem dafür freigegebenen Testkonto ausserhalb des erlaubten Domänen-/Kontenumfangs prüfen, dass die Anmeldung abgewiesen wird. Mit dem AD-Team den vereinbarten LDAP-Schutz der tatsächlichen Verbindung prüfen und das wirksame Rotationsintervall des Computerkontos abgleichen; einen später fälligen Kennwortwechsel separat nachprüfen, nicht aus dem ersten Login als bestanden werten. Bei unerwartetem Home-Zugriff, Anmeldeumfang, Schutz oder Privileg den Rollout stoppen und die AD-/Mac-Verantwortlichen einbeziehen.
6. Erst nach bestandener Verbindung, erneutem Login und Management-Sync eine weitere Pilotwelle zulassen. Zertifikatsrotation mit Überschneidungsfenster planen: erst neues Vertrauen und neue Identität erfolgreich prüfen, danach alte CA oder Authentisierung entfernen. Die Auswahl einer Firewall-TLS-Inspection-CA und allgemeine Apple-Netzwerkprofile gehören nicht in diese macOS-Mobile-Policy-Entscheidung.

Rückweg bei Verbindungsverlust oder falscher Zielgruppe

1. Rollout stoppen, alle tatsächlich betroffenen Konten, Geräte, Gruppen und Profilversionen sichern; über den unabhängigen Zugang das aktuelle Profil und die zuletzt funktionierende Kombination vergleichen. Vor jeder Korrektur die vollständigen Zuweisungen der Testrichtlinie und der Wiederherstellungsrichtlinie erneut prüfen. Nicht die einzige Verbindung oder CA sofort löschen, über die Sophos Mobile den Mac noch erreichen kann.
2. Bei macOS nicht die generische Aktion Uninstall policy voraussetzen: Sophos erlaubt sie laut Admin-Hilfe nur für Android-Geräte-, Knox-Container- und iOS-Geräterichtlinien. Nur wenn die Testrichtlinie nachweislich ausschliesslich dem Pilot zugewiesen ist, deren Payloads korrigieren und Gerätesync beziehungsweise Benutzer-Login abwarten. Andernfalls keine Richtlinie mit Zuweisungen ausserhalb des Pilots verändern: den Scope zuerst mit den Verantwortlichen eingrenzen und den unabhängigen Zugang nutzen. Als Alternative ausschliesslich den betroffenen Pilot-Macs eine vorbereitete, funktionsfähige Richtlinie gleichen Typs zuweisen; vorher auch deren Zuweisungen und Payloads prüfen, keine gemeinsam genutzte Produktionsrichtlinie für den Rückweg editieren und keine globale Gruppen- oder Unassign-Aktion auslösen. Bei Ersatz einer zuvor zugewiesenen Policy deren Abhängigkeiten und den wirksamen Benutzer-/Gerätekontext prüfen. Eine Benutzer-Richtlinie lokal zu entfernen ist kein dauerhafter Rückweg: sie wird beim nächsten Login neu zugewiesen. Das Enrollment-Profil nicht als Rollback entfernen; dies deregistriert den Mac und benötigt Administratorrechte.
3. Vor Entzug einer alten Root-CA alle abhängigen Wi-Fi-/VPN- und SCEP-/Client-Zertifikate sowie den funktionierenden Alternativpfad prüfen; bei geänderter AD-Zuordnung/UID-Mapping nicht durch blindes Profil-Umschalten Dateirechte riskieren. Wiederhergestellte Netzverbindung, Anmeldung, Zertifikatskette und Sophos-Mobile-Sync auf demselben Pilot-Mac nachweisen. Bleibt der Mac ohne Managementzugang, lokalen Mac-/Netzwerk-/PKI-Support mit den dokumentierten Vorher-/Nachher-Werten einschalten.

Validierungsumfang: Keine macOS-/Tenant-Kombination wurde hier im Labor verifiziert. Diese bedingte Dokumentation setzt keinen pauschalen Tenant-/Labortest vor Veröffentlichung voraus. Vor einem produktiven Rollout in der konkreten Umgebung oder vor jeder Behauptung einer funktionierenden macOS-Konnektivität sind Edition/Lizenz, macOS-Version, Richtlinienumfang und Apple-Business-Benutzerzuordnung sowie Geräte-Sync, Benutzer-Login, PKI-Vertrauen, Wi-Fi-EAP und die tatsächlich verwendete Client-Identität in einem autorisierten Pilot am Gerät nachzuweisen. Für SCEP als Wi-Fi-Identität ist im eigenen Tenant nachzuweisen, ob die ausgestellte Identität im Sophos-Feld Identity certificate auswählbar ist beziehungsweise anderweitig tatsächlich im ausgelieferten Wi-Fi-Profil gebunden wird; zusätzlich sind Identität/Fingerprint im richtigen Geräte-/Benutzerschlüsselbund und eine erfolgreiche EAP-/RADIUS-Anmeldung mit genau diesem Zertifikat am verwalteten Pilot-Mac zu prüfen. Eine Zertifikatsausstellung oder Profilinstallation allein reicht nicht. Auch für SCEP als VPN-Identität sind Auswahl beziehungsweise ausgelieferte Bindung, richtiger Schlüsselbund-/Benutzerkontext und erfolgreiche VPN-Anmeldung mit dem erwarteten Zertifikat am Pilot-Mac nachzuweisen; die Sophos-VPN-Hilfe nennt Zertifikatsfelder, aber keinen SCEP-Verknüpfungsweg. Die SCEP-Bindung an Wi-Fi/VPN ist hier ungeklärt und ohne erfolgreichen autorisierten Pilot kein betriebsfähiger Pfad. Auch VPN-App/Provider/Authentisierung, Zertifikatsrotation, unabhängiger Zugang sowie Richtlinienersatz und Wiederherstellung sind vor produktiver Verwendung am Gerät zu prüfen.