Fehlende Berechtigung? Welches Recht zum Erstellen von Computerobjekten für Windows Server 2016 RDS benötigt wird

**Einleitung: Das Herzstück Ihrer RDS-Infrastruktur und ein häufiges Stolpern**

Stellen Sie sich vor, Sie sind dabei, Ihre Windows Server 2016 Remote Desktop Services (RDS)-Infrastruktur einzurichten oder zu erweitern. Alles läuft scheinbar reibungslos, bis plötzlich eine Fehlermeldung auftaucht, die besagt, dass ein **Computerobjekt** nicht erstellt werden kann. Frustration macht sich breit. Welches Recht fehlt hier? Warum kann der Server oder das Installationskonto nicht einfach das tun, was es tun soll? Diese Situation ist leider alles andere als selten und kann selbst erfahrene Administratoren vor ein Rätsel stellen. In diesem umfassenden Artikel tauchen wir tief in die Materie ein und beleuchten genau, welches **Active Directory**-Recht benötigt wird, um **Computerobjekte** für Ihre **Windows Server 2016 RDS**-Bereitstellung erfolgreich zu erstellen und zu verwalten. Unser Ziel ist es, Ihnen nicht nur die technische Lösung zu präsentieren, sondern auch ein tiefgreifendes Verständnis für die zugrunde liegenden Mechanismen zu vermitteln, damit Sie solche Probleme in Zukunft proaktiv vermeiden können.

**RDS und die Bedeutung von Computerobjekten: Eine notwendige Symbiose**

Bevor wir uns den spezifischen Berechtigungen widmen, ist es wichtig zu verstehen, warum **Computerobjekte** in einer **RDS**-Umgebung überhaupt so eine zentrale Rolle spielen. Windows Server Remote Desktop Services ermöglichen es Benutzern, remote auf Anwendungen oder ganze Desktops zuzugreifen, die auf einem Server ausgeführt werden. Eine typische **RDS**-Bereitstellung besteht aus mehreren Rollendiensten, darunter der **Verbindungsbroker** (Connection Broker), der Web Access, die Lizenzierung und die Sitzungshost-Server.

Jeder Server, der Teil einer **RDS**-Farm ist, insbesondere die Remote Desktop Session Host (RDSH)-Server, muss ein eigenes **Computerobjekt** in **Active Directory** haben. Diese Objekte dienen nicht nur der reinen Inventarisierung, sondern sind fundamental für:

* **Authentifizierung und Autorisierung:** Kerberos, das primäre Authentifizierungsprotokoll in einer Windows-Domäne, verwendet **Computerobjekte**. Ohne ein gültiges Objekt kann der Server nicht ordnungsgemäß authentifiziert werden, was den Zugriff auf Ressourcen und die Teilnahme an der Domäne behindert.
* **Gruppenrichtlinien (GPOs):** GPOs werden auf **Computerobjekte** angewendet, um Sicherheitseinstellungen, Softwareverteilung, Anmeldeskripte und andere Konfigurationen für die **RDS**-Server zu steuern. Dies ist entscheidend für eine homogene und sichere Umgebung.
* **Netzwerkzugriff:** Firewall-Regeln, DNS-Registrierungen und andere netzwerkbezogene Einstellungen sind oft an das **Computerobjekt** gebunden.
* **Farm-Management durch den Verbindungsbroker:** Der **Verbindungsbroker** ist das Gehirn der **RDS**-Farm. Er muss in der Lage sein, neue Session Hosts zur Farm hinzuzufügen, deren Status zu überwachen und Benutzerverbindungen auf die verfügbaren Server zu verteilen. Für diese Operationen benötigt der **Verbindungsbroker** (bzw. genauer gesagt, dessen Computerobjekt oder das Installationskonto) die notwendigen Rechte zur Interaktion mit den **Computerobjekten** der Session Hosts.

Fehlt die Berechtigung zur Erstellung dieser Objekte, stoppt der Bereitstellungsprozess oft mit einer kryptischen Fehlermeldung, die nicht direkt auf die fehlende **Active Directory**-Berechtigung hinweist, sondern eher auf einen allgemeinen „Zugriffsfehler” oder das „Fehlgeschlagen des Hinzufügens eines Servers zur Farm”.

**Die Wurzel des Problems: Wer braucht welches Recht?**

Wenn Sie eine **Windows Server 2016 RDS**-Bereitstellung durchführen, insbesondere wenn Sie neue Session Hosts zu einer bestehenden Farm hinzufügen oder eine neue Farm von Grund auf aufbauen, müssen im Hintergrund **Computerobjekte** in **Active Directory** erstellt oder modifiziert werden. Die zentrale Frage ist nun: Welches Konto versucht, diese Aktion durchzuführen, und auf welcher Ebene benötigt dieses Konto welche **Berechtigungen**?

Grundsätzlich gibt es zwei Szenarien:

1. **Der Installationsprozess:** Wenn Sie die **RDS**-Rollen manuell über den Server-Manager oder PowerShell installieren, ist es das Benutzerkonto, mit dem Sie angemeldet sind, das die Aktion ausführt. Dieses Konto benötigt die **Berechtigungen**.
2. **Der RDS-Verbindungsbroker:** In einer Farm-Umgebung ist der **Verbindungsbroker** (Connection Broker) für die Verwaltung der Session Hosts verantwortlich. Wenn der **Verbindungsbroker** im Rahmen seiner Funktionen versucht, einen neuen Session Host zu verwalten oder hinzuzufügen, geschieht dies unter dem Kontext seines eigenen Computerobjekts. Genauer gesagt, die Computerobjekte der **Verbindungsbroker**-Server (z.B. `RDSCB01$`) benötigen die erforderlichen Rechte in **Active Directory**. Dies ist ein häufiger Fallstrick, da Administratoren oft an Benutzerkonten denken und das Computerobjekt des **Verbindungsbrokers** übersehen.

Die Fehlermeldungen können variieren, sind aber oft generisch:
* „Unable to add the specified server to the server pool.” (Der angegebene Server konnte dem Serverpool nicht hinzugefügt werden.)
* „Error during post-installation configuration of roles.” (Fehler während der Nachinstallationskonfiguration der Rollen.)
* „Access Denied” (Zugriff verweigert) im Kontext der **RDS**-Bereitstellung.
* Im Event Log (Ereignisprotokoll) auf dem **Verbindungsbroker** oder dem betreffenden Session Host könnten Sie Einträge finden, die auf LDAP-Fehler oder fehlende **Berechtigungen** beim Zugriff auf **Active Directory** hinweisen.

**Das spezifische Recht: „Computerobjekte erstellen” (Create Computer Objects)**

Das entscheidende Recht, das benötigt wird, ist die **Berechtigung** zum „Erstellen von **Computerobjekten**” (Create Computer objects) in der Organisationseinheit (**OU**) oder dem Container, in dem die **Computerobjekte** der **RDS**-Server (insbesondere der RDSH-Server) erstellt werden sollen.

Dieses Recht muss dem Konto gewährt werden, das die Operation ausführt:
* Entweder dem **Benutzerkonto**, das die **RDS**-Rollen installiert und die Farm konfiguriert.
* Oder dem **Computerobjekt des **Verbindungsbrokers****, wenn der **Verbindungsbroker** selbst (nach der initialen Installation) versucht, weitere Session Hosts hinzuzufügen oder zu verwalten. Dies ist der häufigere und wichtigere Fall in Produktionsumgebungen.

Es ist nicht ausreichend, nur „Create all child objects” zu haben; die explizite **Berechtigung** „Create Computer objects” ist spezifischer und direkter. Zusätzlich zu diesem Recht können auch `Write All Properties` und `Read All Properties` für die Computerobjekte innerhalb dieser **OU** nützlich sein, um eine vollständige Verwaltung durch den **Verbindungsbroker** zu gewährleisten. Diese erweiterten Rechte ermöglichen es dem **Verbindungsbroker**, Attribute der **Computerobjekte** wie z.B. DNS-Einträge oder Service Principal Names (SPNs) zu lesen und zu schreiben, was für Kerberos und andere Dienstregistrierungen wichtig ist.

**Schritt-für-Schritt-Anleitung: Gewähren der erforderlichen Berechtigung**

Das Gewähren dieser **Berechtigung** ist ein Standardprozess in **Active Directory**-Benutzer und -Computer. Gehen Sie wie folgt vor:

1. **Identifizieren Sie die Ziel-OU:**
Wählen Sie die Organisationseinheit (**OU**) in **Active Directory** aus, in der Ihre **RDS**-Server (insbesondere die Session Hosts) Mitglieder sein sollen. Es ist eine bewährte Praxis und aus Gründen der **Sicherheit** dringend empfohlen, eine separate **OU** für Ihre **RDS**-Server zu erstellen, z.B. „OU=RDS-Server,DC=IhreDomäne,DC=local”.

2. **Öffnen Sie „Active Directory-Benutzer und -Computer”:**
Melden Sie sich an einem Domänencontroller oder einem Management-Server mit den RSAT-Tools an, der über die erforderlichen **Active Directory**-Admin-Rechte verfügt. Öffnen Sie `dsa.msc`.

3. **Aktivieren Sie „Erweiterte Funktionen” (falls nicht geschehen):**
Gehen Sie im Menü auf `Ansicht` und stellen Sie sicher, dass `Erweiterte Funktionen` aktiviert ist. Dies ist notwendig, um die erweiterten **Berechtigungen** sehen und bearbeiten zu können.

4. **Navigieren Sie zur Ziel-OU:**
Finden Sie die **OU**, die Sie in Schritt 1 identifiziert haben (z.B. „RDS-Server”).

5. **Öffnen Sie die Sicherheitseinstellungen der OU:**
Klicken Sie mit der rechten Maustaste auf die **OU** und wählen Sie `Eigenschaften`. Wechseln Sie zur Registerkarte `Sicherheit`.

6. **Erweiterte Sicherheitseinstellungen:**
Klicken Sie auf `Erweitert`.

7. **Fügen Sie das erforderliche Konto hinzu:**
Klicken Sie auf `Hinzufügen`.
* **Für das Benutzerkonto des Installers (initiale Einrichtung):** Geben Sie den Namen des Benutzerkontos ein, das die **RDS**-Bereitstellung durchführt (z.B. `DomainAdminUser` oder ein delegiertes Installationskonto).
* **Für den **Verbindungsbroker** (Farm-Management):** Dies ist der kritischere Fall. Geben Sie den Namen des **Computerobjekts** des **RDS**-**Verbindungsbrokers** ein. Dies muss im Format `SERVERNAME$` erfolgen (z.B. `RDSCB01$`). Klicken Sie auf `Objekttypen` und stellen Sie sicher, dass `Computer` ausgewählt ist, bevor Sie auf `Namen überprüfen` klicken.

8. **Wählen Sie die Berechtigungen aus:**
Nachdem Sie das Konto hinzugefügt haben, sollte es in der Liste der Sicherheitsprinzipale erscheinen. Wählen Sie es aus und klicken Sie auf `Bearbeiten` oder fügen Sie es direkt hinzu.
* Stellen Sie sicher, dass der `Gilt für`-Wert auf `Dieses Objekt und alle untergeordneten Objekte` eingestellt ist (für die meisten Szenarien). In manchen, sehr spezifischen Fällen, wo nur die Erstellung in der **OU** erlaubt werden soll, könnte auch `Dieses Objekt selbst` reichen, aber `Dieses Objekt und alle untergeordneten Objekte` ist oft sicherer, um auch die Rechte auf den später erstellten Computerobjekten zu verwalten.
* Aktivieren Sie das Kontrollkästchen für die **Berechtigung**: `Computerobjekte erstellen` (Create Computer objects).
* **Zusätzlich empfohlen:** Für eine reibungslose Verwaltung durch den **Verbindungsbroker** sollten Sie auch die Rechte `Alle Eigenschaften lesen` (Read All Properties) und `Alle Eigenschaften schreiben` (Write All Properties) aktivieren. Diese sollten in der Regel für `Untergeordnete Computerobjekte` gelten, um dem **Verbindungsbroker** die volle Kontrolle über die Metadaten der Session Host-**Computerobjekte** zu ermöglichen. Prüfen Sie, ob diese für `Untergeordnete Computerobjekte` oder `Dieser und alle untergeordneten Objekte` gesetzt sind.

9. **Bestätigen und Anwenden:**
Klicken Sie auf `OK`, um die Änderungen zu speichern. Es kann einige Zeit dauern, bis die Änderungen durch **Active Directory** repliziert werden, insbesondere in größeren Umgebungen.

**Best Practices und Sicherheitshinweise**

Das Gewähren von **Active Directory**-**Berechtigungen** ist ein kritischer Vorgang, der mit Bedacht vorgenommen werden sollte. Hier sind einige bewährte Methoden und **Sicherheitshinweise**:

* **Prinzip der geringsten Privilegien (Least Privilege):** Gewähren Sie niemals mehr **Berechtigungen** als absolut notwendig. Vermeiden Sie es, das Installationskonto oder das **Verbindungsbroker**-Computerobjekt zu Domain-Admins zu machen, nur um dieses Problem zu umgehen. Die oben beschriebene Methode der spezifischen **Delegierung** ist der richtige Weg.
* **Dedizierte OU für RDS-Server:** Erstellen Sie immer eine eigene **OU** für Ihre **RDS**-Server. Dies ermöglicht eine granulare Steuerung von **Berechtigungen** und Gruppenrichtlinien, die nur auf diese Server angewendet werden.
* **Verwenden Sie Sicherheitsgruppen:** Anstatt individuelle Benutzer- oder Computerkonten direkt zu berechtigen, erstellen Sie eine Sicherheitsgruppe (z.B. „SG_RDS_Admin_Rechte”) und weisen Sie dieser Gruppe die **Berechtigungen** zu. Fügen Sie dann die erforderlichen Benutzer- oder Computerkonten dieser Gruppe hinzu. Dies vereinfacht die Verwaltung und Überwachung erheblich. Für den **Verbindungsbroker** kann es jedoch manchmal direkter sein, das Computerobjekt direkt zu berechtigen, wenn nur ein CB existiert. Bei mehreren CBs oder zur besseren Übersicht ist eine Gruppe für die CBs (wenn sie in einer dedizierten **OU** sind) eine gute Option.
* **Regelmäßige Audits:** Überprüfen Sie regelmäßig die **Berechtigungen** für Ihre **OU**s und kritischen Objekte in **Active Directory**, um sicherzustellen, dass keine unnötigen oder übermäßigen Rechte vorhanden sind.
* **Dokumentation:** Dokumentieren Sie alle gewährten **Berechtigungen**, ihre Zwecke und die betroffenen Konten. Dies ist unerlässlich für die Fehlerbehebung und Compliance.
* **Replikation:** Bedenken Sie, dass **Active Directory**-Änderungen Zeit zur Replikation benötigen. Wenn Sie die **Berechtigung** auf einem Domänencontroller gewähren, muss diese Änderung möglicherweise erst auf den Domänencontroller repliziert werden, den der **RDS**-Server oder **Verbindungsbroker** kontaktiert.

**Häufige Fallstricke und Troubleshooting-Tipps**

Selbst nach der korrekten Zuweisung der **Berechtigungen** kann es zu Problemen kommen. Hier sind einige Punkte, die Sie überprüfen sollten:

* **Replikation überprüfen:** Verwenden Sie `repadmin /showrepl` oder `dcdiag` auf Ihren Domänencontrollern, um sicherzustellen, dass die **Active Directory**-Änderungen vollständig repliziert wurden.
* **Domänencontroller-Verbindung:** Stellen Sie sicher, dass der **RDS**-Server oder der **Verbindungsbroker** den Domänencontroller erreichen kann, auf dem die **Berechtigungen** wirksam sind, und diesen auch für seine LDAP-Anfragen verwendet.
* **Caches löschen:** Manchmal hilft es, den **RDS**-Server oder den **Verbindungsbroker** neu zu starten, um eventuell vorhandene Cache-Einträge für **Berechtigungen** zu aktualisieren.
* **Event Logs überprüfen:** Die Ereignisprotokolle (insbesondere Security, System und Application Logs) auf dem **Verbindungsbroker** und den zukünftigen Session Hosts können wertvolle Hinweise auf die genaue Ursache des Problems geben. Suchen Sie nach Fehlern im Zusammenhang mit **Active Directory**, LDAP oder Zugriff verweigert.
* **Test mit `dsadd computer`:** Sie können manuell versuchen, ein **Computerobjekt** in der problematischen **OU** mit dem gleichen Benutzerkonto zu erstellen, das Sie für die **RDS**-Installation verwenden. Öffnen Sie eine administrative PowerShell oder CMD und führen Sie aus: `dsadd computer „CN=TestComputer,OU=IhreOU,DC=IhreDomäne,DC=local”`. Wenn dies fehlschlägt, liegt das Problem definitiv bei den **Berechtigungen** des Kontos auf der **OU**.

**Zusammenfassung und Fazit**

Die erfolgreiche Bereitstellung einer **Windows Server 2016 RDS**-Umgebung hängt von vielen Faktoren ab, und eine korrekte Konfiguration der **Active Directory**-**Berechtigungen** ist dabei von entscheidender Bedeutung. Die Fehlermeldung bezüglich des Nicht-Erstellens von **Computerobjekten** ist ein klassisches Beispiel dafür, wie ein scheinbar kleines Detail große Auswirkungen haben kann.

Das Verständnis, dass nicht nur das Installationskonto, sondern in einer laufenden Farm vor allem das **Computerobjekt des **RDS**-**Verbindungsbrokers**** das Recht `Computerobjekte erstellen` und erweiterte Rechte wie `Alle Eigenschaften lesen` und `Alle Eigenschaften schreiben` auf der Ziel-**OU** benötigt, ist der Schlüssel zur Lösung dieses Problems. Durch die bewusste **Delegierung** dieser spezifischen Rechte, die Einhaltung von Best Practices und eine sorgfältige Fehlerbehebung können Sie Ihre **RDS**-Infrastruktur effizient und sicher aufbauen und erweitern. Denken Sie immer daran: Granulare **Berechtigungen** sind der Eckpfeiler einer robusten und sicheren IT-Umgebung. Mit den Informationen aus diesem Artikel sind Sie nun bestens gerüstet, um diese Herausforderung zu meistern und Ihre **RDS**-Bereitstellung erfolgreich abzuschließen.