6
Hauptbenutzerrechte für User am Terminalserver, der auch DC ist
auf einem Windows Server 2003, der als Terminalserver arbeitet müssen die User Hauptbenutzerrechte haben.
Dies erfordert die Client-Anwendung.
Wäre es ein Mitgliedsserver würde ich die entsprechende Domänengruppe (Domänen-Benutzer) in die Lokale Gruppe Hauptbenutzer aufnehmen. Damit wäre das Problem gelöst.
Unglücklicherweise ist der Server aber auch ein Domaincontroller, somit gibt es keine lokalen Gruppen! Wie kann man das Probem auf Domänenebene lösen? Lässt sich das per GPO umsetzen? In der Domäne gibt es keine solche Gruppe!
Hat jemand eine Idee?
mfg Thomas E.
Dies erfordert die Client-Anwendung.
Wäre es ein Mitgliedsserver würde ich die entsprechende Domänengruppe (Domänen-Benutzer) in die Lokale Gruppe Hauptbenutzer aufnehmen. Damit wäre das Problem gelöst.
Unglücklicherweise ist der Server aber auch ein Domaincontroller, somit gibt es keine lokalen Gruppen! Wie kann man das Probem auf Domänenebene lösen? Lässt sich das per GPO umsetzen? In der Domäne gibt es keine solche Gruppe!
Hat jemand eine Idee?
mfg Thomas E.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72758
Url: https://administrator.de/forum/hauptbenutzerrechte-fuer-user-am-terminalserver-der-auch-dc-ist-72758.html
Ausgedruckt am: 23.12.2024 um 14:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
ich trau mich zwar ungern an diese Fragestellung heran, antworte aber trotzdem mal:
Ein DC als Terminalserver mit Usern, die Hauptbenutzerrechte haben, ist in meinen Augen ein No-Go. Ihr solltet Euch einen zweiten Server beschaffen und diesen zum dedizierten Terminalserver machen.
Wahrscheinlich habt Ihr nur ein geringes Budget und das ist das nicht die Antwort, die Du haben möchtest, daher hier eine zweite:
Du könntest es per Policy machen oder aber auch erstmal mit Setzen von Schreibrechten auf der Platte.
Policy
Benutze am besten die GPMC. Erstelle eine Kopie der Default Domain Controllers Policy. Diese gilt für Euren DC. Erstell eine Testgruppe mit erst einmal einem Testaccount und ordne diese der Policy mit "Lesen durch Sicherheitsfilterung" zu, so daß Mitglieder dieser Testgruppe die Policy beim Anmelden ziehen.
Ändere diese Policy so ab, daß der Testaccount so eingeschränkt wird , daß er die gleichen Rechte hat, die ein Hauptbenutzer hätte (soweit ich es ermessen kann, geht das leider nur zu Fuß, da Ihr ja, wie Du bereits erwähntest, keine lokalen Gruppen habt). Ich würde den Testaccount erst einmal wie einen normalen Benutzer mit sehr eingeschränkten Rechten berechtigen und an den benötigten Stellen dann die Policy soweit aufbohren, daß die Anwendung läuft. Wenn die Anwendung irgendwann läuft und die Policy fertig ist, kannst Du die Anwender in eine globale Domänengruppe packen und statt des Testaccounts diese mit "Lesen durch Sicherheitsfilterung" zuweisen.
Schreibrechte
Vielleicht geht es aber auch einfacher - sollte die Anwendung nämlich nur Schreibrechte im lokalen Programmverzeichnis benötigen (dies ist meist der Fall), dann würde das Setzen von Schreibrechten für die entsprechenden Benutzer (über eine globale Gruppe) auf dem Programmverzeichnis ausreichen. Falls das funktioniert, dann würde ich es wahrscheinlich eher so machen.
Gruß,
fritzo
ich trau mich zwar ungern an diese Fragestellung heran, antworte aber trotzdem mal:
Ein DC als Terminalserver mit Usern, die Hauptbenutzerrechte haben, ist in meinen Augen ein No-Go. Ihr solltet Euch einen zweiten Server beschaffen und diesen zum dedizierten Terminalserver machen.
Wahrscheinlich habt Ihr nur ein geringes Budget und das ist das nicht die Antwort, die Du haben möchtest, daher hier eine zweite:
Du könntest es per Policy machen oder aber auch erstmal mit Setzen von Schreibrechten auf der Platte.
Policy
Benutze am besten die GPMC. Erstelle eine Kopie der Default Domain Controllers Policy. Diese gilt für Euren DC. Erstell eine Testgruppe mit erst einmal einem Testaccount und ordne diese der Policy mit "Lesen durch Sicherheitsfilterung" zu, so daß Mitglieder dieser Testgruppe die Policy beim Anmelden ziehen.
Ändere diese Policy so ab, daß der Testaccount so eingeschränkt wird , daß er die gleichen Rechte hat, die ein Hauptbenutzer hätte (soweit ich es ermessen kann, geht das leider nur zu Fuß, da Ihr ja, wie Du bereits erwähntest, keine lokalen Gruppen habt). Ich würde den Testaccount erst einmal wie einen normalen Benutzer mit sehr eingeschränkten Rechten berechtigen und an den benötigten Stellen dann die Policy soweit aufbohren, daß die Anwendung läuft. Wenn die Anwendung irgendwann läuft und die Policy fertig ist, kannst Du die Anwender in eine globale Domänengruppe packen und statt des Testaccounts diese mit "Lesen durch Sicherheitsfilterung" zuweisen.
Schreibrechte
Vielleicht geht es aber auch einfacher - sollte die Anwendung nämlich nur Schreibrechte im lokalen Programmverzeichnis benötigen (dies ist meist der Fall), dann würde das Setzen von Schreibrechten für die entsprechenden Benutzer (über eine globale Gruppe) auf dem Programmverzeichnis ausreichen. Falls das funktioniert, dann würde ich es wahrscheinlich eher so machen.
Gruß,
fritzo
Da stimme ich fritzo zu... das ist echt etwas das nciht geht. Stell dir doch mal vor... die standard user die man in jeder Firma hat, die einfach keinen 100%igen Plan haben wie ein Windows-System funktioniert. Willst du solche User mit Power-User Rechten einfach auf einen eurer wichtigsten Server loslassen?
Ich würde dir vorschlagen dafür einen eigenen Server zu verwenden... bei dem es auch nicht so schlimm ist wenn die User mal was "kaputt machen".
Verwenden die Leute die darauf arbeiten werden auch Office Produkte wie Outllok auf dem Terminal Server? Weil wenn ja... jetzt stell dir mal vor ein Anwender öffnet da in der Terminal-Server Session eine virenverseuchte Mail... na da wirste dann richtig Spass haben. ;)
Würde lieber versuchen deinem Chef die Gelder für nen System als TerminalServer aus dem Kreuz zu leidern, als das ich dann irgendwann mal nen ganzes Wochenende da sitze und versuche die AD wieder irgendwie zu rekonstruieren.
Gruß
Folkskygg
Ich würde dir vorschlagen dafür einen eigenen Server zu verwenden... bei dem es auch nicht so schlimm ist wenn die User mal was "kaputt machen".
Verwenden die Leute die darauf arbeiten werden auch Office Produkte wie Outllok auf dem Terminal Server? Weil wenn ja... jetzt stell dir mal vor ein Anwender öffnet da in der Terminal-Server Session eine virenverseuchte Mail... na da wirste dann richtig Spass haben. ;)
Würde lieber versuchen deinem Chef die Gelder für nen System als TerminalServer aus dem Kreuz zu leidern, als das ich dann irgendwann mal nen ganzes Wochenende da sitze und versuche die AD wieder irgendwie zu rekonstruieren.
Gruß
Folkskygg
Hauptbenutzer auf dem DC geht garnicht.
Aber warum benötigen die User Hauptbenutzer rechte?
Aber warum benötigen die User Hauptbenutzer rechte?
Das kann eigentlich nur einen Grund haben: es wird irgendwo Schreibzugriff benötigt - entweder muß in einen Ordner auf der Platte oder in den HKLM-Teil der Registry geschrieben werden. Aber da muß ThomasEt jetzt mal schauen, was die Software wo an Schreibrechten benötigt.
Ich bevorzuge weiterhin die Lösung mit der dedizierten Maschine. DC als Terminalserver stinkt irgendwie zu sehr nach kaputtem AD, Stress und Wochenendeinsätzen.
Ich bevorzuge weiterhin die Lösung mit der dedizierten Maschine. DC als Terminalserver stinkt irgendwie zu sehr nach kaputtem AD, Stress und Wochenendeinsätzen.
Wenn Schreibrechte z.B. in c:\Programme\.. oder unter einem bestimmten Zweig in HKLM nötig sind um eine Anwendung zum laufen zukriegen kann ma ja evtl. in diesen ausgewählten Bereichen gegebenenfalls Schreibrechte für User erteilen (am besten per GPO) das ist alle mal besser als pauschale Rechteerweiterung.
Natürlich ist ein dedizierter TermServer die bessere Lösung.
Natürlich ist ein dedizierter TermServer die bessere Lösung.
Hallo an alle! Vielen Dank für die zahlreichen und guten antworten.
Ich kann mich dem nur anschliessen! Im aktuellen Fall wird der Terminalserver nicht mehr länger Domaincontroller sein und zum Mitgliedsserver heruntergestuft werden.
Generell ist es aber dennoch sehr interessant zu wissen, wie man sowas lösen kann, wenn man nicht so viele Server zur Verfügung hat!
mfg Thomas
Ich kann mich dem nur anschliessen! Im aktuellen Fall wird der Terminalserver nicht mehr länger Domaincontroller sein und zum Mitgliedsserver heruntergestuft werden.
Generell ist es aber dennoch sehr interessant zu wissen, wie man sowas lösen kann, wenn man nicht so viele Server zur Verfügung hat!
mfg Thomas
