In der komplexen Welt der IT-Infrastruktur spielen Terminalserver-Umgebungen eine zentrale Rolle für viele Unternehmen. Windows Server 2016 Remote Desktop Services (RDS) bietet eine robuste Plattform für die Bereitstellung von Anwendungen und Desktops, doch hin und wieder stolpert man über knifflige Berechtigungsprobleme. Eines der häufigsten und frustrierendsten Szenarien ist die Situation, in der RDS-Komponenten, insbesondere der RD Connection Broker, nicht über die notwendigen Rechte verfügen, um Computerobjekte in Active Directory (AD) zu erstellen oder zu verwalten. Dieses Problem kann die Skalierung Ihrer RDS-Farm, die Bereitstellung neuer Session Hosts oder sogar die Funktionalität von virtuellen Desktop-Infrastrukturen (VDI) erheblich beeinträchtigen. Aber keine Sorge, dieses Rechteproblem ist lösbar, und wir zeigen Ihnen Schritt für Schritt, wie Sie es angehen können.
Warum benötigt RDS das Recht zum Erstellen von Computerobjekten?
Bevor wir uns in die technischen Details stürzen, ist es wichtig zu verstehen, warum dieses Recht überhaupt notwendig ist. Im Kern geht es darum, dass bestimmte RDS-Funktionen tief in die Domäneninfrastruktur eingreifen müssen. Hier sind die Hauptgründe:
- Hinzufügen neuer RD Session Hosts: Wenn Sie einen neuen Server als RD Session Host zu Ihrer RDS-Farm hinzufügen, muss dieser Server als Computerobjekt in Active Directory registriert werden. Während der Server selbst bei der Domänenaufnahme sein eigenes Objekt erstellt, kann es im Kontext einer RDS-Farm zu Szenarien kommen, in denen der RD Connection Broker oder ein anderer RDS-Dienst stellvertretend agieren muss, um Metadaten zu verwalten oder spezielle Konfigurationen am Computerobjekt vorzunehmen.
- Virtuelle Desktop-Infrastruktur (VDI): Dies ist der prominenteste Anwendungsfall. Bei der Bereitstellung von Pool-basierten oder persönlichen virtuellen Desktops erstellt der RD Connection Broker im Auftrag der RDS-Farm ständig neue virtuelle Maschinen. Jede dieser VMs benötigt ein eigenes Computerobjekt in Active Directory. Ohne die entsprechenden Berechtigungen kann der Broker diese VMs nicht erstellen oder ordnungsgemäß in die Domäne integrieren.
- Verwaltung von Computerkonten: Neben dem Erstellen kann es auch notwendig sein, bestehende Computerobjekte zu ändern (z.B. SPNs zu registrieren) oder zu löschen (z.B. beim Entfernen von VDI-Desktops oder Session Hosts aus der Farm).
Wenn diese Rechte fehlen, erhalten Sie in der Regel Fehlermeldungen in der Server-Manager-Konsole, in den Ereignisprotokollen des Connection Brokers oder auf den Domain Controllern, die auf „Zugriff verweigert” oder ähnliche Probleme hinweisen.
Wer benötigt die Rechte? Der Sicherheitskontext
Die entscheidende Frage ist: Welches Konto oder Objekt benötigt diese Berechtigungen? Es gibt zwei gängige Szenarien:
- Das Computerkonto des RD Connection Broker Servers: In den meisten Standardkonfigurationen von Windows Server 2016 RDS führt der RD Connection Broker die Operationen aus, die das Erstellen oder Modifizieren von Computerobjekten erfordern. Daher müssen die Berechtigungen dem Computerkonto des Servers, auf dem der RD Connection Broker läuft, erteilt werden. Das Format für ein Computerkonto ist `SERVERNAME$`, z.B. `RDSBROKER01$`.
- Ein dediziertes Dienstkonto: In manchen komplexeren Setups wird ein dediziertes Dienstkonto verwendet, um bestimmte RDS-Dienste auszuführen. Wenn dies bei Ihnen der Fall ist und dieses Dienstkonto die kritischen Operationen ausführt, muss dieses Benutzerkonto die Berechtigungen erhalten. Für die meisten Standardinstallationen ist jedoch das Computerkonto des Connection Brokers der richtige Adressat.
Wir konzentrieren uns in dieser Anleitung auf die häufigere Variante: die Zuweisung von Rechten an das Computerkonto des RD Connection Brokers.
Vorbereitung: Die richtige Organisationseinheit (OU) finden
Bevor Sie mit der Zuweisung von Berechtigungen beginnen, sollten Sie sich vergewissern, wo die Computerobjekte Ihrer RDS-Server (insbesondere der Session Hosts oder VDI-VMs) in Active Directory gespeichert sind oder gespeichert werden sollen. Es ist eine bewährte Methode, eine dedizierte Organisationseinheit (OU) für Ihre RDS-Server oder VDI-Desktops zu erstellen. Dies ermöglicht eine granulare Verwaltung von Gruppenrichtlinien und, was noch wichtiger ist, von Berechtigungen.
Nehmen wir an, Sie haben eine OU namens `OU=RDS-Server,DC=ihredomain,DC=local` erstellt oder planen, alle RDS-bezogenen Computerobjekte dort abzulegen. Diese OU wird das Ziel für unsere Berechtigungsänderungen sein.
Schritt-für-Schritt-Anleitung: Berechtigungen in Active Directory delegieren
Diese Anleitung führt Sie durch die notwendigen Schritte unter Verwendung der Active Directory-Benutzer und -Computer (ADUC)-Konsole.
1. Active Directory-Benutzer und -Computer öffnen
Melden Sie sich an einem Domain Controller oder einer Workstation mit installierten Remote Server Administration Tools (RSAT) an, die über die Berechtigung zum Ändern von Active Directory-Berechtigungen verfügt (z.B. als Domänen-Administrator).
- Öffnen Sie den Server-Manager.
- Gehen Sie zu
Tools->Active Directory-Benutzer und -Computer.
2. Erweiterte Funktionen aktivieren
Um die Sicherheitsregisterkarte einer OU zu sehen und granulare Berechtigungen zu konfigurieren, müssen Sie die erweiterten Funktionen aktivieren.
- Klicken Sie in ADUC auf
Ansichtin der Menüleiste. - Wählen Sie
Erweiterte Funktionenaus. Ein Häkchen sollte erscheinen.
3. Die Ziel-OU finden und Eigenschaften öffnen
Navigieren Sie im linken Bereich von ADUC zu der Organisationseinheit (OU), in der die Computerobjekte Ihrer RDS-Server oder VDI-Desktops gespeichert werden sollen.
- Rechtsklicken Sie auf diese OU (z.B. `RDS-Server`).
- Wählen Sie
Eigenschaften.
4. Zur Registerkarte „Sicherheit” wechseln
Im Eigenschaftenfenster der OU wechseln Sie zur Registerkarte Sicherheit. Hier werden alle Zugriffssteuerungslisten (ACLs) für diese OU verwaltet.
5. Das Computerkonto des RD Connection Brokers hinzufügen
Sie müssen nun das Computerkonto des RD Connection Broker Servers zur Liste der Prinzipale hinzufügen, die spezielle Berechtigungen erhalten sollen.
- Klicken Sie auf
Hinzufügen.... - Im Dialogfeld
Benutzer, Computer, Dienstkonten oder Gruppen auswählenklicken Sie aufObjekttypen.... - Stellen Sie sicher, dass
Computeraktiviert ist, und klicken Sie aufOK. - Geben Sie den Namen Ihres RD Connection Broker Servers ein, gefolgt von einem Dollarzeichen (
$) – z.B.RDSBROKER01$. - Klicken Sie auf
Namen überprüfen, um sicherzustellen, dass das Konto gefunden wird, und dann aufOK.
6. Spezifische Berechtigungen konfigurieren (erweitert)
Nachdem Sie das Computerkonto hinzugefügt haben, wählen Sie es in der Liste auf der Registerkarte Sicherheit aus. Anstatt „Volle Kontrolle” zu gewähren (was aus Sicherheitssicht nie empfehlenswert ist), konfigurieren wir granulare Berechtigungen.
- Klicken Sie auf
Erweitert. - Im Dialogfeld
Erweiterte Sicherheitseinstellungenklicken Sie aufHinzufügen.... - Klicken Sie auf
Prinzipal auswählenund wählen Sie erneut das Computerkonto des RD Connection Brokers (z.B. `RDSBROKER01$`) aus. - Im Bereich
Gilt für:wählen SieDiesen Objekt und alle untergeordneten Objekteoder, wenn verfügbar und Sie dies noch spezifischer haben möchten,Nur Computerobjekte(oft für VDI relevant). Die OptionDiesen Objekt und alle untergeordneten Objekteist meist ausreichend und sicher, wenn die OU nur für RDS-Server genutzt wird. - Im Bereich
Berechtigungenaktivieren Sie die folgenden Optionen:Computerobjekte erstellen(Das ist die primäre Berechtigung, die Sie suchen!)Computerobjekte löschen(Nützlich für die Bereinigung von Objekten, z.B. bei der Entfernung von VDI-VMs oder Session Hosts. Aktivieren Sie dies nur, wenn RDS diese Funktionalität benötigt.)Alle Eigenschaften lesenAlle Eigenschaften schreiben(Diese Berechtigung ist weitreichend, aber oft notwendig, damit der Broker zusätzliche Attribute der Computerobjekte verwalten kann. Überlegen Sie, ob spezifischere Schreibrechte ausreichend wären, z.B. „DnsHostName schreiben” und „ServicePrincipalName schreiben”, um das Prinzip der geringsten Rechte besser einzuhalten. Für einen unkomplizierten Start ist „Alle Eigenschaften schreiben” oft eine pragmatische Wahl.)Validiertes Schreiben an DNS-Hostnamen(wichtig für die DNS-Registrierung)Validiertes Schreiben an Dienstprinzipalnamen(wichtig für Kerberos-Authentifizierung und SPN-Registrierung)Passwort ändern(Manchmal erforderlich, wenn der Broker im Namen des Computers agiert.)
- Klicken Sie auf
OKin allen offenen Dialogfeldern, um die Änderungen zu speichern.
Alternative: Delegations-Assistent verwenden
Wenn Sie eine etwas einfachere (aber oft weniger granulare) Methode bevorzugen, können Sie auch den Delegations-Assistenten verwenden:
- Rechtsklicken Sie auf Ihre Ziel-OU (z.B. `RDS-Server`).
- Wählen Sie
Kontrolle delegieren.... - Klicken Sie auf
Weiter. - Klicken Sie auf
Hinzufügen...und fügen Sie das Computerkonto des RD Connection Brokers hinzu (z.B. `RDSBROKER01$`). Klicken Sie aufOKundWeiter. - Wählen Sie
Benutzerdefinierte Aufgabe zum Delegieren erstellenund klicken Sie aufWeiter. - Wählen Sie
Nur die folgenden Objekte im Ordneraus und aktivieren SieComputerobjekte. Klicken Sie aufWeiter. - Aktivieren Sie im Bereich
Berechtigungendie folgenden Optionen:Erstellen ausgewählter Objekte in diesem OrdnerLöschen ausgewählter Objekte in diesem Ordner(optional)Alle Eigenschaften lesenAlle Eigenschaften schreiben(optional, kann durch spezifischere Schreibrechte ersetzt werden)
- Klicken Sie auf
Weiterund dann aufFertigstellen.
Der Delegations-Assistent übersetzt diese Auswahl in die entsprechenden Berechtigungen auf der Sicherheitsregisterkarte. Es ist oft ein guter Ausgangspunkt, kann aber weniger spezifisch sein als die manuelle Konfiguration im Erweiterten Modus.
Testen und Verifizieren
Nachdem Sie die Berechtigungen konfiguriert haben, ist es Zeit, sie zu testen:
- Versuchen Sie, einen neuen RD Session Host zur Farm hinzuzufügen oder eine neue VDI-Sammlung bereitzustellen.
- Überprüfen Sie die Ereignisprotokolle auf dem RD Connection Broker und den Domain Controllern auf Erfolgs- oder Fehlermeldungen bezüglich der Erstellung von Computerobjekten.
- Stellen Sie sicher, dass die Active Directory-Replikation abgeschlossen ist, insbesondere wenn Sie die Änderungen an einem anderen Domain Controller vorgenommen haben als dem, mit dem der RDS-Broker kommuniziert (
repadmin /showreplkann hier hilfreich sein).
Sicherheitsüberlegungen und Best Practices
Die Zuweisung von Berechtigungen ist ein sicherheitsrelevanter Vorgang. Beachten Sie daher folgende Best Practices:
- Prinzip der geringsten Rechte (PoLP): Gewähren Sie nur die absolut notwendigen Berechtigungen. Vermeiden Sie „Volle Kontrolle” wo immer möglich. Die spezifischen Schreibrechte für DNS-Hostnamen und SPNs sind besser als „Alle Eigenschaften schreiben”, wenn die genaue Funktionalität bekannt ist.
- Dedizierte OU: Platzieren Sie Ihre RDS-Computerobjekte immer in einer dedizierten Organisationseinheit. Dies erleichtert nicht nur die Verwaltung, sondern auch die Anwendung von Berechtigungen und Gruppenrichtlinien, ohne andere Teile Ihrer Domäne zu beeinflussen.
- Scope: Wenden Sie die Berechtigungen nur auf die spezifische OU an, in der die Objekte erstellt werden sollen, und nicht auf die gesamte Domäne oder übergeordnete OUs.
- Dokumentation: Dokumentieren Sie genau, welche Berechtigungen Sie welchem Konto auf welcher OU gewährt haben. Dies ist entscheidend für die Fehlersuche und die Einhaltung von Sicherheitsrichtlinien.
- Regelmäßige Überprüfung: Überprüfen Sie regelmäßig die zugewiesenen Berechtigungen, um sicherzustellen, dass sie noch immer relevant und notwendig sind.
- Dienstkonten vs. Computerkonten: Wenn Sie dedizierte Dienstkonten für RDS-Rollen verwenden, stellen Sie sicher, dass diese korrekt identifiziert werden und die entsprechenden Rechte erhalten. Im Kontext der Computerobjekterstellung ist jedoch das Computerkonto des Connection Brokers der häufigste Kandidat.
Häufige Fehlerbehebungen
Sollten nach der Konfiguration immer noch Probleme auftreten, prüfen Sie Folgendes:
- Replikationsverzögerungen: Warten Sie auf die vollständige Active Directory-Replikation.
- Falsche OU: Haben Sie die Berechtigungen auf der richtigen Organisationseinheit gesetzt, in der die Computerobjekte tatsächlich erstellt werden?
- Falscher Prinzipal: Haben Sie das richtige Computerkonto (
SERVERNAME$) oder Dienstkonto hinzugefügt? - Erweiterte Funktionen: Haben Sie die erweiterten Funktionen in ADUC aktiviert, um alle Optionen zu sehen und die Berechtigungen korrekt zu setzen?
- Ereignisprotokolle: Überprüfen Sie die Sicherheitsereignisprotokolle auf dem Domain Controller und die System-/Anwendungsprotokolle auf dem RD Connection Broker für detailliertere Fehlermeldungen.
- DNS-Probleme: Stellen Sie sicher, dass die DNS-Auflösung korrekt funktioniert.
Fazit
Das Problem, dass Windows Server 2016 RDS keine Computerobjekte in Active Directory erstellen kann, ist ein häufiges Hindernis in vielen Implementierungen. Durch das Verständnis des Bedarfs und die sorgfältige Anwendung der richtigen Berechtigungen auf das Computerkonto Ihres RD Connection Brokers in der entsprechenden Organisationseinheit können Sie dieses Problem effektiv lösen. Denken Sie immer daran, das Prinzip der geringsten Rechte zu beachten und Ihre Änderungen zu dokumentieren, um eine sichere, stabile und effiziente Remote Desktop Services-Umgebung zu gewährleisten. Mit dieser detaillierten Anleitung sollten Sie in der Lage sein, Ihre RDS-Farm reibungslos zu betreiben und zu skalieren.