Windows Server CA: RPC-Fehler 1722 & „Ungültiger Zeiger“ (0x80004003)

In ehemaligen Small Business Server (SBS) Umgebungen stoßen viele Administratoren auf ein scheinbar mysteriöses Problem: Eine frisch installierte Certificate Authority (CA) auf einem neuen Windows Server verweigert die Zertifikatsausstellung, obwohl die Installation und Einrichtung davor fehlerfrei durchgelaufen ist.

Besonders in Szenarien, in denen die alten SBS-Strukturen im Active Directory noch „nachhallen“, kann die moderne Architektur eines Windows Server 2025 ins Stolpern geraten.

In diesem Artikel analysieren wir den Fall, bei dem ein RPC-Fehler 1722 und ein ungültiger Zeiger (0x80004003) die Ausstellung von Zertifikaten blockierten, und warum die Lösung im Detail der DCOM-Gruppenmitgliedschaft lag.

Die Ausgangslage

Wir bewegen uns in einer Domäne, die ihren Ursprung auf einem Small Business Server hatte.

• Alt (Legacy): Der SBS fungierte als „All-in-One“-Lösung: Er war Domänencontroller (DC), Exchange-Server und Zertifizierungsstelle (CA) in einem. Reste dieser Konfiguration (Gruppen, Attribute, etc.) sind noch im Active Directory enthalten!
• Neu: Ein frischer Windows Server 2025 wurde als Mitgliedsserver in die Domäne aufgenommen. Die Rolle der Zertifizierungsstelle wurde dort sauber neu installiert.

Nach der Einrichtung versuchten wir, über das klassische CA-Webportal (/certsrv) wie auch über die lokale MMC ein Zertifikat anzufordern. Der Vorgang brach sofort ab. Statt eines ausgestellten Zertifikats erhielten wir folgende Fehlermeldung:

„Fehler bei der Anforderung… Ergebnis: Ungültiger Zeiger 0x80004003 (E_POINTER) … CCertRequest::Submit: Ungültiger Zeiger 0x80004003.“

Parallel dazu wiesen Eventlogs und Tests (z. B. via certutil) auf einen RPC-Fehler 1722 und fehlende DCOM-Rechte hin.

Die Analyse: Warum „Ungültiger Zeiger“?

Der Fehlercode 0x80004003 (E_POINTER) ist ein generischer COM-Fehler. Er tritt auf, wenn eine Anwendung einen Zeiger auf ein Objekt erwartet, dieser aber null ist.

Im Kontext der Zertifizierungsstelle bedeutet das: Das Web-Enrollment-Formular versucht, via DCOM (Distributed Component Object Model) die Methode CCertRequest::Submit auf dem CA-Dienst aufzurufen. Schlägt die Sicherheitsüberprüfung für diesen DCOM-Aufruf fehl, wird die Verbindung blockiert, bevor der Dienst ein gültiges Antwortobjekt zurückgeben kann. Die Webanwendung erhält „nichts“ zurück und interpretiert dies als ungültigen Zeiger.

Die eigentliche Ursache ist also kein Softwarefehler, sondern ein Berechtigungsproblem.

Der „SBS-Legacy“-Effekt

AuAuf dem neuen CA-Server (Windows Server 2025) prüften wir die DCOM-Zugriffsgruppen. Hier lag das Problem begraben, versteckt in den Altlasten der Domänenstruktur.

1. Standard auf Member-Servern: Normalerweise nutzt eine CA die lokale Gruppe „Certificate Service DCOM Access“. In einer sauberen Umgebung fügt das Setup dort oft „Authenticated Users“ und „Domain Computers“ hinzu.
2. Das Problem: Durch die Historie der Domäne oder strikte Voreinstellungen waren in der Zugriffsgruppe nur „Domain Users“ enthalten.
3. Die Lücke: In einer Active Directory Domäne sind Domänencontroller (DCs) nicht Mitglied der Gruppe „Domain Computers“. Sie haben ihre eigene Organisationseinheit und Gruppe („Domain Controllers“).

Da die CA für bestimmte Prüfungen Rücksprache mit dem AD (und damit den DCs) hält, scheiterte der Zugriff an der fehlenden Berechtigung in der DCOM-ACL.

Das Problem mit „Authenticated Users“

In einer sauberen Umgebung ist die Gruppe „Authenticated Users“ (Authentifizierte Benutzer) Best Practice und enthält automatisch auch die DCs.

SBS-Kontext: In alten SBS-Domänen wurde oft via GPO das Recht „Auf diesen Computer vom Netzwerk aus zugreifen“ massiv eingeschränkt oder die Gruppe „Authentifizierte Benutzer“ aus Sicherheitsgründen entfernt (Härtung). Daher greift „Authenticated Users“ in diesem speziellen Szenario oft nicht.

Warum nicht einfach die Gruppe „Domänencontroller“ hinzufügen?

Hier kommt die Besonderheit der alten SBS-Umgebung ins Spiel. In vielen Fällen reicht es nicht aus, einfach die globale Gruppe „Domain Controllers“ hinzuzufügen. Aufgrund von Problemen bei GPO-Einschränkungen (User Rights Assignment) aus SBS-Zeiten wird die Berechtigung über die Gruppe oft nicht korrekt oder schnell genug aufgelöst.

Die Lösung war daher explizit: Die Computerkonten der Domänencontroller einzeln berechtigen.

Die Lösung: Schritt-für-Schritt

Um den Fehler 0x80004003 und RPC 1722 zu beheben, müssen die DCOM-Rechte auf dem CA-Server angepasst werden.

Wichtig: Fügen Sie die Computerkonten der DCs direkt hinzu, verlassen Sie sich in alten Domänenstrukturen nicht auf die Gruppenverschachtelung!

1. Öffnen Sie auf dem neuen CA-Server die Computerverwaltung (compmgmt.msc).
2. Navigieren Sie zu Lokale Benutzer und Gruppen -> Gruppen.
3. Suchen Sie die Gruppe Cert Service DCOM Access (bzw. „Zertifikatsdienste DCOM-Zugriff“).
4. Klicken Sie auf Hinzufügen, ändern Sie den Objekttyp, sodass auch Computer gesucht werden.
5. Suchen und fügen Sie nun jeden Ihrer Domänencontroller einzeln hinzu (z. B. DC01$, DC02$).
6. Optional, aber empfohlen: Starten Sie den Server neu, um sicherzugehen, dass alle DCOM-Dienste die neuen ACLs laden.

Zertifikatsanforderungen sollten nun sofort funktionieren.

Hinweis: In alten SBS-Umgebungen ist oft zu beobachten, dass die Auflösung der Gruppe ‚Domänencontroller‘ unzuverlässig ist, weshalb der direkte Eintrag des DC-Computerkontos die robusteste Lösung darstellt.

Hintergrund: Warum dieser Unterschied?

Es hilft zu verstehen, warum SBS-Umgebungen hier so anfällig sind:

Empfehlung für Windows Server

Betreiben eine CA niemals auf einem Domänencontroller. Die Trennung der Rollen erhöht die Sicherheit und erleichtert spätere Migrationen. Wenn jedoch man von einer alten Struktur migriert, prüfe bei Fehlern immer zuerst die Mitgliedschaften der lokalen DCOM-Gruppe. Der Fehler 0x80004003 im Web Enrollment ist fast immer ein „Access Denied“ im DCOM-Gewand.