Ich verwende X.509-Clientzertifikate, um eine Reihe von Windows-Clients über gegenseitiges TLS zu authentifizieren. Welche Clients sind Teil dieser Gruppe?sollenirgendwie im AD verwaltet werden, z. B. über die Gruppenmitgliedschaft oder die übergeordnete OU.
Hinweis: Die Frage bezieht sich auf Computerzertifikate, nicht auf Benutzerzertifikate. Das heißt, jeder Benutzer sollte dieses Zertifikat verwenden können, wenn er eine HTTPS-Anforderung von einem solchen Computer aus startet. (Dies gilt zusätzlich zu jeder Benutzeranmeldemethode, die nicht Teil des mTLS-Authentifizierungsschemas ist.)
Server sollten erkennen können, dass der authentifizierende Clientcomputer Mitglied dieses Sets ist. Server sind Linux-basierte Container und nicht Teil des AD/der Domäne, daher verfügen wir nur über die Informationen im X.509-Zertifikat.
Bieten Windows-Zertifikatvorlagen eine Möglichkeit, einen solchen Anspruch als Teil des X.509-Zertifikats zu übermitteln? Es scheint, dass ich die Anzahl der Computer einschränken kann, die ein solches Zertifikat erhalten können, aber dann finde ich keine Möglichkeit, diese Zertifikate so zu kennzeichnen, dass der Server sie identifizieren kann.
- Das X.509-Zertifikat enthält weder den Namen noch die ID der administrativen Vorlage, deshalb kann ich den Server auch nicht so einstellen, dass er diese prüft.
- Die Flexibilität bei der Konfiguration von Betreffzeilen scheint begrenzt zu sein, insbesondere gibt es keine Möglichkeit, AD-Informationen in das Betrefffeld zu übertragen. Das wäre ideal – übersehe ich hier etwas?
- Ich habe darüber nachgedacht, für diese Vorlagen eine spezielle Zwischenzertifizierungsstelle zu verwenden, aber das scheint für so grundlegende Anforderungen viel zu kompliziert.
Vielleicht gibt es einen anderen Aspekt des X.509-Zertifikats, der über die Vorlage festgelegt werden kann? Oder kann ich einen anderen Anspruch als Gruppe/OU verwenden?
Antwort1
Die Antwort ist nein. Die Gruppenmitgliedschaft ist eher eine dynamische Eigenschaft, nicht statisch und kein Teil der Identität des Zertifikatsinhabers. Daher können Sie die Gruppenmitgliedschaft nicht in ein Zertifikat aufnehmen, da diese Information nicht zur Identität gehört. Und jedes Mal, wenn die Gruppenmitgliedschaft geändert wird, müssen Sie das Zertifikat neu ausstellen. Zertifikate sind ziemlich lange gültig. Dies ist eine sehr fehlerhafte Lösung.
Das heißt, jeder Benutzer sollte dieses Zertifikat verwenden können, wenn er eine HTTPS-Anfrage von einem solchen Computer aus startet.
Dies funktioniert nur, wenn die TLS-Anforderung von einer Anwendung gesendet wird, die unter einem lokalen System- oder Netzwerkdienstkonto ausgeführt wird. Wenn Sie solche Zertifikate verwenden möchten, müssen Sie den TLS-Client beispielsweise über den Quellcode explizit so konfigurieren, dass er ein nicht standardmäßiges Client-Zertifikat verwendet.
Server sind Linux-basierte Container und nicht Teil des AD/der Domäne
interessant, wie sollen Linux-basierte Server die tatsächliche Gruppenmitgliedschaft validieren?
Das Client-Zertifikat im gegenseitigen TLS ist die Authentifizierungsmethode. Felder im Zertifikat werden den Kontoinformationen zugeordnet, mit denen Server verbunden werden müssen.
Da Ihre Linux-Server nicht Teil eines AD sind, können sie das Client-Zertifikat nicht an das AD-Benutzerkonto binden und die Gruppenmitgliedschaft validieren. Server können nicht einmal feststellen, ob eine solche Gruppe tatsächlich existiert. Für Linux-Server muss eine separate Identitätsdatenbank verfügbar sein, und Linux-Server müssen das Client-Zertifikat irgendwie an die Identität in dieser separaten Identitätsdatenbank binden. Und nur die in dieser separaten Identitätsdatenbank verfügbaren Informationen dürfen zur Client-Autorisierung verwendet werden.
Das bedeutet, dass Ihre Anforderungen:
Die Gruppenmitgliedschaft für Computer sollte im AD verwaltet werden.
Und
Server sind Linux-basierte Container und nicht Teil des AD/der Domäne
schließen sich gegenseitig aus und können nicht zusammen verwendet werden. Machen Sie den Linux-Server entweder AD-fähig oder schließen Sie in Zertifikate Informationen zur Identität ein, die für Linux-Server verfügbar sind. Und ich würde die Aufnahme von Gruppenmitgliedschaften in Zertifikate dringend vermeiden. Gruppenmitgliedschaften sollten in kurzlebigen Token verwendet werden, nicht in langlebigen Zertifikaten.