Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Der Zertifikatregistrierungs-Webdienst ist ein AD CS-Rollendienst (Active Directory Certificate Services), der Benutzern und Computern das Ausführen der Zertifikatregistrierung mithilfe des HTTPS-Protokoll ermöglicht. Zusammen mit dem Zertifikatregistrierungsrichtlinien-Webdienst wird dadurch eine richtlinienbasierte Zertifikatregistrierung ermöglicht, wenn der Clientcomputer nicht Mitglied einer Domäne ist oder wenn für ein Domänenmitglied keine Verbindung mit der Domäne besteht. Der Webdienst für die Zertifikatsregistrierung verwendet das HTTPS-Protokoll, um Zertifikatsanforderungen von Client-Computern im Netzwerk anzunehmen und ausgestellte Zertifikate an diese zurückzugeben. Der Zertifikatregistrierungs-Webdienst verwendet das DCOM-Protokoll, um sich mit der Zertifizierungsstelle (CA) zu verbinden und die Zertifikatsregistrierung im Namen des Anforderers abzuschließen.
Die Zertifikatsregistrierung über HTTPS ermöglicht:
- Zertifikatsregistrierung über Gesamtstrukturgrenzen hinweg, um die Anzahl der CAs in einem Unternehmen zu reduzieren
- Extranet-Bereitstellung zur Ausstellung von Zertifikaten für mobile Mitarbeitende und Geschäftspartner
Dieser Artikel bietet einen Überblick über den Zertifikatregistrierungs-Webdienst, einschließlich Informationen über die Authentifizierungsarten, Überlegungen zum Lastausgleich und Konfigurationsoptionen.
Authentifizierungstypen
Der Zertifikatregistrierungs-Webdienst unterstützt die drei folgenden Authentifizierungsarten:
Integrierte Windows-Authentifizierung
Clientzertifikatsauthentifizierung
Benutzernamen- und Kennwortauthentifizierung
Jede dieser Authentifizierungsarten wird in den folgenden Abschnitten ausführlicher behandelt.
Integrierte Windows-Authentifizierung
Die integrierte Windows-Authentifizierung verwendet entweder Kerberos oder NT LAN Manager (NTLM), um einen nahtlosen Authentifizierungsfluss für Geräte zu gewährleisten, die mit dem internen Netzwerk verbunden sind und einer Domäne angehören. Diese Methode wird für interne Implementierungen bevorzugt, da sie die bestehende Infrastruktur der Active Directory Domain Services (AD DS) nutzt und nur minimale Änderungen an den Client-Computern der Zertifikate erfordert. Verwenden Sie diese Authentifizierungsmethode, wenn Sie nur Clients benötigen, die direkt mit Ihrem internen Netzwerk verbunden sind, um auf den Webdienst zuzugreifen.
Clientzertifikatsauthentifizierung
Wenn den Computern Zertifikate zur Verfügung gestellt werden, können die Client-Computer die Client-Zertifikatsauthentifizierung verwenden. Für die Authentifizierung von Client-Zertifikaten ist keine direkte Verbindung zum Unternehmensnetzwerk erforderlich. Die Client-Zertifikatsauthentifizierung wird der Authentifizierung mit Benutzername und Kennwort vorgezogen, da sie eine sicherere Methode der Authentifizierung darstellt. Diese Methode erfordert jedoch, dass x.509-Zertifikate den Clients zunächst auf anderem Wege zur Verfügung gestellt werden. Verwenden Sie diese Authentifizierungsmethode, wenn Sie Benutzern digitale X.509-Zertifikate für die Client-Authentifizierung zur Verfügung stellen möchten. Diese Authentifizierungsmethode ermöglicht es Ihnen, den Webdienst im Internet verfügbar zu machen.
Wenn Sie die zertifikatsbasierte Authentifizierung von außerhalb der Domäne für einen Computer verwenden möchten, der in einer Arbeitsgruppe konfiguriert ist oder der Mitglied einer Domäne ist, zu der keine Gesamtstruktur-Vertrauensstellung besteht, dann müssen Sie außerdem Folgendes tun:
- Stellen Sie sicher, dass in der Gesamtstruktur, zu der die Zertifizierungsstelle gehört, ein Computerkonto mit demselben Namen wie der Computer, der das Zertifikat erhält, existiert.
- Stellen Sie ein Zertifikat mit Namen aus, die für den Computer geeignet sind, für den das Zertifikat ausgestellt wird.
- Übertragen Sie das ausgestellte Zertifikat manuell von einem Computer innerhalb der Domäne auf den entsprechenden Computer, der entweder in einer Arbeitsgruppe konfiguriert ist oder der Mitglied einer Domäne ist, zu der keine Gesamtstruktur-Vertrauensstellung-Beziehung besteht.
Benutzernamen- und Kennwortauthentifizierung
Die einfachste Form der Authentifizierung ist der Benutzername und das Kennwort. Diese Methode wird in der Regel für die Betreuung von Clients verwendet, die nicht direkt mit dem internen Netzwerk verbunden sind. Dies ist eine weniger sichere Authentifizierungsoption als die Verwendung von Client-Zertifikaten, aber es erfordert keine Bereitstellung eines Zertifikats für Clients und ist daher oft einfacher zu implementieren als die Authentifizierung mit Client-Zertifikaten. Verwenden Sie diese Authentifizierungsmethode, wenn Sie möchten, dass Benutzer einen Benutzernamen und ein Kennwort eingeben, um sich beim Webdienst zu authentifizieren. Diese Authentifizierungsmethode kann verwendet werden, wenn der Zugriff auf den Webdienst über das interne Netzwerk oder über das Internet erfolgt.
Anforderungen an die Delegation
Die Delegation ermöglicht es einem Dienst, sich für ein Benutzerkonto oder ein Computerkonto auszugeben, um auf Ressourcen im gesamten Netzwerk zuzugreifen. Wenn ein Dienst für die Delegation vertrauenswürdig ist, kann dieser Dienst sich als Benutzer ausgeben, um andere Netzwerkdienste zu nutzen.
Die Delegation ist für den Zertifikatregistrierungs-Webdienst erforderlich, wenn alle der folgenden Punkte zutreffen:
Die CA befindet sich nicht auf demselben Computer wie der Zertifikatregistrierungs-Webdienst
Der Zertifikatregistrierungs-Webdienst muss in der Lage sein, Anträge auf Erstregistrierung zu verarbeiten, im Gegensatz zur Verarbeitung von Zertifikatserneuerungsanträgen.
Der Authentifizierungstyp ist auf integrierte Windows-Authentifizierung oder Client-Zertifikatauthentifizierung eingestellt.
Eine Delegation für den Zertifikatregistrierungs-Webdienst ist nicht erforderlich, wenn:
Die CA und der Zertifikatregistrierungs-Webdienst befinden sich auf demselben Computer
Benutzername und Kennwort sind die Authentifizierungsmethode.
Wenn der Zertifikatregistrierungs-Webdienst als integrierte Anwendungspool-Identität ausgeführt wird, sollten Sie die Delegation auf dem Computerkonto konfigurieren, das den Dienst hostet. Wenn der Zertifikatregistrierungs-Webdienst unter einem Domänenbenutzerkonto ausgeführt wird, müssen Sie zunächst einen geeigneten Dienstprinzipalnamen (SPN) erstellen und dann die Delegierung für das Domänenbenutzerkonto konfigurieren.
Die spezifische Art der Delegierung, die Sie konfigurieren sollten, hängt von der für den Zertifikatregistrierungs-Webdienst ausgewählten Authentifizierungsmethode ab:
- Wenn Sie die integrierte Windows-Authentifizierung gewählt haben, sollten Sie die Delegation auf Nur Kerberos verwenden konfigurieren.
- Wenn der Dienst die Client-Zertifikatauthentifizierung verwendet, sollten Sie die Delegation auf Beliebiges Authentifizierungsprotokoll verwenden konfigurieren.
Best Practices für Lastausgleich und Fehlertoleranz
Der größte Faktor, der sich auf den Durchsatz auswirkt, ist laut umfangreichen Leistungstests von Microsoft die Netzwerklatenz. Der Zertifikatregistrierungs-Webdienst und die Client-Komponenten des Webdienstes für die Zertifikatsregistrierung sind nicht auf Technologien für den Netzwerklastausgleich (NLB) angewiesen, sondern verfügen über eine eingebaute Logik für den Lastausgleich und die Fehlertoleranz. Die Clients nehmen beispielsweise automatisch eine Zufallsauswahl aus der Liste der Endpunkte vor und versuchen, die Liste zu durchlaufen, wenn der erste Endpunkt nicht antwortet. Solange mehrere Uniform Resource Identifiers (URIs) veröffentlicht werden, ist ein grundlegender Lastausgleich und Fehlertoleranz eingebaut.
NLB sollte nicht verwendet werden, um Fehlertoleranz oder Hochverfügbarkeit zu gewährleisten, da NLB den Datenverkehr an einen Host weiterleiten könnte, auf dem die Richtlinie oder der Webdienst gestoppt oder nicht verfügbar ist. Wenn alle Endpunkte hinter einem einzigen NLB-ausgeglichenen URI veröffentlicht werden, kann die eingebaute Client-Logik nicht den nächsten URI ausprobieren, was zu einer weniger fehlertoleranten Lösung führt, als wenn überhaupt kein spezieller Lastausgleich verwendet wird.
Zu den allgemeinen Best Practices für den Lastausgleich der Webdienste für Richtlinien und Registrierung gehören:
- Veröffentlichen Sie mehrere Anmelde- und Richtlinien-URIs, die jeweils eindeutige DNS-Namen haben und vorzugsweise über verschiedene Netzwerkpfade verfügbar sind. Lassen Sie die eingebaute Client-Logik für Lastausgleich und Fehlertoleranz sorgen.
- Veröffentlichen Sie nicht mehrere URIs hinter einem einzigen URI (es sei denn, dieser URI wird über ein Gerät, das sowohl die Netzwerk- als auch die Anwendungsebene kennt, ausgeglichen).
- Verwenden Sie keine DNS-Round-Robin- oder andere DNS-Lastausgleichstechniken, die keine Intelligenz auf der Anwendungsebene und kein Routing bieten.
Konfigurationsoptionen
In den folgenden Abschnitten werden die verschiedenen Konfigurationsoptionen für den Zertifikatregistrierungs-Webdienst erläutert.
Intranet mit einer einzigen Gesamtstruktur
Das einfachste Einsatzszenario ist eine einzelne Gesamtstruktur mit Clients, die mit dem Intranet verbunden sind. Bei diesem Entwurf können der Zertifikatregistrierungs-Webdienstsrichtlinie und der Zertifikatregistrierungs-Webdienst auf einer ausstellenden Zertifizierungsstelle installiert werden, aber es wird empfohlen, sie auf separaten Computern zu installieren. Wenn der Zertifikatregistrierungs-Webdienst und der Zertifikatregistrierungs-Webdienst auf getrennten Computern ausgeführt werden, muss der Zertifikatregistrierungs-Webdienst in der Lage sein, mit AD DS über LDAP zu kommunizieren. Der Zertifikatregistrierungs-Webdienst muss in der Lage sein, sich über DCOM mit der CA zu verbinden. In Intranet-Szenarien ist entweder Kerberos oder NTLM die typische Authentifizierungsart.
Intranet mit mehreren Gesamtstrukturen
Ein fortschrittlicheres Intranet-Szenario umfasst mehrere Gesamtstrukturen mit zentralisierten Ausgabediensten in nur einem (oder einigen) von ihnen. In diesem Design sind die Gesamtstrukturen mit einem zweiseitigen Gesamtstruktur-Vertrauensstellung verbunden und die CA und die Webdienste zur Zertifikatsregistrierung werden im selben Forest gehostet. Die Vorteile dieses Modells sind, dass es ein hohes Maß an Konsolidierung in verschiedenen Gesamtstrukturumgebungen ermöglicht. In der Vergangenheit benötigte jede Gesamtstruktur eine eigene CA für die automatische Registrierung. Jetzt sind alle PKI-Dienste zentralisiert, was zu einer erheblichen Verringerung der Gesamtzahl der erforderlichen CAs führen kann. Da es sich um ein Intranet-Szenario handelt, ist das gängigste Authentifizierungsschema entweder Kerberos oder NTLM.
Umkreisnetzwerk & Filiale
Dieses Einsatzszenario bietet die Möglichkeit, Benutzer und Computer zu registrieren, die nicht direkt mit dem Netzwerk eines Unternehmens oder über ein virtuelles privates Netzwerk (VPN) verbunden sind. Bei diesem Entwurf befinden sich der Zertifikatregistrierungs-Webdienst und der Zertifikatregistrierungs-Webdienst beide im Umkreis des Netzwerks, und internetbasierte Clients registrieren sich über HTTPS bei diesen Endpunkten. Dieses Bereitstellungsmodell eignet sich ideal für Domänenbenutzer, die häufig an entfernten Standorten arbeiten, oder für Filialszenarien, in denen die VPN- oder Direktverbindung zurück zum Unternehmensnetzwerk unzuverlässig ist.
Optional kann ein schreibgeschützter Domänencontroller, Read Only Domain Controller (RODC), verwendet werden. Die externen Clients (Remotebenutzer) haben über die Corp-Firewall keinen Zugriff auf den beschreibbaren Domänencontroller oder auf die CA. Die Registrierungs- und Richtlinien-Webservice-Server haben keinen Zugriff auf den beschreibbaren Domain Controller. Der Zertifikatregistrierungs-Webdienst muss jedoch die Möglichkeit haben, sich über DCOM durch die Firewall mit der Zertifizierungsstelle zu verbinden.
Nur-Erneuerungen-Modus
Damit der Zertifikatregistrierungs-Webdienst Zertifikate von einer Zertifizierungsstelle anfordern kann, muss er den Aufruf an die Zertifizierungsstelle delegieren und sich dabei als der Anrufer ausgeben. Das bedeutet, dass für das Webdienstkonto für die Zertifikatsregistrierung die Delegation aktiviert sein muss. Für Endpunkte, die dem Internet zugewandt sind, ist dies nicht unbedingt die beste Lösung, da dies ein höheres Maß an Anfälligkeit für internetbasierte Bedrohungen bedeutet.
Um dieses Risiko zu minimieren, ermöglicht der Modus „Nur Erneurung“ dem Zertifikatregistrierungs-Webdienst, nur Anträge auf Zertifikatserneuerung ohne aktivierte Delegation zu verarbeiten. Der Webdienst für die Zertifikatsregistrierung verwendet das Originalzertifikat, das im internen Netzwerk bereitgestellt wurde, um die über das Internet gesendete Erneuerungsanforderung zu authentifizieren. Der Zertifikatregistrierungs-Webdienst übermittelt dann die Anforderung an die Zertifizierungsstelle unter seiner eigenen Berechtigung, und die Zertifizierungsstelle erneuert das Zertifikat auf der Grundlage der Active Directory-Informationen des Anforderers des ursprünglichen Zertifikats und/oder der Betreff-Informationen im ursprünglichen Zertifikat. In diesem Modus werden neue Anforderungen zur Registrierung von Zertifikaten vom Webdienst für die Zertifikatsregistrierung abgelehnt und erreichen die Zertifizierungsstelle nie.
Aus der Perspektive des Netzwerkdesigns kombiniert dieses Szenario sowohl das interne als auch das Umkreisnetzwerkmodell, die zuvor besprochen wurden.
Schlüsselbasierte Verlängerung
Im Modus der schlüsselbasierten Erneuerung kann ein vorhandenes gültiges Zertifikat zur Authentifizierung seiner eigenen Erneuerungsanforderung verwendet werden. Dies ermöglicht es Computern, die nicht direkt mit dem internen Netzwerk verbunden sind, ein bestehendes Zertifikat automatisch zu erneuern.
Sie können die schlüsselbasierte Erneuerung verwenden, um Zertifikats-Client-Computern außerhalb Ihrer AD DS-Gesamtstruktur zu ermöglichen, ihre Zertifikate zu erneuern, bevor sie ablaufen. Dazu gehören Clients, die in Arbeitsgruppen konfiguriert sind, oder Clients, die Mitglieder anderer AD DS-Wälder sind. Ein Konto in der Gesamtstruktur der CA muss verwendet werden, um das erste Zertifikat zu erhalten. Sobald das Zertifikat jedoch an den Client verteilt wurde, ist für die schlüsselbasierte Erneuerung keine Gesamtstruktur-Vertrauensstellung mehr erforderlich, um eine Zertifikatserneuerung zu ermöglichen.
Zum Beispiel könnte ein Zertifikat, das für einen in einer Arbeitsgruppe konfigurierten Webserver ausgestellt wurde, von einem Mitglied der Enterprise CA-Domäne erneuert werden. Ein Beispiel für eine solche Konfiguration finden Sie in der folgenden Abbildung.
Web1 muss das Stamm-CA-Zertifikat im Speicher der vertrauenswürdigen Stammzertifizierungsstellen haben, bevor Sie eine Zertifikatserneuerung anfordern. Web1 verwendet Zertifikatregistrierungs-Webdienste, um seine Zertifikate automatisch zu erneuern, wenn die schlüsselbasierte Erneuerung aktiviert ist. Und ein Administrator von Web1 muss sicherstellen, dass der URI des Certificate Enrollment Policy Web Service auf Web1 konfiguriert ist.
Hinweis
Wenn Sie die schlüsselbasierte Erneuerung aktivieren möchten, müssen Sie die Client-Zertifikatauthentifizierung für den Zertifikatregistrierungs-Webdienst aktivieren.
Unterschiede zum Rollendienst der Zertifizierungsstellen-Webregistrierung
Obwohl CA Web Enrollment und Zertifikatregistrierungs-Webdienste beide HTTPS verwenden, handelt es sich um grundlegend unterschiedliche Technologien. CA Web Enrollment bietet eine browserbasierte, interaktive Methode zur Beantragung einzelner Zertifikate, die keine speziellen Client-Komponenten oder eine Konfiguration erfordert. CA Web Enrollment unterstützt nur interaktive Anforderungen, die der Antragsteller manuell über die Website erstellt und hochlädt. Wenn ein Administrator beispielsweise ein Zertifikat für einen Apache-Webserver mit Linux-Betriebssystem bereitstellen möchte, kann eine PKCS #10-Anforderung hochgeladen werden, die mit OpenSSL erstellt wurde. Nachdem die Zertifizierungsstelle die Anforderung gestellt hat, kann das Zertifikat mit dem Browser heruntergeladen werden.
Der Webdienst für Zertifikatsregistrierungsrichtlinien und der Zertifikatregistrierungs-Webdienst konzentrieren sich auf automatisierte Zertifikatsanforderungen und die Bereitstellung von Zertifikaten unter Verwendung des nativen Clients. Zertifikatregistrierungs-Webdienste und CA Web Enrollment sind komplementäre Technologien. Die Zertifizierungsstelle-Webregistrierung unterstützt Zertifikatanforderungen und eine breite Palette von Clientbetriebssystemen. Die Zertifikatregistrierungs-Webdienste bieten automatische Anforderungen und die Bereitstellung von Zertifikaten für Client-Computer.