DKE-Fehlerbehebung
Dieses Kapitel konzentriert sich auf Double Key Encryption (DKE) für Microsoft 365: den Weg von einem Office-Client über Microsoft Purview Vertraulichkeitsbezeichnungen bis zu Ihrem On-Premise-DuoKey-DKE-Schlüsselendpunkt (dem KMS-API-Container).
Der hier beschriebene Diagnoseansatz orientiert sich an Microsofts offizieller DKE-Fehlerbehebungsanleitung, angepasst an eine containerisierte On-Premise-DuoKey-Bereitstellung, bei der der DKE-Dienst als KMS-API-Pod hinter dem OpenShift Ingress Router läuft.
Wie DKE zusammenspielt
Zwei Schlüssel schützen den Inhalt: der von Microsoft verwaltete Schlüssel und Ihr DKE-Schlüssel, der Ihren On-Premise-Endpunkt niemals verlässt. Wenn eine der beiden Seiten dieses Ablaufs ausfällt, können Benutzer DKE-geschützte Inhalte weder anwenden noch öffnen.
Schritt 1 — Ist der DKE-Schlüsselendpunkt erreichbar?
Der schnellste erste Test. Öffnen Sie aus einem Client-Netzwerk die Schlüssel-URL in einem Browser:
https://<dke-endpoint>/<keyname>
- Erwartet: eine JSON-Antwort mit dem öffentlichen Schlüssel (
kid,key, Schlüsselmetadaten). - Nichts / Timeout / Verbindung abgelehnt: Netzwerk-, DNS-, Ingress- oder Pod-Problem.
Cluster-seitige Prüfungen:
oc get route -n duokey # ist die DKE/KMS-Route vorhanden?
oc get pods -n duokey -l app=duokey-kms-api # ist der KMS-API-Pod Running/Ready?
oc logs -n duokey -l app=duokey-kms-api --tail=200
curl -I https://<dke-endpoint>/<keyname> # Status + TLS
| Symptom | Wahrscheinliche Ursache | Behebung |
|---|---|---|
| Verbindung abgelehnt / Timeout | Firewall / DNS / keine Route | Port 443 zum Endpunkt freigeben; prüfen, ob öffentliches DNS auf den LB auflöst; OpenShift-Route prüfen |
| 502 / 503 | Kein funktionierender KMS-API-Pod | Zuerst die KMS-API-Pods beheben (oc describe, oc logs) |
404 bei /<keyname> | Falscher Schlüsselname | Bestätigen, dass der Schlüsselname der bereitgestellten Schlüsselkonfiguration entspricht |
Schritt 2 — TLS / Zertifikatsvertrauen
DKE-Clients erfordern ein gültiges, vertrauenswürdiges TLS-Zertifikat auf dem Endpunkt.
| Symptom | Ursache | Behebung |
|---|---|---|
certificate not trusted im Browser/Office | Endpunkt verwendet eine nicht vertrauenswürdige/private CA | Verwenden Sie ein von Clients vertrautes Zertifikat oder verteilen Sie Ihre interne CA an die Clients |
| Handshake-Fehler / Reset | TLS-Version / Cipher-Unterschied | Ingress-tlsSecurityProfile an die Client-Anforderungen anpassen (Netzwerksicherheit) |
| Namensabweichung | Zertifikat-CN/SAN ≠ Endpunkt-Hostname | Zertifikat mit dem korrekten SAN neu ausstellen |
Schritt 3 — Authentifizierung (Entra ID)
DKE autorisiert Schlüsselanforderungen mithilfe eines Entra-ID-Tokens (Azure AD). Die meisten Fehler vom Typ "kann den Schlüssel nicht abrufen" sind Issuer/Audience-Abweichungen.
Prüfen Sie die KMS-API-/DKE-Konfiguration (bereitgestellt als ConfigMap/Secret,
entspricht Microsofts appsettings.json):
| Einstellung | Muss übereinstimmen mit |
|---|---|
| Gültige Issuer | Dem Issuer Ihres Entra-ID-Tenants (https://sts.windows.net/<tenantId>/ oder v2 login.microsoftonline.com/<tenantId>/v2.0) |
| Audience / JWT-Audience | Der App-ID-URI / Client-ID der DKE-Anwendung, die in Entra ID registriert ist |
| Autorisierte Benutzer | Die Mail/UPN oder Gruppe, die Schlüssel anfordern darf |
| Tenant-ID | Ihr Entra-ID-Tenant |
# Die laufende DKE-Konfiguration prüfen (Secrets schwärzen)
oc get configmap duokey-kms-config -n duokey -o yaml
| Symptom | Ursache | Behebung |
|---|---|---|
| 401 Unauthorized | Issuer/Audience-Abweichung oder kein/abgelaufenes Token | ValidIssuers/Audience korrigieren; Entra-App-Registrierung bestätigen |
| 403 Forbidden | Benutzer nicht in der Autorisierungsliste | Benutzer/Gruppe zu den autorisierten Benutzern hinzufügen |
| Funktioniert für Admin, nicht für Benutzer | Autorisierungs-Scoping | Autorisierte Benutzer / Gruppenzuordnung überprüfen |
Stellen Sie sicher, dass die DKE-App-Registrierung in Entra ID existiert, die erwartete Audience/App-ID-URI bereitstellt und dass die Administratorzustimmung erteilt wurde. Eine Issuer/Audience-Abweichung ist die mit Abstand häufigste DKE-Fehlerursache.
Schritt 4 — Konfiguration der Vertraulichkeitsbezeichnung (Purview)
Die DKE-Vertraulichkeitsbezeichnung muss auf Ihren Endpunkt verweisen und veröffentlicht sein.
- In Microsoft Purview müssen die Verschlüsselungseinstellungen der
DKE-Bezeichnung die exakte DKE-Endpunkt-URL enthalten (
https://<dke-endpoint>). - Die Bezeichnungsrichtlinie muss für die Zielbenutzer veröffentlicht sein.
- Räumen Sie Zeit für die Verbreitung von Bezeichnung/Richtlinie an die Clients ein.
| Symptom | Ursache | Behebung |
|---|---|---|
| Bezeichnung fehlt in Office | Richtlinie nicht veröffentlicht / nicht verbreitet | Richtlinie veröffentlichen; Synchronisierung abwarten; ab-/anmelden |
| Bezeichnung wird angewendet, Inhalt aber anderswo unlesbar | Endpunkt für diesen Benutzer nicht erreichbar | Schritte 1–3 aus dem betroffenen Netzwerk erneut prüfen |
| Falscher Endpunkt | URL-Tippfehler in der Bezeichnung | DKE-Endpunkt-URL an der Bezeichnung korrigieren |
Schritt 5 — Office-Client
| Symptom | Ursache | Behebung |
|---|---|---|
| "Etwas ist schiefgelaufen" beim Anwenden/Öffnen | Endpunkt nicht erreichbar oder Authentifizierungsfehler | Schritte 1 und 3 aus dem Netzwerk des Clients ausführen |
| Älterer Client kann DKE nicht nutzen | Build unterstützt DKE nicht | Auf einen DKE-fähigen Microsoft-365-Apps-Build aktualisieren |
| Sporadische Fehler nach Konfigurationsänderung | Veraltetes Token / Cache | Ab- und wieder anmelden; Office-Anmeldeinformations-Cache leeren |
| Funktioniert online, schlägt offline fehl | DKE erfordert Endpunktzugriff beim Öffnen | Der Endpunkt muss erreichbar sein, wann immer geschützter Inhalt geöffnet wird |
Durchgängige Checkliste
- Schlüsselendpunkt liefert im Browser JSON mit öffentlichem Schlüssel:
https://<dke-endpoint>/<keyname> - KMS-API-Pods
Running/Ready; Route vorhanden - TLS-Zertifikat gültig und von Clients vertraut
- Entra-ID-Issuer + Audience stimmen mit der DKE-Konfiguration überein
- Benutzer befindet sich in den autorisierten Benutzern/der Gruppe
- DKE-Bezeichnung verweist auf den korrekten Endpunkt und ist veröffentlicht
- Office-Client ist ein DKE-fähiger Build und kann den Endpunkt erreichen
Eskalation an DuoKey
Sammeln und senden Sie an [email protected]:
oc logs -n duokey -l app=duokey-kms-api --tail=500
oc get route,pods -n duokey
oc get configmap duokey-kms-config -n duokey -o yaml # Secrets schwärzen
Geben Sie an: den genauen Fehler, ob der Browser-Test des Schlüsselendpunkts erfolgreich ist, die betroffenen Benutzer sowie alle kürzlichen Änderungen an Bezeichnungen oder Entra ID.