89371
Goto Top

Domain Controller zeigt alle Clients ohne Subdomain

Hallo zusammen,

ich spiele an meinem freiten Tag wieder an meinem Test-Netzwerk. Ich habe eine Domain angelegt (z.B. meinedomain.de).
Dann habe ich mit pro Standort eine Subdomain ausgedacht: home.meinedomain.de, elternhaus.meinedomain.de usw.
Den Clients habe ich zunächst unter TCP Einstellungen den DNS Suffix je nach Standort mitgegeben. z.B. mutter-pc.elternhaus.meinedomain.de, was auch gut funktioniert.
Dem Domain Contoller habe ich OU's angelegt, die je nach Standort heissen: home, elternhaus usw.

Nun habe ich diesen Client in die Domäne hinzugefügt und in die richtige OU verschoben.
Im DNS Server des Domain Controllers ist dieses jedoch noch als mutter-pc.meinedomain.de zu finden.
Klar, der DNS Server kann ja nicht wissen, dass im dortigen Netzwerk eine subdomain existiert.

Wie wird dieses als Best Practice gehandelt? Einfach manuell die Zonen anlegen und die DNS Einträge dort hin verschieben?
Oder kann man das mit den OU's verknüpfen?

Vielen Dank schon einmal...

Content-Key: 395223

Url: https://administrator.de/contentid/395223

Printed on: April 26, 2024 at 16:04 o'clock

Member: tikayevent
Solution tikayevent Dec 09, 2018 at 15:17:52 (UTC)
Goto Top
Das wird so nicht klappen, da die Rechner Mitglied der Stammdomäne sind. Um das zu ermöglichen, was du vorhast, müsstest du einen weiteren Domänencontroller aufbauen, der eine untergeordnete Domäne bereitstellt.

Sicher ist es möglich, dass man es über Verbiegungen hinbekommt, dass die Clients den gewünschten Namen registrieren, aber dennoch werden die immer unter pcname.meinedomain.de erreichbar bleiben.
Member: Criemo
Solution Criemo Dec 09, 2018 at 17:38:11 (UTC)
Goto Top
Hallo Monto1,
Wir müssen hier einmal klarstellen, dass verschiedene OUs nicht gleich subdomänen sind. Oder war es einfach nur falsch beschrieben, oder falsch verstanden

Was du machen könntest wären: wirkliche subs anlegen und dann über Domains und Services jeder sub einen eigenen IP Bereich zuweisen.
Dann müsstest du aber im DHCP auch verschiedenen IP Bereiche erstellen und die PCs manuell anhand der MACs eine feste IP aus dem jeweilig erstellten Bereich, für die entsprechende sub zuweisen. Das gleiche für den DNS.

Viele Grüße
criemo
Member: wiesi200
Solution wiesi200 Dec 09, 2018 at 22:03:29 (UTC)
Goto Top
Hallo,
Best Practice hierzu?
Ganz einfach so nicht machen.

Die OU's und Standorte haben einfach nix mit Subdomains zu tun.

Wenn du die Subdomains haben willst, dann musst du jeweils nen eigenen Domaincontroller installieren und dir nen Forest aufbauen.
Oder dir geht's nur um DNS dann manuell Weiterleitungen pflegen
Member: emeriks
Solution emeriks Dec 10, 2018 updated at 07:37:12 (UTC)
Goto Top
Hi,
wie die Kollegen schon schreiben:
Du verwechselst offenbar DNS-Domänen mit AD-Domänen. AD benutzt zwar DNS als Namespace, aber das war es dann auch schon.

Wenn Du den Clients - warum auch immer - anderen DNS-Domänen zuordnen willst, als sie es automatisch durch Ihre Mitgliedschaft in einer AD-Domäne schon sind, so macht das nur zusätzlich Sinn. Lass die Clients also mit ihren primären Domänen-Suffixen in der zur AD-Domäne gehörenden DNS-Domäne, lass sie dort ihre A-Records automatisch aktualisieren, und lege in den DNS-Sub-Domänen Aliase an (CNAME Records), welche auf die "originalen" FQDN verweist. Dann kann man die Clients auch über den anderen FQDN ansprechen. Je nach Dienst, welchen Du da ansprechen willst, muss Du das ggf. noch explizit aktivieren.

E.
Mitglied: 89371
89371 Dec 11, 2018 at 05:57:39 (UTC)
Goto Top
Danke schon mal...

Wofür verwendet man dann im DNS üblicher Weise die Subdomains, wenn nicht für verschiedene Standorte?

Ich habe mir halt bisher ganz gut merken können wo ich welches Gerät anspreche:

nas.home.meinedomain.de
nas.elternhaus.meinedomain.de
Member: tikayevent
Solution tikayevent Dec 11, 2018 at 19:03:12 (UTC)
Goto Top
Für verschiedene Standorte gibt es im AD Standorte. Klingt komisch, ist aber so. Standorte werden anhand der IP-Adressen definiert jeder gesondert angelegte Standort muss über mindestens einen DC verfügen. Darüber werden Anfragen ans AD selbst entsprechend verteilt und die Replikation über Standortgrenzen hinweg verläuft etwas anders als innerhalb eines Standortes.

DNS gab es schon weit vor dem AD und ist mit der Entwicklung des AD essentieller Teil dessen geworden. Die Funktion der Subdomain existierte schon weit vor dem AD und hat mit dem AD selbst nichts zu tun. Wenn du jetzt eine untergeordnete Domäne in deinem AD aufbaust (wie in meiner ersten Antwort bereits erwähnt), benötigst du dafür einen gesonderten DC, der sich nur um eine einzige untergeordnete Domäne kümmern wird. Es würde dir aber auch nichts bringen, weil deine Benutzer entweder in jeder untergeordneten Domäne einen eigenen Benutzer benötigen oder sie müssten sich an der übergeordneten (jetzt bestehenden) Domäne anmelden, womit die untergeordneten Domänen sinnfrei werden.

Untergeordnete Domänen bzw. Subdomains im AD werden in Großunternehmen verwendet, um verschiedene Unternehmensteile sinnvoll zu trennen.
Mitglied: 89371
89371 Dec 11, 2018 at 19:12:26 (UTC)
Goto Top
Viele Dank für Eure Geduld. Das mit den Standorten schaue ich mir dann während den Feiertagen an.
Mitglied: 89371
89371 Dec 11, 2018 at 23:06:16 (UTC)
Goto Top
Jetzt habe ich es doch schon mal angefangen. Ich habe testweise ein paar Standorte angelegt, und die Domain Controller hinein geschoben. Man kann sich die Standorte auch im Gruppenrichtlinieneditor anzeigen lassen und Gruppenrichtlinien zuweisen. Wenn ich jedoch unter Active Directory Benutzer und Computer den Baum anschaue, fehlen die Standorte, um dort Computer hinein zu schieben, die die Gruppenrichtlinie dann annehmen sollen. Gilt das nur für Server? Oder Sollte ich Gruppenrichtlinien grundsätzlich über OU's zuweisen?
Member: tikayevent
tikayevent Dec 12, 2018 at 00:11:57 (UTC)
Goto Top
Die Standorte werden automatisch anhand der IP-Adressen zugewiesen.
Member: emeriks
emeriks Dec 12, 2018 at 07:13:05 (UTC)
Goto Top
Zitat von @tikayevent:
Die Standorte werden automatisch anhand der IP-Adressen zugewiesen.
Will sagen, der Computer erkennt selbst, zu welchem Standort er gehört und fordert dann die GPO's für diesen Standort an.
Member: emeriks
emeriks Dec 12, 2018 updated at 07:24:05 (UTC)
Goto Top
Zitat von @tikayevent:
Es würde dir aber auch nichts bringen, weil deine Benutzer entweder in jeder untergeordneten Domäne einen eigenen Benutzer benötigen oder sie müssten sich an der übergeordneten (jetzt bestehenden) Domäne anmelden, womit die untergeordneten Domänen sinnfrei werden.
Benutzer von vertrauten Domänen können sich bei allen Computern einer dieser Domäne anmelden und dort Zugriffrechte erhalten, sofern nicht eingeschränkt. Auch "überkreuz": Also z.B. Benutzer aus Domäne A ist am Computer aus Domäne B angemeldet und greift auf einen Server in Domäne C zu. Alles kein Problem.

Untergeordnete Domänen bzw. Subdomains im AD werden in Großunternehmen verwendet, um verschiedene Unternehmensteile sinnvoll zu trennen.
Was wäre da sinnvoll? Es gibt meines Wissens nur wenige Gründe, sowas zu tun. Ein paar davon sind z.B.
  • vollständige Verwaltung der Domäne liegt in anderer Hand
  • Die Member Computer müssen - warum auch immer - einen enderen primären DNS-Suffix haben
  • Man hat verdammt viele Resourcen, für welche man nach AGDLP Berechtigungen erteilen muss. z.B. viele Fileserver mit großen Dateistrukturen und großer, komplexer Berechtigungsmatrix. Hier könnten die Sicherheits-Token einiger Benutzer zu groß werden, um alle Gruppen enthalten zu können, und man könnte durch die Verteilung der Ressourcen (Server) über mehrere Domänen diese Token je Server verkleinern. Sowas könnte man aber auch durch AGLP lösen.
  • der Domänenname soll ein bestimten (Tochter-)Firmennamen, Niederlassungsnamen o.ä. abbilden
Member: tikayevent
tikayevent Dec 12, 2018 at 22:29:18 (UTC)
Goto Top
Zitat von @emeriks:

Zitat von @tikayevent:
Es würde dir aber auch nichts bringen, weil deine Benutzer entweder in jeder untergeordneten Domäne einen eigenen Benutzer benötigen oder sie müssten sich an der übergeordneten (jetzt bestehenden) Domäne anmelden, womit die untergeordneten Domänen sinnfrei werden.
Benutzer von vertrauten Domänen können sich bei allen Computern einer dieser Domäne anmelden und dort Zugriffrechte erhalten, sofern nicht eingeschränkt. Auch "überkreuz": Also z.B. Benutzer aus Domäne A ist am Computer aus Domäne B angemeldet und greift auf einen Server in Domäne C zu. Alles kein Problem.

Dieses ist mir schon klar, nur wenn man zur Standorttrennung unterschiedliche Domänen nimmt, egal ob Trust, untergeordnet oder in der gleichen Gesamtstruktur, sich dann aber doch nur mit dem Benutzer aus einer anderen Domäne anmeldet, weil die ja wie gesagt zur Standorttrennung aufgebaut wurde (ich rede jetzt nicht von einem x-beliebigen Produktivszenario sondern von der oben beschriebenen Bastelumgebung), kann man entweder auf die unterschiedlichen Domänen verzichten, da ja eh keine Anmeldung in den anderen Domänen erfolgt (es ist bescheuert, für zwei Rechner und vermutlich null Benutzer einen eigenen DC zu betreiben) oder man spart sich den Kram mit den Domänen gleich ganz und arbeitet mit lokalen Anmeldungen.

Untergeordnete Domänen bzw. Subdomains im AD werden in Großunternehmen verwendet, um verschiedene Unternehmensteile sinnvoll zu trennen.
Was wäre da sinnvoll? Es gibt meines Wissens nur wenige Gründe, sowas zu tun. Ein paar davon sind z.B.
  • vollständige Verwaltung der Domäne liegt in anderer Hand
  • Die Member Computer müssen - warum auch immer - einen enderen primären DNS-Suffix haben
  • Man hat verdammt viele Resourcen, für welche man nach AGDLP Berechtigungen erteilen muss. z.B. viele Fileserver mit großen Dateistrukturen und großer, komplexer Berechtigungsmatrix. Hier könnten die Sicherheits-Token einiger Benutzer zu groß werden, um alle Gruppen enthalten zu können, und man könnte durch die Verteilung der Ressourcen (Server) über mehrere Domänen diese Token je Server verkleinern. Sowas könnte man aber auch durch AGLP lösen.
  • der Domänenname soll ein bestimten (Tochter-)Firmennamen, Niederlassungsnamen o.ä. abbilden
Unsere frühere Holding hatte da eine größere Konstruktion. Es gab bzw. gibt es noch, eine arg verschachteltes AD. Jede Gesellschaft hat eine eigene Domain, da die Verwaltung bei den eigenen Gesellschaften liegen, es gibt aber auch spezielle Domänen, an denen verschiedene Aufgaben hingen. Es gab eine extra Domain, in der nur Exchange-Server waren, da die XNG-Server nicht pro Gesellschaft betrieben wurden sondern für die Gesamtstruktur. Das gleiche gab es noch für verschiedene andere Systeme. Da aber alle Unternehmen zur gleichen Holding gehörten, hätte man auch eine große Domäne bauen können. Bloß wenn an die hundert Gesellschaften in der gleichen Domäne unterwegs sind, gibt das irgendwann Chaos. Zum Teil ist es auch gar nicht möglich, einheitliche Standards durchzudrücken, da jede Gesellschaft andere Anforderungen hat.
Es hatte für uns auch den Vorteil, dass wir uns ohne große Probleme nach dem Verkauf trennen konnten.