Grundlagen: Enroll on Behalf of (EOBO)

Nachfolgend eine Beschreibung der Enroll on Behalf Of Funktion sowie Abgrenzung zu anderen Methoden, Zertifikate zu beantragen.

Funktionsweise

Reguläre Zertifikatanforderung

Eine reguläre Zertifikatanforderung liegt üblicherweise im PKCS#10 Format vor. Die Zertifikatanforderung ist signiert mit dem zum in der Zertifikatanforderung hinterlegten öffentlichen Schlüssel gehörenden privaten Schlüssel signiert.

Als Antragsteller wird die Active Directory Identität des Kontos in der Zertifizierungsstellen-Datenbank protokolliert, welches die Zertifikatanforderung an die Zertifizierungsstelle sendet. Die Identität des Zertifikats entspricht bei einer Online-Vorlage diesem Konto, bei einer Offline-Vorlage wird die Identität aus der Zertifikatanforderung übernommen.

Signierte Zertifikatanforderung

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Bei einer signierten Zertifikatanforderung wird die PKCS#10 Zertifikatanforderung in eine Cryptographic Message Syntax (CMS, RFC 5652, einer Weiterentwicklung des PKCS#7 Standards) oder Certificate Management over CMS (CMC, RFC 5272) Nachricht verpackt.

Die CMS-Nachricht wird mit dem privaten Schlüssel eines Zertifikats für einen Zertifikatregistrierungsagenten (Enrollment Agent) signiert.

Auf diese Weise kann beispielsweise ein Freigabeprozess realisiert werden – ein Zertifikatregistrierungs-Agent kann nach Sichtung der Zertifikatanforderung seine Freigabe erteilen, die Zertifizierungsstelle kann anhand der Signatur sicherstellen, dass die Zertifikatanforderung überprüft wurde.

Ein populäres Beispiel ist der Registrierungsdienst für Netzwerkgeräte (NDES), der eingehende Zertifikatanforderungen mit einem entsprechenden Zertifikat signiert, bevor er diese an die Zertifizierungsstelle weitergibt. Die Zertifizierungsstelle kann die Zertifikatanforderung dann auf Vorhandensein dieser Signatur überprüfen (was in den Anleitungen von Microsoft jedoch nicht erwähnt bzw. verlangt wird).

Eine entsprechende Konfiguration wird in der Zertifikatvorlage in der Karteikarte "Issuance Requirements" vorgenommen.

Als Antragsteller wird die Active Directory Identität des Kontos in der Zertifizierungsstellen-Datenbank protokolliert, welches die Zertifikatanforderung an die Zertifizierungsstelle sendet. Die Identität des Zertifikats entspricht bei einer Online-Vorlage diesem Konto, bei einer Offline-Vorlage wird die Identität aus der Zertifikatanforderung übernommen.

Enroll on Behalf of (EOBO) Zertifikatanforderung

Eine Enroll on Behalf of Zertifikatanforderung beinhaltet zusätzlich noch ein RequesterName Attribut, in welchem die Identität eines vom Antragsteller abweichenden Kontos eingetragen wird.

Als Antragsteller wird die Active Directory Identität des in der EOBO-Anforderung im Attribut "RequesterName" eingetragenen Kontos in der Zertifizierungsstellen-Datenbank protokolliert. Die Identität des Zertifikats entspricht bei einer Online-Vorlage ebenfalls diesem Konto.

Ein typisches Einsatzszenario wäre der Fall des Mitarbeiterausweises: Dieser wird durch einen Mitarbeiter der Personalabteilung oder der Gebäudesicherheit mit einem auf den Mitarbeiter lautenden Zertifikat ausgestellt und diesem dann anschließend ausgehändigt, d.h. in einem solchen Fall ist es erforderlich, dass ein als vertrauenswürdig eingestufter dritter die Zertifikatbeantragung für den Mitarbeiter vornimmt.

Technische Voraussetzungen für EOBO

Ablauf der Zertifikatbeantragung

Nachfolgend wird der Ablauf der Zertifikatbeantragung aus Sicht des Zertifikatregistrierungs-Agenten beschrieben. Es wird davon ausgegangen, dass er zu diesem Zeitpunkt bereits über ein entsprechendes Enrollment-Agenten Zertifikat verfügt.

Der Agent öffnet die Veraltungskonsole für Benutzerzertifikate (cermgr.msc). Unter Personal klickt er mit rechts auf Certificates und wählt "All Tasks" – "Advancd Operations" – "Enroll On Behalf Of…".

Im nächsten Dialog wird mit Klick auf "Next" fortgefahren…

Im nächsten Dialog wird (falls vorhanden) die Zertifikatbeantragungs-Richtlinie (Enrollment Policy) ausgewählt und mit Klick auf "Next" fortgefahren.

Im nächsten Dialog wählt der Agent sein Zertifikatregistrierungs-Agenten-Zertifikat aus.

Anschließend wird mit Klick auf "Next" fortgefahren…

Im folgenden Dialog wählt der Agent die zu verwendende Zertifikatvorlage aus. Es werden nur solche angezeigt, welche eine Signatur durch einen Zertifikatregistrierungs-Agenten erfordern.

Im nächsten Dialog wählt der Agent das Benutzerkonto aus, für welches er ein Zertifikat beantragen möchte.

Im Beispiel wurde bewusst das Domänen-Administrator-Konto ausgewählt, um ein grundlegendes Problem mit diesem Mechanismus aufzuzeigen: in der Standard-Einstellung können Zertifikatregistrierungs-Agenten für jeden Benutzer im Active Directory Zertifikate beantragen. Dies umfasst Mitglieder der Geschäftsleitung genau so wie administrative Konten. Hierdurch ist es einem Zertifikatregistrierungs-Agenten problemlos möglich, missbräuchlich andere Identitäten anzunehmen, was auch zu einer kompletten Kompromittierung der Active Directory Gesamtstruktur führen kann.

Um diesen Vektor einzuschränken, sollte sehr genau gewählt werden, welche Zertifizierungsstellen in NTAuthCertificates enthalten sind, welche Zertifizierungsstellen Zertifikate für Zertifikatregistrierungs-Agenten ausstellen dürfen, und es sollte die Funktion "Restricted Enrollment Agents" verwendet werden, um auf den betreffenden Zertifizierungsstellen einzuschränken, welche Agenten für welche Konten Zertifikate beantragen dürfen.

Nach Klick auf "Next" wird das Zertifikat für den Benutzer beantragt. Anschließend kann der Vorgang beendet oder der nächste Benutzer ausgewählt werden.

Eigenständige Erneuerung des Zertifikats durch den Benutzer

Bitte beachten, dass Benutzer ein per EOBO beantragtes Zertifikat nur dann eigenständig erneuern können, wenn ihnen dies durch die Konfiguration der Zertifikatvorlage erlaubt wird. Hierzu muss unter "Issuance Requirements" konfiguriert sein, dass Benutzer bei einer Erneuerung automatisch ein Zertifikat ausgestellt bekommen, wenn sie bereits über ein gültiges Zertifikat von der gleichen Vorlage verfügen.

Weiterführende Links:

Externe Quellen

9 Gedanken zu „Grundlagen: Enroll on Behalf of (EOBO)“

Kommentare sind geschlossen.

de_DEDeutsch