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

{:de}

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.

In environments that were formerly based on Small Business Server (SBS), many administrators encounter a seemingly mysterious problem: A freshly installed Certificate Authority (CA) on a new Windows Server refuses to issue certificates, even though the installation and setup appeared to complete without errors.

Especially in scenarios where old SBS structures still „echo“ within Active Directory, the modern security architecture of Windows Server 2025 can stumble.

In this article, we analyze a case where an RPC Error 1722 and an Invalid Pointer (0x80004003) blocked certificate issuance, and why the solution lay in the details of DCOM group membership.

The Situation

We are operating in a domain that originated on a Small Business Server.

• Old (Legacy): The SBS functioned as an „All-in-One“ solution: It was the Domain Controller (DC), Exchange Server, and Certificate Authority (CA) all in one. Remnants of this configuration (groups, attributes, etc.) still exist in Active Directory!
• New: A fresh Windows Server 2025 was joined to the domain as a Member Server. The Certificate Authority role was cleanly installed on this new server.

After setup, we attempted to request a certificate via the classic CA Web Enrollment portal (/certsrv) as well as via the local MMC. The process aborted immediately. Instead of an issued certificate, we received the following error message:

„Error in request… Result: Invalid Pointer 0x80004003 (E_POINTER) … CCertRequest::Submit: Invalid Pointer 0x80004003.“

In parallel, Event Logs and connection tests (e.g., using certutil) pointed to an RPC Error 1722 and missing DCOM permissions.

The Analysis: Why „Invalid Pointer“?

The error code 0x80004003 (E_POINTER) is a generic COM error. It occurs when an application expects a pointer to an object, but the pointer is null.

In the context of the Certificate Authority, this means: The Web Enrollment form attempts to call the CCertRequest::Submit method on the CA service via DCOM (Distributed Component Object Model). If the security check for this DCOM call fails, the connection is blocked before the service can return a valid result object. The web application receives „nothing“ back and interprets this as an invalid pointer.

The underlying cause is essentially not a software bug, but a permission issue.

The „SBS Legacy“ Effect

We checked the DCOM access groups on the new CA server (Windows Server 2025). This is where the problem was buried, hidden within the legacy burdens of the domain structure.

1. Standard on Member Servers: Normally, a CA uses the local group „Cert Service DCOM Access“. In a clean environment, the setup often adds „Authenticated Users“ and „Domain Computers“ to this group.
2. The Problem: Due to the domain’s history or strict historical presets, the access group only contained „Domain Users“.
3. The Gap: In an Active Directory domain, Domain Controllers (DCs) are not members of the „Domain Computers“ group. They have their own Organizational Unit and group („Domain Controllers“).

Since the CA consults AD (and thus the DCs) for certain checks, or because the DC itself initiated the request, the access failed due to missing permissions in the DCOM ACL.

The Problem with „Authenticated Users“

In a clean environment, the „Authenticated Users“ group is Best Practice and automatically includes DCs.

SBS Context: In old SBS domains, the user right „Access this computer from the network“ was often massively restricted via GPO, or the „Authenticated Users“ group was removed from permissions for hardening reasons. Therefore, „Authenticated Users“ often does not apply in this specific scenario.

Why not simply add the „Domain Controllers“ group?

This is where the peculiarity of the old SBS environment comes into play. In many cases, it is not sufficient to simply add the global „Domain Controllers“ group. Due to issues with GPO restrictions (User Rights Assignment) dating back to SBS times, permissions via the group are often not resolved correctly or quickly enough.

The solution was therefore explicit: Authorize the computer accounts of the Domain Controllers individually.

The Solution: Step-by-Step

To fix error 0x80004003 and RPC 1722, the DCOM rights on the CA server must be adjusted.

Important: Add the computer accounts of the DCs directly; do not rely on group nesting in old domain structures!

1. Open Computer Management (compmgmt.msc) on the new CA server.
2. Navigate to Local Users and Groups -> Groups.
3. Locate the group Cert Service DCOM Access (or „Zertifikatsdienste DCOM-Zugriff“ in German systems).
4. Click on Add, change the Object Type so that Computers are also searched.
5. Search for and add each of your Domain Controllers individually (e.g., DC01$, DC02$).
6. Optional, but recommended: Restart the server to ensure that all DCOM services load the new ACLs.

Certificate requests should now function immediately.

Note: In old SBS environments, the resolution of the ‚Domain Controllers‘ group is frequently observed to be unreliable. Therefore, explicitly adding the DC computer account represents the most robust solution.

Background: Why the Difference?

It helps to understand why SBS environments are so susceptible here:

Recommendation for Windows Server

Never operate your CA on a Domain Controller. Separating roles increases security and facilitates future migrations. However, if you are migrating from an old structure, always check the memberships of the local DCOM group first if errors occur. Error 0x80004003 in Web Enrollment is almost always an „Access Denied“ in DCOM disguise.