Knox Service Plugin mit Sophos Mobile einordnen

Das Knox Service Plugin (KSP) bringt zusätzliche Samsung-Knox-Einstellungen als verwaltete Android-Enterprise-App in Sophos Mobile. Es ist keine eigene Sophos-Geräterichtlinie und ersetzt weder das Android-Enterprise-Enrollment noch dessen Verwaltungsmodus.

Produktions-HOLD: KSP-Einstellungen für Gerätezugang, Netzwerk, Zertifikate, Apps, Passwörter und Kiosk nicht produktiv zuweisen, bevor Einzelrichtlinie, Modus, Lizenz, beobachtete Wirkung und Rückweg am Zielgerät geprüft sind. Ein installierter KSP oder abgeschlossener Sophos-Auftrag genügt dafür nicht.

Vorprüfung: Was muss vor einem Versuch geklärt sein?

Für einen autorisierten Versuch an einem nicht produktiven Gerät prüfen:

1. Gerät, Modus, gewünschte Einstellungen: Modell, Eigentum, Android-/Knox-/KSP-Version und Verwaltungsmodus erfassen; jede benötigte Einstellung mit ihrem beabsichtigten Wirkungsbereich und den versionsbezogenen Samsung-Release-Notes abgleichen. Die Unterstützung je Einstellung ist nicht verifiziert.
2. Samsung-Support klären: Bei älteren Geräten die unten getrennt belegten Aussagen zu Android 9 und Android 12 mit Samsung klären. Android 12/Knox 3.8 allein belegt keine Eignung jeder Richtlinie.
3. Sophos-Umgebung und Lizenz prüfen: Gemäss den unten erläuterten KSP-Mindestanforderungen von Samsung mit Sophos klären, ob die konkret eingesetzte Konsole zur zentralen Geräteverwaltung (UEM) Android Enterprise, Geräteverwaltungs-APIs und OEMConfig sowie managed Google Play für den gewählten Device-Owner-/Profile-Owner-Modus unterstützt. Das dokumentierte Schlüsselfeld, gültige Berechtigung, tatsächliche Aktivierung und Ablaufdatum prüfen; Zuständigkeit für Verlängerung und nötige Reaktivierung der Geräte über die UEM festlegen. Nicht geprüft; „kostenlos“ bedeutet nicht „ohne Schlüssel“.
4. Doppelte Steuerung ausschliessen: Native Sophos-Richtlinien und KSP-Einstellungen je Einschränkung vergleichen; Samsungs besondere Empfehlung für KSP-Geräteeinschränkungen beachten. Eine konfliktfreie Kombination ist nicht nachgewiesen.
5. Wirkung und Rückweg beobachten: Nach Freigabe am Testgerät Ausgangszustand, Wirkung je Einstellung, verfügbares Feedback und Zustand nach administrativer Entfernung prüfen. Gesicherte Administrationsverbindung und Wiederherstellungsweg vorsehen.

Verwaltungsmodus und Wirkungsbereich

Sophos Mobile behandelt KSP als App für Samsung-Geräte mit Knox Platform for Enterprise (KPE, Samsungs Plattform für Unternehmensrichtlinien). Die App wird über managed Google Play genehmigt und verteilt. Die folgende Reihenfolge ist durch die Sophos-Dokumentation bestätigt, nicht durch einen Test in einem Sophos-Tenant oder auf einem Gerät. Für einen autorisierten Versuch nach der Vorprüfung sind Genehmigung, Konfiguration und Installation getrennte Schritte:

1. Für das Android-Enterprise-Konto genehmigen: Unter Apps > Android auf der Seite Apps - Android Enterprise mit Open managed Google Play den eingebetteten Store öffnen. Dort die KSP-App aufrufen, Select wählen und mit Yes bestätigen. Optional lässt sich die App über Organize apps einer Sammlung zuordnen. Das Fenster schliessen; die App erscheint nun in der Sophos-App-Liste. Das ist der dokumentierte Genehmigungsweg, noch keine Installation. Benutzer sehen die App in ihrem managed Play Store erst bei der nächsten Synchronisierung des Geräts mit Sophos Mobile. Der sichtbare Konsoleneintrag bedeutet daher nicht, dass die App schon für die Selbstinstallation verfügbar ist.
2. App konfigurieren und Einstellungen senden: Im dokumentierten Sophos-Ablauf unter Apps > Android die KSP-App wählen. Mit Page und App category deren Platzierung in der Google-Play-Store-App der Benutzer festlegen. Anschliessend Use managed configuration aktivieren und die Samsung-definierten Einstellungen unter Managed configuration konfigurieren. Gemäss diesem dokumentierten Ablauf den Knox-Lizenzschlüssel in KPE Premium License key eingeben; die unten erläuterte Einschränkung zur ungeprüften aktuellen Sophos-Umgebung bleibt bestehen. Danach folgen Save und der separate Befehl Send app settings to Google. Laut Sophos stellt dieser Befehl die Konfigurationsänderungen den Benutzern zur Verfügung.
3. Installation getrennt auslösen: Nach Sophos kann KSP auf ausgewählten Geräten oder Gerätegruppen installiert werden; alternativ installieren Benutzer die genehmigte App selbst aus managed Google Play. Für die administrative Installation unter Apps > Android den Pfeil neben KSP öffnen und Install wählen. Einzelgeräte oder über Select device groups Gruppen auswählen und mit Finish abschliessen. Sophos übergibt den Auftrag an Google; den Installationsstatus unter Show device > Installed apps prüfen. Send app settings to Google ersetzt diesen Installationsschritt nicht. Laut Sophos werden bei der Installation des zuvor konfigurierten KSP auf einem Gerät die Knox-Richtlinien angewendet; der dokumentierte Ablauf setzt den oben genannten Knox-Lizenzschlüssel voraus.

Die angebotenen Felder können sich mit der KSP-App-Version ändern; welche Einstellung tatsächlich greift, hängt vom Verwaltungsmodus und von der jeweiligen Samsung-Richtlinie ab. Weder das Senden an Google noch die Installation beweist die Wirkung am Gerät.

• Vollständig verwaltetes Firmengerät: Sophos Mobile kann das gesamte Gerät verwalten. Das beweist noch nicht die Unterstützung jeder KSP-Einstellung.
• Privates Gerät mit Arbeitsprofil: Die Verwaltung reicht nur in den Arbeitsbereich; ein sichtbares KSP-Feld belegt keine geräteweite Wirkung.
• Firmeneigenes Gerät mit Arbeitsprofil: Samsung nennt diesen Modus für KSP. Welche Einstellungen auch ausserhalb des Arbeitsprofils wirken können, ist von der konkreten Samsung-Richtlinie abhängig; Sophos-Unterstützung und Wirkung sind offen.
• Dediziertes Gerät: Es ist vollständig verwaltet und zusätzlich für Kiosk-Nutzung eingerichtet. Auch hier ist nicht jede KSP-Einstellung automatisch freigegeben.

Sophos unterscheidet vollständig verwaltete Geräte, Arbeitsprofile und dedizierte Geräte; dediziert bedeutet dabei vollständig verwaltetes Enrollment mit zusätzlicher Kiosk-Konfiguration und ist kein vierter eigenständiger Enrollment-Modus. Legacy-Android-Geräteadministrator, Knox-Container und Mobile Threat Defense sind keine austauschbaren KSP-Verwaltungsmodi. Für doppelte Funktionen empfiehlt Samsung grundsätzlich die eingebaute Steuerung der Geräteverwaltungslösung und KSP für zusätzlich benötigte Funktionen. Überschneiden sich native Sophos- und KSP-Einschränkungen, muss die Zuständigkeit vor einem Versuch geklärt werden. Für den Sonderfall, dass auch nur eine KSP-Geräteeinschränkung benötigt wird, empfiehlt Samsung, alle Geräteeinschränkungen innerhalb der KSP-Struktur zu verwalten. Das ist keine pauschale Freigabe für eine gemischte Sophos-/KSP-Konfiguration; Überschneidungen sind am unterstützten Testgerät zu prüfen.

Welche Samsung-Geräte kommen für KSP infrage?

Für ältere Geräte widersprechen sich Samsungs Angaben zum Funktionieren und zur Unterstützung von KSP. Die KSP-Mindestanforderungen (Stand 1. September 2026) nennen Android 12 oder neuer. Die Tabelle der unterstützten Knox-Versionen (Seite aktualisiert am 2. September, Tabelle am 22. Juli 2026) führt für KSP Android 12.0/Knox 3.8 auf, mit Ausnahmen je Funktion. Der separat aufgeführte KPE-Plattformwert ist keine KSP-Grenze. Dagegen antwortet Samsungs KSP-FAQ (Stand 14. September 2026) auf die Frage nach unterstützten Geräten, KSP funktioniere bereits ab Android 9/Knox 3.2.1. Wegen des Widerspruchs belegt diese Aussage keine verlässliche aktuelle Support-Freigabe für ältere Geräte.

Auch bei einem Gerät innerhalb der genannten Support-Grenze müssen die einzelnen Funktionen geprüft werden. Die Release Notes für KSP 26.08 nennen App-Version 1.5.74 vom 4. September 2026; der Auto Blocker benötigt Knox 3.14 oder neuer, die USB-Ausnahmeliste bei gesperrtem Gerät Knox 3.14 und Android 17 oder neuer. Peripheral-Configuration-Richtlinien entfallen in diesem Release. Diese Grenzen gelten für die genannten Funktionen, nicht für alle KSP-Richtlinien. Ein veröffentlichter App-Release belegt weder die Verfügbarkeit im konkreten Sophos-Tenant noch die Übernahme der Konfiguration oder ihre Wirkung auf Geräten.

Für die Planung: Die Support-Tabelle unterscheidet Weiterbetrieb von Support. Ältere Geräte werden laut Samsung nicht allein wegen der Support-Grenze aus Knox-Diensten entfernt; Samsung bietet für Probleme auf solchen Geräten aber keinen Support. Das ist weder eine KSP-Funktionsgarantie unter Android 12 noch eine Aussage, dass KSP dort grundsätzlich nicht funktionieren kann. Die FAQ-Frage nach unterstützten Geräten bleibt dazu widersprüchlich. Für eine neue Einführung die aktuellen Mindestanforderungen und die Grenze Android 12/Knox 3.8 zugrunde legen; ältere Geräte ohne Klärung von Modell und gewünschten Einstellungen mit Samsung nicht freigeben. Auch innerhalb dieser Grenze bleibt die Wirkung einzelner Richtlinien in Sophos Mobile zu prüfen.

Lizenz: kostenlos ist nicht schlüssellos

Die Sophos-Konfigurationsvorgaben (Stand 8. August 2023) verlangen im Feld KPE Premium License key einen Schlüssel; ohne ihn würden die Richtlinien nicht angewendet. Ob dieses Feld und die Richtlinien im konkreten Sophos-System heute ebenso funktionieren, ist nicht geprüft. Samsung nennt die App und die KPE-Premium-Berechtigung kostenlos, verlangt aber eine gültige KPE-Lizenz. Spezialfunktionen können getrennte kostenpflichtige Berechtigungen benötigen. Laut Samsung-Lizenzbedingungen läuft die Premium-Berechtigung zwei Jahre ab Aktivierung; ein Ablauf betrifft auch bestehende Geräte. Samsung verlangt bei Ablauf neben der Verlängerung eine Reaktivierung der betroffenen Geräte über die UEM, nicht nur die Erneuerung des Schlüssels. Ob und wie das im konkreten Sophos-Tenant erfolgt, ist offen. Ablauf ist kein Rückweg.

Kostenlos bedeutet weder schlüssellos im dokumentierten Sophos-Ablauf noch automatisch aktiviert in der konkreten Sophos-Mobile-Umgebung. Lizenzschlüssel gehören nicht in Artikel, Screenshots oder ungeschützte Tickets.

Prüfung am Testgerät

Vor der Wirkungsprüfung zunächst Installation und App-Version kontrollieren. Sophos unterscheidet zwei Fehlerbilder:

• Bleibt Installation request to be sent to Google lange stehen, prüfen, ob KSP für das Land des Benutzers und den Gerätetyp verfügbar ist.
• Bleibt Installation request sent to Google lange stehen, auf dem Gerät in Google Play Pending downloads öffnen und nach einem hängenden Auftrag suchen. Der KSP-Auftrag startet erst, wenn die davor eingereihten Aufträge abgeschlossen sind.

Updates: Laut Sophos lassen sich App-Updates nicht aus Sophos Mobile auslösen; Benutzer müssen sie in Google Play durchführen. Ein erneuter Installationsauftrag ist daher kein dokumentierter Update-Weg. Die tatsächlich installierte KSP-Version erfassen und die dazugehörigen Samsung-Release-Notes sowie die angebotenen Konfigurationsfelder abgleichen.

Besonders Netzwerk-, Zertifikats-, Kiosk- und Zugangsbeschränkungen dürfen nicht ohne gesicherte Administrationsverbindung und Rückweg produktiv ausprobiert werden. Eine erfolgreiche App-Installation oder Übergabe an Google beweist keine Richtlinienwirkung. Laut Samsungs KSP-FAQ gibt es Feedback je Richtlinie nur, falls die UEM die nötige Google-Schnittstelle integriert. Ob Sophos Mobile dieses Feedback in der konkreten Umgebung anzeigt, ist offen. Die tatsächliche Wirkung ist am Testgerät zu beobachten.

Debug mode nur für den begrenzten Versuch

Wenn das Feedback in der Konsole fehlt, beschreibt Samsung einen Debug-Test direkt am Gerät. Ohne Debug mode läuft KSP normalerweise ohne sichtbare App-Oberfläche im Hintergrund. Den Versuch auf wenige autorisierte, nicht produktive Geräte begrenzen. Die folgenden Schritte sind dokumentiert, aber nicht in einem Sophos-Tenant oder auf einem Gerät getestet:

1. Unter Apps > Android KSP öffnen und bei aktiviertem Use managed configuration unter Managed configuration den Schalter Debug mode einschalten. Samsung weist darauf hin, dass dessen Position und Darstellung von der UEM-Oberfläche abhängen. Fehlt der Schalter im angebotenen Schema, mit Sophos klären, statt einen anderen Debug-Schalter zu verwenden.
2. Nur die zuvor freigegebenen Testeinstellungen konfigurieren, Save wählen und mit Send app settings to Google senden. Laut Samsung öffnet sich die KSP-App beim nächsten Empfang neuer Richtlinien auf dem Gerät. Bleibt sie geschlossen, zunächst Zustellung sowie die Versionen von Google Play services und Play client prüfen. Ein gespeicherter Konsolenwert belegt noch keinen Empfang; Samsungs allgemeiner Hinweis auf eine UEM-Aktualisierung ist kein bestätigter Sophos-Klickpfad.
3. In KSP die zuletzt empfangene Konfiguration öffnen. Unter Configuration results die Ergebnisse prüfen und über Policies received die empfangenen Einstellungen im JSON-Format mit den beabsichtigten Testwerten vergleichen. Samsung zeigt erfolgreiche Richtlinien schwarz und fehlgeschlagene rot an. Für jede fehlgeschlagene Richtlinie die Fehlermeldung erfassen. Empfang, Ergebnis je Richtlinie und Fehlerinformation getrennt dokumentieren und zusätzlich die tatsächliche Gerätewirkung kontrollieren. Ein Erfolgsstatus ersetzt diese Beobachtung nicht.
4. Nach dem Versuch Debug mode in derselben verwalteten Konfiguration ausschalten, Save wählen und erneut Send app settings to Google ausführen. Den Empfang der geänderten Konfiguration am Testgerät prüfen. Samsung verlangt das Abschalten vor einer breiten Verteilung; dadurch entsteht noch keine Produktionsfreigabe.

Bei einem ungeklärten Fehler den Versuch stoppen. Lizenzprobleme mit dem Reseller, Fragen zur UEM-Konsole mit Sophos und KSP-Probleme mit dem Samsung-Knox-Support klären.

Diagnoseexporte sichern und Geräteprotokolle anfordern

Die folgenden Schritte beruhen auf dokumentierten Herstellerangaben, nicht auf einem Gerätetest. Gesicherte Administrationsverbindung und Rückweg müssen während des autorisierten, nicht produktiven Versuchs erhalten bleiben.

1. KSP öffnen und die zuletzt empfangene Konfiguration auswählen. Im Exportmenü Export results wählen und mit Save unter Internal storage > Download sichern.
2. Dies mit Export policies received und Export historical events wiederholen. Die Dateien heissen ConfigurationResults_<timestamp>.txt, ReceivedPolicies_<timestamp>.txt und HistoricalEvents_<timestamp>.txt; <timestamp> steht für den vom Export erzeugten Zeitstempel. Ergebnisse und empfangene Richtlinien enthalten JSON; historische Ereignisse umfassen auch frühere Richtlinien und Lizenzaktivierungen.
3. Zeitnah zum Fehler zusätzlich die dumpState-ZIP-Datei über den autorisierten Samsung-Knox-Support erfassen lassen, da Geräteprotokolle überschrieben werden können. Diese Anleitung ist kein ausführbares SysDump-Sammelrezept. Mit dem Support Modell, Android-Version, Zugriffsberechtigung und Erfassungszeitraum klären, bevor Systemdiagnosefunktionen verwendet werden.

Apply Latest Policies darf nur die bereits genehmigten Testeinstellungen erneut anwenden. Wegen der Zustellverzögerung gegebenenfalls nach einigen Minuten erneut versuchen; weder der Tastendruck noch ein Export beweist die Wirkung. Empfang, Ergebnisse und tatsächliche Gerätewirkung erneut vergleichen.

Bei Android 15 oder neuer kann für SysDump eine vorübergehende Deaktivierung von Security and privacy > Auto Blocker nötig sein. Das schwächt einen Schutzmechanismus: nur bei bestätigtem Bedarf, ausdrücklicher Genehmigung und begrenzt auf das Testgerät und die Erfassungsdauer durch autorisierten Support vornehmen lassen; danach den ursprünglichen Schutz wiederherstellen und prüfen. Debug Level Mid ist ebenfalls kein Standardschritt: nur bei nach einem Neustart reproduzierbarem Fehler oder auf Anforderung des Samsung-Knox-Supports erwägen. Die Änderung startet das Gerät neu; Unterbrechung genehmigen lassen, Administrationszugang absichern und nach der Erfassung Debug Level Low wiederherstellen. Dieser Geräte-Debug-Level ist nicht der KSP-Schalter Debug mode.

Alle vier Dateien auf vertrauliche Inhalte einschliesslich Lizenzschlüssel prüfen, geschützt aufbewahren und nur über den autorisierten Supportkanal übermitteln. Delete dumpstate/logcat erst nach überprüfter sicherer Aufbewahrung verwenden, nicht als ersten oder zwingenden Erfassungsschritt. Nach der Diagnose die Wiederherstellung von Schutz und Debug-Einstellungen kontrollieren. Hier wurden weder Protokolle erfasst noch eine Support-Untersuchung durchgeführt.

Rückweg ist nicht gleich Deinstallation

Sophos beschreibt für KSP die Deinstallation der App als Weg zum Entfernen von Knox-Richtlinien. Nicht belegt ist, dass jede einzelne Einstellung danach ihren vorherigen Gerätezustand wiederherstellt. Vor dem Auftrag den Ausgangszustand und den vorgesehenen Wiederherstellungsweg festhalten; anschliessend App-Entfernung und Zustand jeder Testeinstellung am Gerät prüfen.

Für den autorisierten Versuch dokumentiert Sophos diesen administrativen Deinstallationsauftrag. Er gilt sowohl für durch Sophos Mobile installierte Apps als auch für Apps, die Benutzer aus managed Google Play installiert haben:

1. Unter Apps > Android auf Apps - Android Enterprise den Befehl Uninstall wählen.
2. Die betreffenden Einzelgeräte auswählen oder mit Select device groups die freigegebenen Testgruppen wählen. Vor dem Weitergehen kontrollieren, dass keine produktiven Geräte enthalten sind.
3. Auf Select app KSP auswählen.
4. Auf Schedule task mit Now den Auftrag sofort anstossen oder mit Date den geplanten Tag und die Uhrzeit angeben.
5. Mit Finish abschliessen. Sophos sendet die Aufträge an eine Google-API; bis zum Beginn der Deinstallation können einige Minuten vergehen. Auch Now bedeutet keine sofort bestätigte Entfernung am Gerät.

Für ein einzelnes Gerät nennt Sophos alternativ Show device > Installed apps und das Papierkorbsymbol neben dem App-Namen. Nach der Zustellung die tatsächliche Entfernung und den Gerätezustand prüfen. Bleibt eine Testeinstellung wirksam oder ist die Administrationsverbindung unterbrochen, nicht von einer Wiederherstellung ausgehen und nicht weiter ausrollen.

Das Löschen eines Katalogeintrags deinstalliert bereits installierte Apps nicht. Auch Benutzerdeinstallation ist kein gleichwertiger Rückweg. Hat der Administrator die App aus Sophos Mobile installiert, installiert Google sie nach Benutzerdeinstallation standardmässig sofort wieder. Dauerhafte Entfernung durch Benutzer hängt laut Sophos von Allow app uninstall in der zugewiesenen Restrictions-Konfiguration für das Gerät oder Arbeitsprofil ab. Diese Freigabe nicht als pauschalen Rollback-Schritt ändern; sie ist keine dokumentierte Voraussetzung für den administrativen Deinstallationsauftrag.