8
Rootdomäne, mehrere Child Domänen, DNS... alles unter 2008
Hallo Admins,
heute habe ich wirklich mal einen schweren Brocken. Ich habe hier schon nach ähnlichen Beiträgen gesucht, bin aber leider nicht fündig geworden. Im Gegenteil sind die paar Beiträge mit einem ähnlichen Thema erst gar nicht beantwortet worden. Aber zum Thema.
Im neuen Firmennetz haben wir eine Rootdomäne mit Server 2008 aufgebaut. Dazu besteht auch schon die erste Child Domäne im Baum.
Nach einigen Problemen im Erstellungsassistent, manuellem Aufbau des DNS und wiederholten Probierens, hat es dann endlich geklappt. Die Rootdomäne ist außerdem der GC und es befinden sich auf diesem auch alle OUs, Benutzer und Gruppenrichtlinien.
Außerdem gibts noch zwei TerminalServer mit Mit Lastenausgleich in der Rootdomäne, aber ohne eigener Domäne (man kitzelt ja so viel wie möglich aus dem TerminalServer raus
). Außer einem Replikationsfehler (sind noch am Arbeiten), sieht alles ganz gut aus.
Nun folgendes Problem:
1. Ich möchte gern auf allen Child Domänen die gesamten Objekte der Rootdomäne (wichtig OU Struktur, Benutzer und Gruppenrichtlinie) ebenfalls nutzen. Die Delagation ist ja nicht das Problem, da diese im Domänenbaum automatisch erstellt wird. Ich brauche aber eine einfache Lösung, alle Benutzer mit ihren Eigenschaften auch in allen untergeordneten Domänen zur Verfügung zu haben. Wichtig sind dabei auch die Terminalzugriffskonfigurationen, die in den Gruppenrichtlinien festgelegt sind.
2. Die erstellten Install Pakete (msi) für die RemoteApp Terminalzugriffe sind ja gut über die GPO zu verteilen (übrigens eine gesunde Alternative als direkt die rdp Dateien zu nehmen, da der Anwender mit den dargestellten Icons wenig anfangen kann), aber bei Anwendung der RemoteApps würde ich gern auf die Abfrage der Authorisierung verzichten, da wir ein gesichertes und in sich geschlossenes Netz haben (nur ein Breitbandzugang Internet für alle Standorte). Es wird für die Anwender nervend, permanent bei Neuanmeldung und Nutzung der TerminalApps ihren Benutzername und Passwort einzugeben.
Ansonsten gibts so die üblichen aber behebbaren Fehler (hoch lebe MS).
Danke im voraus!!
Mirko
heute habe ich wirklich mal einen schweren Brocken. Ich habe hier schon nach ähnlichen Beiträgen gesucht, bin aber leider nicht fündig geworden. Im Gegenteil sind die paar Beiträge mit einem ähnlichen Thema erst gar nicht beantwortet worden. Aber zum Thema.
Im neuen Firmennetz haben wir eine Rootdomäne mit Server 2008 aufgebaut. Dazu besteht auch schon die erste Child Domäne im Baum.
Nach einigen Problemen im Erstellungsassistent, manuellem Aufbau des DNS und wiederholten Probierens, hat es dann endlich geklappt. Die Rootdomäne ist außerdem der GC und es befinden sich auf diesem auch alle OUs, Benutzer und Gruppenrichtlinien.
Außerdem gibts noch zwei TerminalServer mit Mit Lastenausgleich in der Rootdomäne, aber ohne eigener Domäne (man kitzelt ja so viel wie möglich aus dem TerminalServer raus
). Außer einem Replikationsfehler (sind noch am Arbeiten), sieht alles ganz gut aus.Nun folgendes Problem:
1. Ich möchte gern auf allen Child Domänen die gesamten Objekte der Rootdomäne (wichtig OU Struktur, Benutzer und Gruppenrichtlinie) ebenfalls nutzen. Die Delagation ist ja nicht das Problem, da diese im Domänenbaum automatisch erstellt wird. Ich brauche aber eine einfache Lösung, alle Benutzer mit ihren Eigenschaften auch in allen untergeordneten Domänen zur Verfügung zu haben. Wichtig sind dabei auch die Terminalzugriffskonfigurationen, die in den Gruppenrichtlinien festgelegt sind.
2. Die erstellten Install Pakete (msi) für die RemoteApp Terminalzugriffe sind ja gut über die GPO zu verteilen (übrigens eine gesunde Alternative als direkt die rdp Dateien zu nehmen, da der Anwender mit den dargestellten Icons wenig anfangen kann), aber bei Anwendung der RemoteApps würde ich gern auf die Abfrage der Authorisierung verzichten, da wir ein gesichertes und in sich geschlossenes Netz haben (nur ein Breitbandzugang Internet für alle Standorte). Es wird für die Anwender nervend, permanent bei Neuanmeldung und Nutzung der TerminalApps ihren Benutzername und Passwort einzugeben.
Ansonsten gibts so die üblichen aber behebbaren Fehler (hoch lebe MS).
Danke im voraus!!
Mirko
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: 92665
Url: https://administrator.de/contentid/92665
Ausgedruckt am: 23.11.2024 um 04:11 Uhr
8 Kommentare
Neuester Kommentar
Hi,
zu 1:
Die Objekte sind einmal im AD drin - in der Root-Domain. Die Objekte können aber innerhalb des Forrest nicht doppelt angelegt werden. Das macht auch keinen Sinn, weil sie sind ja schon da.
Warum willst Du das aber - sag doch bitte mal dazu ein paar Worte. Welche Idee steckt dahinter?
zu 2:
Hm - ist nur ein Schuss ins Blaue: schau dir mal die Kommandozeilenoptionen des Programms mstsc an - da kann man bestimmt irgendwie Benutzernamen und Kennwort hinterlegen... Wenn nicht, dann wenigstens den Benutzernamen und dann vielleicht das Kennwort beim ersten Mal Zugriff speichern oder sowas ...
Obwohl es nervt, würde ich Dir aber dringend davon abraten - machst Du erst einmal eine Ausnahme möchten die User gleich die ganze Hand und Passworte abschaffen ....
Grüße
zu 1:
Die Objekte sind einmal im AD drin - in der Root-Domain. Die Objekte können aber innerhalb des Forrest nicht doppelt angelegt werden. Das macht auch keinen Sinn, weil sie sind ja schon da.
Warum willst Du das aber - sag doch bitte mal dazu ein paar Worte. Welche Idee steckt dahinter?
zu 2:
Hm - ist nur ein Schuss ins Blaue: schau dir mal die Kommandozeilenoptionen des Programms mstsc an - da kann man bestimmt irgendwie Benutzernamen und Kennwort hinterlegen... Wenn nicht, dann wenigstens den Benutzernamen und dann vielleicht das Kennwort beim ersten Mal Zugriff speichern oder sowas ...
Obwohl es nervt, würde ich Dir aber dringend davon abraten - machst Du erst einmal eine Ausnahme möchten die User gleich die ganze Hand und Passworte abschaffen ....
Grüße
Hallo Mathias,
vielen Dank für Deine schnelle Antwort. Also zu Erstens:
Natürlich sind schon alle Objekte in der Root. (Übrigens ist es bei mir kein Forrest, sondern nur ein Tree mit versch. SubDomänen). Mir geht es auch nicht darum die Objekte zu duplizieren, sondern nur, dass in allen Subdomänen unter Benutzuing der in der Rootdomäne befindlichen OUs gearbeitet und authorisiert werden kann.
Egal an welcher Subdomäne (Standort) ich mich anmelde, muss die Subdomäne auf die OUs der Rootdomäne zugreifen. Rechte, Gruppenzugehörigkeit, Terminalbenutzer, Gruppenrichtlinien.... Ist ja auch von der Administration am einfachsten.
Dazu hätte ich zur Umsetzung gern einige Tipps.
Mit Zweitens ist das so eine Sache. die rdp Dateien kann man ja editieren, aber irgendwie habe ich gelesen, dass die Sicherheitsbestimungen bei Anwendung des rdp Clients 3.1 erweitert wurden und ein Passwort eingegeben werden muss.
Mit dem letzten Deiner Sätze stimme ich Dir zu, aber ich möchte die Benutzung der TerminalApps so einfach wie möglich machen. Und das MPLS Netz der Telekom was wir nutzen, ist sehr sicher, da der einzige externe Zugang direkt und aktiv überwacht wird.
Wenn ich eine rdp Datei als Remotescript verwende geht das mit dem editieren natürlich. Aber ich habe es mir noch nicht angeschaut, wie es mit den msi Installern funktioniert. Schaun wir mal.
Bis dann
Mirko
vielen Dank für Deine schnelle Antwort. Also zu Erstens:
Natürlich sind schon alle Objekte in der Root. (Übrigens ist es bei mir kein Forrest, sondern nur ein Tree mit versch. SubDomänen). Mir geht es auch nicht darum die Objekte zu duplizieren, sondern nur, dass in allen Subdomänen unter Benutzuing der in der Rootdomäne befindlichen OUs gearbeitet und authorisiert werden kann.
Egal an welcher Subdomäne (Standort) ich mich anmelde, muss die Subdomäne auf die OUs der Rootdomäne zugreifen. Rechte, Gruppenzugehörigkeit, Terminalbenutzer, Gruppenrichtlinien.... Ist ja auch von der Administration am einfachsten.
Dazu hätte ich zur Umsetzung gern einige Tipps.
Mit Zweitens ist das so eine Sache. die rdp Dateien kann man ja editieren, aber irgendwie habe ich gelesen, dass die Sicherheitsbestimungen bei Anwendung des rdp Clients 3.1 erweitert wurden und ein Passwort eingegeben werden muss.
Mit dem letzten Deiner Sätze stimme ich Dir zu, aber ich möchte die Benutzung der TerminalApps so einfach wie möglich machen. Und das MPLS Netz der Telekom was wir nutzen, ist sehr sicher, da der einzige externe Zugang direkt und aktiv überwacht wird.
Wenn ich eine rdp Datei als Remotescript verwende geht das mit dem editieren natürlich. Aber ich habe es mir noch nicht angeschaut, wie es mit den msi Installern funktioniert. Schaun wir mal.
Bis dann
Mirko
Hi,
das verstehe ich nicht - gut, es mag ja unterschiedliche Standorte geben, doch gibt es da auch Domänencontroller? Wenn ich das jetzt verstanden hab, dann wohl nicht??? Oder durchaus schon welche, aber nur Backupcontroller????
Eine DNS-Subdomain hat auf die Anmeldevorgänge als solches erstmal keinen Einfluss - Du müßtest Dich in den Standorten anmelden können an der Root-Domain, sofern eine Verbindung zum PDC-Emulator da ist.
Anders ist es, wenn es eigenständige DC's gibt in den Standorten, die auch innerhalb der AD-Struktur als DC's arbeiten - dann hast Du aber wiederum einen Forrest ... Die AD-Struktur ist sozusagen ein Schema, was in gewisser Weise oberhalb des Schemas der DNS-Verwaltung liegt und arbeitet ....
Ich bin gerade verwirrt ...
Grüße
das verstehe ich nicht - gut, es mag ja unterschiedliche Standorte geben, doch gibt es da auch Domänencontroller? Wenn ich das jetzt verstanden hab, dann wohl nicht??? Oder durchaus schon welche, aber nur Backupcontroller????
Eine DNS-Subdomain hat auf die Anmeldevorgänge als solches erstmal keinen Einfluss - Du müßtest Dich in den Standorten anmelden können an der Root-Domain, sofern eine Verbindung zum PDC-Emulator da ist.
Anders ist es, wenn es eigenständige DC's gibt in den Standorten, die auch innerhalb der AD-Struktur als DC's arbeiten - dann hast Du aber wiederum einen Forrest ... Die AD-Struktur ist sozusagen ein Schema, was in gewisser Weise oberhalb des Schemas der DNS-Verwaltung liegt und arbeitet ....
Ich bin gerade verwirrt ...
Grüße
Mmhh
Also folgendes...
Jeder Standort hat einen eigenen FileServer, da die zentrale Datenablage über die geringe Bandbreite der MPLS Netze für FileDienste nicht ausreicht. Ausserdem wirds dann eng für die Kommunikationsdienste (Internet und Mail), sowie den Terminalanwendungen.
Die Stanorte sind auch sehr weit auseinander. Auf jedem FileServer (bisher testweise nur auf einem) ist eine Subdomäne mit Controller installiert.
Bsp.
Rootdomäne: Standortdomänen:
unternehmen.local - standort1.unternehmen.local
- standort2.unternehmen.local
u.s.w.
Warum kann die Anmeldung nicht an der lokalen Domäne stattfinden? Wenn ich über die Gruppenrichtlinien Programme und Updates zur Verfügung stelle, diverse Rechteeinstellungen vornehme, würde das den Rahmen des täglichen
Trafficbedarfs bei zweihundert Nutzern insgesamt überschreiten.
Das heißt also, der Benutzer soll sich an der Sub Domäne anmelden und diese erhält Ihre Konten und Kontenrichtlinien von der Root.
Im übrigen gibt es ja solche Universellen Gruppen, die wahrscheinlich in diesem Zusammenhang eingesetzt werden könnten.
Oder liege ich falsch?
Also folgendes...
Jeder Standort hat einen eigenen FileServer, da die zentrale Datenablage über die geringe Bandbreite der MPLS Netze für FileDienste nicht ausreicht. Ausserdem wirds dann eng für die Kommunikationsdienste (Internet und Mail), sowie den Terminalanwendungen.
Die Stanorte sind auch sehr weit auseinander. Auf jedem FileServer (bisher testweise nur auf einem) ist eine Subdomäne mit Controller installiert.
Bsp.
Rootdomäne: Standortdomänen:
unternehmen.local - standort1.unternehmen.local
- standort2.unternehmen.local
u.s.w.
Warum kann die Anmeldung nicht an der lokalen Domäne stattfinden? Wenn ich über die Gruppenrichtlinien Programme und Updates zur Verfügung stelle, diverse Rechteeinstellungen vornehme, würde das den Rahmen des täglichen
Trafficbedarfs bei zweihundert Nutzern insgesamt überschreiten.
Das heißt also, der Benutzer soll sich an der Sub Domäne anmelden und diese erhält Ihre Konten und Kontenrichtlinien von der Root.
Im übrigen gibt es ja solche Universellen Gruppen, die wahrscheinlich in diesem Zusammenhang eingesetzt werden könnten.
Oder liege ich falsch?
Ahhh - doch ein Forrest ...
Lass mich das mal zusammenfassen:
Es gibt eine Root-Domain, die unternehmen.local heisst und da sind auch die ganzen Nutzer drin. Dann gibt es für die Standorte Unterdomains, die im Forrest enthalten sind, also standort1.unternehmen.local und standort2.unternehmen.local usw. Die Nutzer sollen sich bei standort1.unternehmen.local an und bei standort2.unternehmen.local anmelden, die Konten selbst sind in unternehmen.local enthalten.
Soweit verstanden?
Die Problematik mit dem Traffik kannst Du fast nicht umgehen, solange die Konten on unternehmen.local drin sind kannst Du zwar etwas tricksen, doch es bleibt dabei - der Traffic zur Root-Domain läuft auf. Das kannst Du erstmal nur so umgehen, dass die Konten in den Subdomains angelegt werden, doch das ist gefährlich, da nur ein DC im Standort existiert.
Was kannst Du aber tun? Der Windows Server 2003 R2 hat die Eigenschaft, dass er einen Replikationsdienst besitzt, der Differenzen überträgt. Das kannst Du ausnutzen, in dem Du auf dem Hauptserver einen Ordner einrichtest und dort die Programme reintust. Dann replizierst Du den Kram einfach auf die Standortserver und das dauert zwar etwas länger, nimmt aber nicht soviel Bandbreite in Anspruch.
Bei den Nutzern selbst installierst Du nicht per GPO, sondern per Batch und mit Hilfe der Umgebungsvariable %LOGONSERVER% kannst Du dann steuern, von welchem Server er die Pakete holt.
Plan B wäre, die Sache mit den Unterdomains aufzugeben und nur mit einer Domain zu arbeiten - mit der Root-Domain. Jeder Fileserver im Standort wird dann zum DC der Root-Domain erklärt, Du hast zwar mit der Replikation etwas mehr zu tun, insgesamt sinkt aber der Verwaltungsaufwand und Traffik. Die User können sich dann am DC im Standort anmelden und im NETLOGON liegen die Dateien - bandbreitenschonend mit W2K3 R2 übertragen.
Plan C ist, auf den Standortservern einfach MS Virtual Server zu installieren und in eine solche BOX einen DC der Root-Domain reinzutun. Damit sparst Du Hardware und kannst das im laufenden Betrieb rekonfigurieren. Damit ist DC der Standortdomain am Standort und ein DC der Root-Domain und bei richtigen Standorteinstellungen sollte sich das mit dem Traffik auch in Grenzen halten. Hinzu kommt eine gewissen Ausfallsicherheit in den Standorten, da bei Leitungsausfall ein DC der Root-Domain im Standort existiert ...
Plan D könnte ich mir so vorstellen, dass Du den DC der Root-Domain ausbaust und ein MS Virtual Server installierst, in dem Du jeweils einen DC für jeden Standort installierst. Damit kannst Du Konten in den Standortservern installieren und nutzen, hast aber eine Kopie der Nutzerdatenbank in der Zentrale.
Grüße
Lass mich das mal zusammenfassen:
Es gibt eine Root-Domain, die unternehmen.local heisst und da sind auch die ganzen Nutzer drin. Dann gibt es für die Standorte Unterdomains, die im Forrest enthalten sind, also standort1.unternehmen.local und standort2.unternehmen.local usw. Die Nutzer sollen sich bei standort1.unternehmen.local an und bei standort2.unternehmen.local anmelden, die Konten selbst sind in unternehmen.local enthalten.
Soweit verstanden?
Die Problematik mit dem Traffik kannst Du fast nicht umgehen, solange die Konten on unternehmen.local drin sind kannst Du zwar etwas tricksen, doch es bleibt dabei - der Traffic zur Root-Domain läuft auf. Das kannst Du erstmal nur so umgehen, dass die Konten in den Subdomains angelegt werden, doch das ist gefährlich, da nur ein DC im Standort existiert.
Was kannst Du aber tun? Der Windows Server 2003 R2 hat die Eigenschaft, dass er einen Replikationsdienst besitzt, der Differenzen überträgt. Das kannst Du ausnutzen, in dem Du auf dem Hauptserver einen Ordner einrichtest und dort die Programme reintust. Dann replizierst Du den Kram einfach auf die Standortserver und das dauert zwar etwas länger, nimmt aber nicht soviel Bandbreite in Anspruch.
Bei den Nutzern selbst installierst Du nicht per GPO, sondern per Batch und mit Hilfe der Umgebungsvariable %LOGONSERVER% kannst Du dann steuern, von welchem Server er die Pakete holt.
Plan B wäre, die Sache mit den Unterdomains aufzugeben und nur mit einer Domain zu arbeiten - mit der Root-Domain. Jeder Fileserver im Standort wird dann zum DC der Root-Domain erklärt, Du hast zwar mit der Replikation etwas mehr zu tun, insgesamt sinkt aber der Verwaltungsaufwand und Traffik. Die User können sich dann am DC im Standort anmelden und im NETLOGON liegen die Dateien - bandbreitenschonend mit W2K3 R2 übertragen.
Plan C ist, auf den Standortservern einfach MS Virtual Server zu installieren und in eine solche BOX einen DC der Root-Domain reinzutun. Damit sparst Du Hardware und kannst das im laufenden Betrieb rekonfigurieren. Damit ist DC der Standortdomain am Standort und ein DC der Root-Domain und bei richtigen Standorteinstellungen sollte sich das mit dem Traffik auch in Grenzen halten. Hinzu kommt eine gewissen Ausfallsicherheit in den Standorten, da bei Leitungsausfall ein DC der Root-Domain im Standort existiert ...
Plan D könnte ich mir so vorstellen, dass Du den DC der Root-Domain ausbaust und ein MS Virtual Server installierst, in dem Du jeweils einen DC für jeden Standort installierst. Damit kannst Du Konten in den Standortservern installieren und nutzen, hast aber eine Kopie der Nutzerdatenbank in der Zentrale.
Grüße
Hallo Mathias,
habe gerade Deine Infos erhalten. Muss das erstmal durcharbeiten. Aber eines kann ich Dir schon klar sagen. Virtuelle Rechner als DC- davon wird klar auch von MS abgeraten.
Melde mich dann nochmal.
Erstmal vielen Dank.
Mirko
habe gerade Deine Infos erhalten. Muss das erstmal durcharbeiten. Aber eines kann ich Dir schon klar sagen. Virtuelle Rechner als DC- davon wird klar auch von MS abgeraten.
Melde mich dann nochmal.
Erstmal vielen Dank.
Mirko
Jupp - das ist eine Schnapsidee, ich weiss.
Vorteil dieser Variante ist, dass es funktioniert und das bei mir im Produktiveinsatz seit 1 1/2 Jahren. Natürlich sollte man nicht einen DC virtualisieren, dessen Wirt in der entsprechend virtualisierten Domäne ist - das macht keinen Sinn.
Wenn Dir MS Virtual Server nix ist, wie wäre es mit einem Debian und VMWareserver drauf - funktioniert und die VMWareserversoftware gibt es gratis. Im Gegensatz zur Windows-Version, bei der man angemeldet sein muss, arbeitet die Unixvariante als echter VMWaredienst.
Mit dieser Variante der Virtualisierung kannst Du hohe Kosten erstmal vermeiden - das war mein Gedankengang dahinter - clever ist nicht, das stimmt wohl ...
Grüße
Vorteil dieser Variante ist, dass es funktioniert und das bei mir im Produktiveinsatz seit 1 1/2 Jahren. Natürlich sollte man nicht einen DC virtualisieren, dessen Wirt in der entsprechend virtualisierten Domäne ist - das macht keinen Sinn.
Wenn Dir MS Virtual Server nix ist, wie wäre es mit einem Debian und VMWareserver drauf - funktioniert und die VMWareserversoftware gibt es gratis. Im Gegensatz zur Windows-Version, bei der man angemeldet sein muss, arbeitet die Unixvariante als echter VMWaredienst.
Mit dieser Variante der Virtualisierung kannst Du hohe Kosten erstmal vermeiden - das war mein Gedankengang dahinter - clever ist nicht, das stimmt wohl ...
Grüße
So, nun habe ich etwas mehr Zeit.
Also, wir haben lang und breit diskutiert.
In Vergangenhei habe ich oft mit Vertrauensstellungen gearbeitet, da gerade in stark fluktuierenden Standorten immer die Probleme neuer in sich geschlossener IT Technik oder Netzwerke besteht.
Dann sind ja noch die Komponenten Bandbreite und stattfindender Traffiic, der ja in solchen Konstrukten nicht zu verachten ist.
Nächster Problemherd ist eine TerminalFarm bestehend aus 2 NLB Servern.
MS sagt ja, leere Root und Standortbezogen die Sub plus DC.
Dein Plan B ist ganz gut und ich werde dies die nächsten zwei Tage mal testen.
Wir sind in der glücklichen Lage eine Teststellung unabhängig vom aktiven Netzwerk zu verwenden, da die Umrüstung auf ein neues ERP System ansteht und dabei sowieso eine ganze Menge neu inst/konf./migr.
werden muss.
Vielen Dank für Deine Hilfe.
Mirko
Also, wir haben lang und breit diskutiert.
In Vergangenhei habe ich oft mit Vertrauensstellungen gearbeitet, da gerade in stark fluktuierenden Standorten immer die Probleme neuer in sich geschlossener IT Technik oder Netzwerke besteht.
Dann sind ja noch die Komponenten Bandbreite und stattfindender Traffiic, der ja in solchen Konstrukten nicht zu verachten ist.
Nächster Problemherd ist eine TerminalFarm bestehend aus 2 NLB Servern.
MS sagt ja, leere Root und Standortbezogen die Sub plus DC.
Dein Plan B ist ganz gut und ich werde dies die nächsten zwei Tage mal testen.
Wir sind in der glücklichen Lage eine Teststellung unabhängig vom aktiven Netzwerk zu verwenden, da die Umrüstung auf ein neues ERP System ansteht und dabei sowieso eine ganze Menge neu inst/konf./migr.
werden muss.
Vielen Dank für Deine Hilfe.
Mirko
