Mac-VPN-Zertifikat: Welches Konto sieht das Gateway?

Das Profil zeigt Ihren Namen, die sichtbare Bezeichnung des Zertifikats sagt etwas anderes, und das Gateway-Protokoll verzeichnet eine dritte Kennung. Keine davon lügt, und genau das ist das Problem: Drei verschiedene Felder werden gelesen, als beantworteten sie eine einzige Frage. Die Verbindung legt Anmeldedaten, eine IKEv2-Kennung und ein Konto vor, und das Gateway entscheidet, welche davon was autorisiert.

Drei Identitäten in einer Verbindung

Der sichtbare Profilname ist eine Bezeichnung für Menschen. Er wählt eine Verbindung aus und sonst nichts. Das Zertifikat sind Anmeldedaten, und ob es etwas beweisen kann, hängt davon ab, ob der Client den passenden privaten Schlüssel besitzt. Das Kontofeld ist eine Behauptung über einen Prinzipal, und der Server darf es einer anderen lokalen Identität zuordnen.

Wenn die Authentifizierung fehlschlägt, fragen Sie, auf welche der drei sich der Fehler bezieht. Zurückgewiesene Anmeldedaten, eine unbekannte Kennung und ein deaktiviertes Konto erzeugen unterschiedliche Meldungen, und sie alle als ein „Zertifikatsproblem“ zu behandeln, schickt Sie an die falsche Konsole.

Lesen Sie die nativen Felder nach ihrer Aufgabe

In einer verwalteten nativen IKEv2-Konfiguration trennt Apples Payload-Referenz die Werte, und die Authentifizierungsmethode entscheidet, welche Kombination erforderlich ist:

Ein Zertifikat und eine EAP-Anmeldung können in derselben Verbindung unterschiedliche Rollen haben. Erzwingen Sie nicht, dass jedes Feld denselben Text enthält, nur weil eines davon ihn hat, und nehmen Sie nicht an, dass eine Änderung die anderen überschreibt. Eine VPN-App von Drittanbietern kann ein völlig anderes Modell anbieten; nutzen Sie deren dokumentierte Identitätsauswahl, statt native Feldnamen dorthin zu übertragen.

Ein Serverzertifikat ist keine Client-Identität

Das Zertifikat, das das Gateway validiert, ist ein Vertrauensanker. Es beweist, dass Sie den erwarteten Server erreicht haben. Eine Client-Identität ist ein anderes Objekt: Sie umfasst den Zugriff auf den privaten Schlüssel, der beweist, dass die verbindende Partei die ist, für die sie sich ausgibt. Das Umbenennen eines sichtbaren Kontos kann das eine nicht in das andere verwandeln.

Hier geht eine gut gemeinte Korrektur schief. Das CA-Zertifikat des Gateways in den Client-Speicher zu importieren, bewirkt nichts für die Client-Authentifizierung, und diesen Eintrag mit dem Benutzernamen zu beschriften macht ihn nicht zu einer Benutzeridentität. Die beiden Objekte leben in verschiedenen Teilen des Profils und beantworten verschiedene Fragen.

Folgen Sie dem Prinzipal bis zur Zuordnung am Gateway

Bestätigen Sie, wofür die Anmeldedaten ausgestellt wurden: für diesen Benutzer, dieses Gerät oder eine gemeinsame Rolle. Das Mac-Anmeldekonto ist nicht automatisch dieser Prinzipal, und ein von einem anderen Rechner kopiertes Zertifikat behält die Identität des Rechners, für den es ausgestellt wurde.

Vergleichen Sie dann die tatsächlichen Anmeldedaten, nicht die Bezeichnung. Aussteller, Seriennummer und Fingerabdruck lassen Sie und den Administrator bestätigen, dass Sie über dasselbe Objekt sprechen. Anzeigenamen sind editierbar und häufig doppelt vorhanden, was sie zur schlechtesten möglichen Kennung während eines Vorfalls macht.

Der letzte Schritt liegt beim Gateway. Lassen Sie dessen Eigentümer eine Verbindung mit den vorgelegten Kennungen und der Kontozuordnungsregel korrelieren, die sie verbraucht hat. Eine Bezeichnung auf der Clientseite kann nicht feststellen, was der Server entschieden hat, und eine Regel, die ein Zertifikat einem deaktivierten Konto zuordnet, wird fehlschlagen, während jedes Feld auf der Clientseite korrekt aussieht.

Reparieren Sie die Schicht, der die Abweichung gehört

Wenn das Profil auf die falschen Anmeldedaten zeigt, korrigieren Sie deren Referenz oder Auswahl. Wenn die Anmeldedaten zu einem anderen Prinzipal gehören, gehen Sie die Neuregistrierung beim Aussteller durch, statt Bezeichnungen zu bearbeiten. Wenn das Gateway gültige Anmeldedaten an das falsche Konto bindet, muss dessen Richtlinieneigentümer die Zuordnung korrigieren. Das sind drei verschiedene Änderungen mit drei verschiedenen Genehmigern.

Die Erneuerung verdient dieselbe Sorgfalt. Das Zertifikat auszutauschen, seine sichtbare Bezeichnung umzubenennen und eine Person zwischen Kontosystemen zu verschieben, wirkt sich nicht zwangsläufig in gleicher Weise auf die Zuordnung aus. Halten Sie fest, welche der drei Sie geändert haben, denn der nächste Fehler wird von der Clientseite identisch und im Gateway-Protokoll anders aussehen.

Teilen Sie nur die minimalen öffentlichen Kennungen, die der Support benötigt. Ein privater Schlüssel oder ein vollständiges Identitätspaket ist nie Teil dieses Austauschs, so bequem es die Diagnose auch machen würde.