Sophos Mobile: WLAN und Zertifikate für Windows verwalten

Schnellweg: Für ein bereits in Sophos Mobile verwaltetes Windows-Gerät unter Policies > Windows eine eigene Pilot-Policy erstellen, passende Wi-Fi- und gegebenenfalls Root certificate, Client Certificate oder SCEP-Konfigurationen hinzufügen, speichern und nur einem Testgerät zuweisen. Vorher einen vom neuen WLAN unabhängigen Zugang und die bisherige funktionierende Verbindung erhalten. Danach auf dem Gerät die Verbindung und den Zugriff auf Sophos Mobile prüfen. Eine gespeicherte Policy ist noch kein Beweis, dass das Gerät das neue Profil übernommen hat.

Dieser Ablauf betrifft Sophos Mobile MDM für bereits registrierte Windows-Rechner, nicht den Sophos-Endpoint-Agenten, die Sophos-Firewall-VPN-Konfiguration oder den Sophos-Connect-Client. Die Windows-Policy-Seiten dokumentieren Konfigurationen, beweisen aber keine Unterstützung jedes Windows-Builds und jeder Edition. Vor einer produktiven Zuweisung für das konkrete Gerät Windows-Edition, Build, Microsoft-Supportstatus (einschliesslich einer gegebenenfalls benötigten ESU-Berechtigung), Sophos-Mobile-Enrollment-Modus und aktuelle Sophos-Kompatibilität unabhängig prüfen. Windows-10-Support wird hier nicht zugesichert. Ein Tenant- oder Gerätetest wurde nicht durchgeführt.

Vor dem ersten Eingriff

Prüfen, dass das konkrete Gerät bereits in Sophos Mobile registriert ist, Policies > Windows und die benötigten Konfigurationen im eigenen Tenant verfügbar sind und die zuständige Person die Zuweisung autorisiert hat. Enrollment ist ein eigener Ablauf; ein vorhandener Endpoint-Agent ersetzt es nicht.
SSID, Authentifizierung, bestehende Vertrauenskette und benötigte Benutzer- oder Geräteidentität mit WLAN-/PKI-Verantwortlichen abgleichen. Ein WPA2-Personal-Testprofil ist kein Ersatz für 802.1X mit Zertifikaten. Die manuelle Wi-Fi-Maske dokumentiert nur WPA (Personal) und WPA2 (Personal). Für bestehende andere Verbindungen beschreibt Sophos den Import eines zuvor aus Windows exportierten XML-Profils; die Eignung des konkreten WLANs muss am Pilot geprüft werden.
Für den Pilot einen zweiten funktionierenden Netzwerkpfad, etwa eine freigegebene kabelgebundene Verbindung, und lokalen Zugriff vorhalten. Falls WLAN der einzige Managementpfad ist, nicht das bisherige Profil oder die bisherige CA zuerst entfernen. Einen zweiten Zugriff und eine zuständige Person für Rückbau vereinbaren.
In Restrictions die Option Forbid manual configuration für diesen Pilot nicht einschalten: Sophos beschreibt, dass sie beim Anwenden bestehende, von Benutzern konfigurierte und Wi-Fi-Sense-WLAN-Profile löscht. Die gesamte Restrictions-Konfiguration ist ausserdem für Windows Pro nicht anwendbar. Auch Disable VPN settings ist lediglich eine Sperre von Windows-Einstellungen, keine VPN-Konfiguration.
Bei Zertifikaten die ausstellende CA, Gültigkeit, gewünschten Target store und die erlaubte Schlüsselablage freigeben lassen. Ein Stammzertifikat ist ein Vertrauensanker, kein Clientzertifikat. Key is exportable nur mit begründetem Bedarf aktivieren; ein privater Schlüssel und eine exportierte WLAN-Datei gehören nicht in Tickets, Chats oder öffentliche Ablagen.

Policy und WLAN am Pilotgerät einrichten

In Sophos Mobile Policies > Windows > Create öffnen, einen Windows-Policy-Typ auswählen und auf Edit policy einen eindeutig als Pilot bezeichneten Namen und eine Beschreibung eingeben. Mit Add configuration die benötigten Bausteine hinzufügen und jeden über seinen Namen bearbeiten.
Für ein einfaches Testnetz Wi-Fi > Configure manually wählen. Beispiel: SSID PILOT-WLAN durch die tatsächliche SSID ersetzen; Security type auf das tatsächlich konfigurierte WPA (Personal) oder WPA2 (Personal) setzen und das passende Passwort eingeben. Hidden network nur für ein tatsächlich verborgenes Netz; Connect automatically nur wenn automatische Verbindung erwünscht ist. Das Beispiel ist keine Aussage über die Sicherheit einer produktiven WLAN-Architektur.
Alternativ, wenn eine vorhandene Windows-Verbindung übernommen werden soll: auf einem autorisierten Windows-Rechner, auf dem das Netz unter Known networks steht, die Eingabeaufforderung als Administrator öffnen. Mit netsh wlan show profiles den Profilnamen prüfen und mit netsh wlan export profile "<SSID>" key=clear folder=<Destination> in einen zuvor eingerichteten, zugriffsbeschränkten Ordner exportieren. <SSID> ist durch den angezeigten Profilnamen, <Destination> durch den Zielordner zu ersetzen. Das erzeugte XML enthält das WLAN-Passwort im Klartext. Unter Wi-Fi > Create from existing connection > Wi-Fi profile die XML-Datei hochladen und die lokale Exportdatei nach dem Upload sicher löschen; keine Ausgabe oder Datei ins Ticket kopieren. Kein key=clear auf gemeinsam genutzten oder ungeschützten Rechnern ausführen.
Auf Edit policy mit Save speichern. In Policies > Windows beim Piloteintrag das blaue Dreieck und Assign wählen, auf Select devices ausschliesslich das benannte Testgerät markieren und Finish wählen. Nicht versehentlich Select device groups für eine produktive Gruppe benutzen: Laut Sophos wird für Windows-Policies keine spätere Schedule task-Maske angeboten.
Auf dem Pilotgerät bei bestehendem unabhängigen Zugang die verfügbare WLAN-Verbindung und eine tatsächlich benötigte interne Ressource prüfen; danach sicherstellen, dass das Gerät weiterhin mit Sophos Mobile kommuniziert. Bei ausbleibender Wirkung zunächst Zielgerät, Policy-Zuweisung, nächsten Geräte-Kontakt, SSID/Schutztyp und den Status der vorhandenen WLAN-Verbindung prüfen. Nicht durch massenhafte Neuzuweisungen einen Fehler kaschieren.

Zertifikate: Vertrauen, Identität und SCEP unterscheiden

Für eine 802.1X- oder andere zertifikatsabhängige Verbindung reicht das obige WPA-Personal-Beispiel nicht. Der Import eines Enterprise-WLAN-XML-Profils zusammen mit einem Client- oder SCEP-Zertifikat ist kein von Sophos dokumentierter, betriebsfertiger 802.1X-Ablauf: Ob Import, Zertifikatsauswahl, Authentifizierung und Anwendungsreihenfolge im konkreten Windows-/Enrollment-/PKI-/WLAN-Modus funktionieren, ist offen. Die folgenden Zertifikatsbausteine sind deshalb nur mit WLAN-/PKI-Verantwortlichen und unabhängigem Netzwerkzugang am Einzelgerät zu erproben:

Root certificate: den freigegebenen Vertrauensanker hochladen

Vor dem Upload die freigegebene X.509-CA-Datei (PEM oder DER) unabhängig von der Sophos-Anzeige gegen die PKI-Freigabe prüfen: Dateiidentität/Fingerprint, Subject, Issuer, Gültigkeit und beabsichtigte Zertifikatskette. Häufige Dateiendungen sind bei PEM .cer, .crt und .pem, bei DER .cer und .der. Das sind Beispiele, keine abschliessende Liste zulässiger Endungen. Gerade .cer kann beide Kodierungen enthalten; die Endung allein bestimmt das Format nicht.

Unter Edit policy > Add configuration > Root certificate > Upload a file die freigegebene Datei hochladen. Alternativ kann man sie aus dem Datei-Explorer in den Bereich File ziehen und dort ablegen. Certificate name zeigt laut Sophos den Issuer Distinguished Name (DN) des hochgeladenen Zertifikats, nicht eine verifizierte Identität des CA-Zertifikats; dieses Feld allein belegt den richtigen Vertrauensanker nicht. Apply und danach Save wählen.

Für jedes weitere Stammzertifikat eine eigene Root certificate-Konfiguration zur selben Policy hinzufügen. Die Zertifikate dieser Policy sind anschliessend als Root certificate in deren SCEP-Konfiguration auswählbar. Nur den beabsichtigten Vertrauensanker verteilen, nicht irgendein heruntergeladenes Zertifikat.

Client Certificate: Identität und private Schlüsselablage festlegen

Für ein bereits ausgestelltes Clientzertifikat akzeptiert File PEM oder PKCS #12. In der Client Certificate-Konfiguration auf Upload a file klicken und die Datei mit dem Zertifikat auswählen. Alternativ die Datei aus dem Datei-Explorer in den Bereich Upload a file ziehen. Certificate name zeigt nach dem Upload den Subject-Wert. Target store > User gilt für den bei Sophos Mobile registrierten Benutzer; Device macht das Zertifikat allen Benutzern dieses Rechners verfügbar.

Key location > Software speichert den privaten Schlüssel in einem softwarebasierten Schlüsselspeicher; TPM or software nutzt dagegen ein TPM, wenn es verfügbar ist, und sonst einen softwarebasierten Schlüsselspeicher. TPM installiert das Zertifikat nicht, wenn ein TPM fehlt oder im BIOS ausgeschaltet ist. Windows Hello for Business speichert den privaten Schlüssel in einem Windows-Hello-for-Business-Container. Container name bezeichnet genau den Container, in dem der private Schlüssel dieses Zertifikats abgelegt wird; dafür einen zur Umgebung passenden Container festlegen.

Mit Key is exportable können Benutzer beim Export des Zertifikats auch dessen privaten Schlüssel exportieren. Damit wird nicht nur das öffentliche Zertifikat kopierbar, sondern auch das zugehörige geheime Schlüsselmaterial. Die Wahl von Speicherort und Exportierbarkeit muss deshalb zur PKI-Sicherheitsvorgabe passen, nicht nur dazu, dass der Upload gelingt. Die Vorgabe aus den Voraussetzungen bleibt bestehen: nur bei begründetem Bedarf aktivieren und private Schlüssel nicht in Tickets, Chats oder öffentliche Ablagen übernehmen. Im Pilot die tatsächliche Zertifikatsablage und Zielauthentifizierung prüfen.

SCEP: Ausstellung und Identität mit der PKI abstimmen

Statt eine bestehende Identität hochzuladen, fordert der Client ein Zertifikat von der CA an. Für die von Sophos dokumentierte Integration mit einer SCEP-fähigen Windows-CA muss Sophos Fusion über HTTP(S) grundsätzlich beide getrennten Pfade erreichen: <YOUR-SCEP-SERVER>/CertSrv/MSCEP (SCEP-Server-URL) und <YOUR-SCEP-SERVER>/CertSrv/MSCEP_ADMIN (Challenge-URL); Firewallfreigabe und berechtigte Zugangsdaten mit dem PKI-Team einzeln prüfen. Sophos nennt für einen Windows-2003-SCEP-Server abweichend /CertSrv/MSCEP auch als Challenge-URL; diese Ausnahme nicht auf andere Server übertragen.

Vor der Netzfreigabe in Sophos Fusion My Products > Mobile öffnen und den Hostnamen in der Browser-Adresszeile prüfen: Im ersten URL-Bestandteil steht die Kontoregion unmittelbar nach smc-user-if-cloudstation-. Massgeblich ist diese Kontoregion, nicht der Standort des Administrators oder Geräts. Für SCEP eingehende Verbindungen von Sophos Fusion zum SCEP-Server über TCP 443 erlauben und die Quelladressen auf die für diese Region dokumentierten Adressen begrenzen. Bevor die Firewallregel erstellt oder aktiviert wird, muss die für den PKI-/Netzwerk-Change zuständige Person die aktuelle Sophos-Quelladressliste für SCEP jetzt abrufen, darin ausschliesslich die Adressen der ermittelten Kontoregion auswählen und diese für den konkreten Change freigeben. Kontoregion, Abrufdatum und freigegebene Quelladressen im Change-Protokoll festhalten. Dieser Live-Abruf liefert die veränderlichen Adressen, nicht eine zusätzliche Konfigurationsanleitung; keine dauerhaft gültige IP-Liste aus einem alten Beispiel ableiten. Liegt keine aktuelle, für diese Kontoregion freigegebene Liste vor, hier stoppen und die Firewallregel weder erstellen noch aktivieren; die Quellfreigabe niemals auf andere Regionen oder beliebige Adressen erweitern.

In Setup > Sophos setup > SCEP werden die URLs global hinterlegt. Die globale Einrichtung ist ein eigener PKI-Change; keine allgemeine Gültigkeit dieser Windows-CA-Pfade für andere SCEP-Implementierungen unterstellen. Zusätzlich die folgenden Einstellungen mit dem PKI-Team abstimmen:

Unter User und Password die Zugangsdaten des Kontos eintragen, das einen Challenge-Code erstellen darf und die nötigen Rechte zur Zertifikatsregistrierung hat. In User das Anmeldeformat username@domain verwenden. Dieses globale SCEP-Dienstkonto ist nicht die Benutzeridentität, die später im Zertifikats-Subject stehen soll; Zugangsdaten nicht in Beispiele oder Tickets übernehmen.
Unter Challenge characters die Zeichentypen für das Challenge-Passwort auswählen. Unter Challenge length die voreingestellte Länge übernehmen. Diese Felder betreffen das Passwort, nicht die Challenge-URL in der Windows-Policy.
Use HTTP proxy nur dann deaktivieren, wenn Sophos Mobile den HTTP-Proxy beim Verbindungsaufbau zum SCEP-Server bewusst umgehen soll. Die Option ist nur verfügbar, wenn der HTTP-Proxy aktiviert ist; das Umgehen ist keine allgemeine SCEP-Voraussetzung.

Save testet laut Sophos lediglich die Verbindung zum SCEP-Server, nicht Zertifikatsausstellung oder Erneuerung am Gerät.

In der Windows-Policy zuerst das CA-Zertifikat als Root certificate, dann SCEP hinzufügen und die Felder mit dem PKI-Team festlegen:

Description beschreibt diese einzelne SCEP-Konfiguration, nicht die gesamte Policy. Unter URL die Webadresse des CA-Servers eintragen; %_SCEPPROXYURL_% referenziert die global hinterlegte SCEP-Server-URL.
Subject ist der Name der Person oder des Geräts, die beziehungsweise das das Zertifikat erhalten soll. Dafür können Platzhalter für Benutzerdaten oder Geräteeigenschaften verwendet werden. Entscheidend ist der aufgelöste Wert nach dem Ersetzen aller Platzhalter durch die tatsächlichen Daten: Er muss ein gültiger X.500-Name sein und zur vorgesehenen Identität passen. CN=%_USERNAME_% ist nur ein Syntaxbeispiel für eine Benutzeridentität, kein allgemein gültiger Geräte-Subject. Bei der Policy-Zuweisung wird %_USERNAME_% durch die Eigenschaft Exchange Login des Benutzers ersetzt, der dem Gerät zugeordnet ist. Das ist nicht automatisch dessen E-Mail-Adresse, Windows-Anmeldename oder das globale SCEP-Dienstkonto aus User. Vor der Zuweisung diese Eigenschaft prüfen und im Pilot den daraus entstehenden X.500-Namen mit Exchange Login und der PKI-Vorgabe abgleichen; einen Geräteplatzhalter nur verwenden, wenn seine Eignung für den konkreten Windows-/Enrollment-Modus bestätigt ist.
Unter Subject Alternative Name bei Bedarf einen oder mehrere SAN-Einträge ergänzen. Für jeden Eintrag Add wählen und anschliessend SAN-Typ und SAN-Wert eingeben. Die Werte mit der benötigten Identität und der CA-Vorgabe abgleichen; ein passender Subject ersetzt diese Prüfung nicht.
Challenge ist die Webadresse, über die ein Challenge-Passwort vom SCEP-Server bezogen wird. %_CACHALLENGE_% referenziert die global hinterlegte Challenge-URL; es ist ein URL-Platzhalter, nicht das Challenge-Passwort selbst. Unter Root certificate das passende CA-Zertifikat auswählen. Die Liste enthält alle Zertifikate, die in Root certificate-Konfigurationen der aktuellen Policy hochgeladen wurden; sie ist kein allgemeiner tenantweiter Zertifikatsbestand.
Retries legt die Anzahl der Wiederholungen fest, wenn der Server mit pending antwortet, die Ausstellung also noch aussteht. Retry delay ist der Abstand zwischen diesen Wiederholungen in Sekunden. Beide Werte mit dem Ausstellungsablauf der PKI abstimmen; zusätzliche Wiederholungen beheben keine falsche Challenge-Berechtigung oder ungültige Identität.
Key size ist die Grösse des öffentlichen Schlüssels im ausgestellten Zertifikat. Der Wert muss zur auf dem SCEP-Server konfigurierten Schlüsselgrösse passen, nicht nur allgemein zur CA. Den konkreten Wert mit dem PKI-Team abgleichen; daraus folgt keine bestimmte Schlüsselablage oder Exportierbarkeit wie bei Client Certificate.
Unter Certificate usage den vorgesehenen Verwendungszweck festlegen: Use as digital signature erlaubt die Verwendung für digitale Signaturen, Use for encryption die Verwendung zur Datenverschlüsselung. Diese Zwecke nicht mit einem bereits funktionierenden WLAN-Zugang oder VPN-Tunnel gleichsetzen; die Auswahl muss zum beabsichtigten Zertifikat und zur CA-Vorgabe passen.

Beim Erstellen der Policy den SCEP renewal interval festlegen und die tatsächliche Ausstellung und Erneuerung mit der CA am Pilotgerät prüfen. Ohne bestätigte CA-Anbindung und eindeutige Identitätszuordnung keine produktive Zuweisung.

Erfolg bedeutet mehr als «Policy zugewiesen»: Auf dem Pilotgerät muss das richtige Zertifikat mit passender Identität und Gültigkeit im vorgesehenen Benutzer- oder Gerätekontext erscheinen, die vorgesehene Verbindung authentifizieren und der Sophos-Mobile-Kontakt bestehen bleiben. Scheitert SCEP, zunächst CA-Erreichbarkeit, Challenge-Berechtigung, Subject/SAN, CA-Vertrauen, Schlüsselparameter und den Gerätestatus mit dem PKI-Team prüfen; keine Zertifikatsprüfung oder Servervalidierung abschalten, um den Test grün zu bekommen.

Rückweg mit unabhängigem Zugang vorbereiten

Bei einem Fehlschlag die bisherige funktionierende Verbindung und CA möglichst unangetastet lassen; ein störungsfreier Rückweg ist nicht zugesichert. Über den vorher geprüften unabhängigen Zugang auf dem betroffenen Gerät zuerst den tatsächlich zugewiesenen Policy-Namen und die lokale Verbindung prüfen. Die Pilot-Policy korrigieren oder eine zuvor vorbereitete funktionierende Windows-Policy gezielt dem gleichen einzelnen Gerät zuweisen; erst nach erneutem Kontakt und nachgewiesen funktionierendem WLAN die Testkonfiguration ablösen. Sophos dokumentiert für Windows-Policies kein gerätespezifisches Uninstall policy: Diese Aktion gilt nur für Android-, Knox- und iOS-Policies. Unassign wirkt laut Dokumentation auf alle Geräte einer Policy und ist daher kein sicherer Einzelgerät-Rückweg. Änderungen an anderen Policies synchronisieren beim nächsten Gerätekontakt automatisch; ohne Kontakt darf man keine erfolgreiche Rücknahme behaupten. Vor einer produktiven Änderung müssen am exakt registrierten Windows-Gerät Policy-Synchronisierung, tatsächliche WLAN-Authentifizierung und der lokale Rückweg bei gesichertem Zweitzugang beobachtet und freigegeben sein.

Ist das Gerät schon offline, keine CA, SCEP-Zugangsdaten oder alte WLAN-Profile zentral widerrufen und keine Gruppen-Policy auf Verdacht ändern. Erst lokale Erreichbarkeit über den vereinbarten Zweitweg wiederherstellen und den Istzustand erfassen; danach Pilot-Zuweisung und Zertifikatsgültigkeit erneut prüfen. Ob und wann auf dem Client verbliebene Zertifikate oder Profile durch einen Policy-Wechsel entfernt werden, ist hier nicht als garantierter Automatismus dokumentiert und muss im eigenen Windows-/Sophos-Mobile-Modus verifiziert werden.

VPN-Grenze: Die aktuelle Sophos-Liste der Windows-Policy-Konfigurationen enthält WLAN, Root-/Clientzertifikate und SCEP, aber keinen eigenständigen Windows-VPN-Payload. Die Option Disable VPN settings in Restrictions sperrt Einstellungen und ist keine VPN-Bereitstellung. Für eine VPN-Verbindung sind Client, Tunnelprotokoll, Gateway und Authentifizierung separat zu planen; aus einem installierten Zertifikat folgt noch kein VPN-Tunnel. Die bestehenden Sophos-Connect-Provisioning-Schritte für Windows behandeln den getrennten Firewall-/VPN-Client-Pfad.