Drücke "Enter", um den Text zu überspringen.

Schlagwort: Domäne

SCCM: Verwaltung von Clients in nicht-vertrauten Domänen und in Workgroups

Am leichtesten ist es für den Administrator natürlich, wenn alle verwalteten Geräte in der selben Domäne stehen. Aber der System Center Configuration Manager ist auch in der Lage, mit Geräten umzugehen, die außerhalb der eigenen Gesamtstruktur (“Forest”) in einer nicht-vertrauten Domäne (“Non-trusted Domain”) oder sogar nur in einer Arbeitsgruppe (“Workgroup”) stehen. Dafür sind ein paar Voraussetzungen zu erfüllen und ein paar Besonderheiten bei der Einrichtung zu beachten.

Voraussetzungen:

  • Geräte der nicht-vertrauten Domäne (“nvD”) oder der Workgroup (“WG”) können den gewünschten Verwaltungspunkt (“Management Point”, MP) per DNS auflösen
  • Verwaltete Geräte in der nvD und/oder der WG können von den Standortsystemservern (“Site Server”) des SCCMs aufgelöst werden (bei nvD zusätzlich der Domänen-Name der nvD)
  • Das Konto der Client-Push-Installation hat ausreichend Rechte auf den Zielcomputern
    • Bei nvD ist ein Domänen-Account der nvD nötig, der auf den Clients lokale Admin-Rechte hat
    • Bei WG-Computern ist ein lokales Admin-Konto nötig, dass auf jedem WG-Computer gleich konfiguriert ist (Name / Passwort)

Um nun den Configuration Manager Client auf einem Gerät in einer Workgroup hinzuzufügen, kann die Push-Installation verwendet werden. Dazu muss a) die Firewall des PCs entsprechend geöffnet werden und b) ein passendes (lokales!) Konto als Push-Installations-Konto hinterlegt werden (Mehrere Konten möglich!):

wg1

Außerdem ist es notwendig, ein passendes Netzwerkzugriffskonto (“Network Access Account”) im SCCM zu hinterlegen, denn das Computerkonto des WG-Systems hat ja keine Leserechte auf den Site-Servern der Domäne:

wg1

Nun kann der Client mittels Pushinstallation (oder auch händisch!) verteilt werden und Software und co. auf den Arbeitsgruppen-PCs bereitgestellt werden.

Für die Verwaltung von Computern in einer nicht-vertrauten Domäne (nvD) muss zunächst die Gesamtstruktur der nvD bekannt gemacht werden:

nvd1

nvd2

Außerdem muss die “Active Directory Systemermittlung” um die externe Domäne (nvD) ergänzt werden:

nvd3

nvd4

Damit können denn Geräte der externen Domäne gefunden werden – und später per Push-Installation (siehe oben) mit dem Client betankt und somit verwaltet werden.

Hinweis: Für den Aufbau einer Secondary Site in einer externen Domäne ist eine bidirektionale Vertrauensstellung notwendig! (Two-Way-Trust)

2 Comments

Wie ein guter Domänen-Name aussieht – und wie nicht.

Auf den ersten Blick klingt das für viele sicher nach einer trivialen Frage: “Wie soll die neue AD Domäne denn heißen?” – aber so trivial ist diese Frage gar nicht.

Zunächst einmal muss man sich natürlich an die Vorgaben halten:

  • Der volle Domänenname (“Fully Qualified Domain Name, FQDN”) darf maximal 255 Zeichen lang sein und darf dabei aus Kleinbuchstaben, Großbuchstaben, Zahlen und dem “-”-Zeichen bestehen. Pro Label sind 63 Zeichen zulässig.
  • Der NetBIOS Name der Domäne ist auf 15 Zeichen beschränkt sowie auf Unicode-Zeichen und ein paar wenige Sonderzeichen

Ein AD Domänen-Name ist immer auch ein DNS-Name. Ein Domänen-Name besteht daher in der Regel aus einem oder mehreren Präfixen und einem Suffix, nach dem Aufbau-Prinzip

Präfix1.Präfix2.Suffix

Nun findet man heute sehr viele Domänen-Name nach dem Aufbau “Firma.local”, “.site”, “.lan” und so weiter. Die Wahl dieses Namens ist in der Regel auf die frühere Empfehlung, als Suffix keine öffentlichen Internet-Toplevel-Domänen wie “.com”, “.net” oder “.de” zu verwenden, da es sonst zu dem Problem kommt, dass man eine gesplittete DNS-Verwaltung benötigt oder aus dem internen Netz heraus eine Webseite nicht erreichen kann, wenn diese aus dem selben Prä- und Suffix besteht.

Diese Empfehlung hat heute keine Gültigkeit mehr!

Erstens werden auch diese “selbsterdachten” Suffixe mittlerweile von den Anbietern als Toplevel-Domänen verkauft. Das von einem selbst verwendete “FIRMA.LOCAL” könnte also zeitnah Eigentum einer anderen Firma werden! Und zweitens gibt es in gewissen Szenarien ganz klare Vorgaben, die die Verwendung dieser selbsterdachten Suffixe verbieten. Eines davon ist, dass keiner der großen SSL-Zertifikat-Anbieter Zertifikate für derartige Domänen- oder Hostnamen mehr ausstellt! (Vergleich dazu auch: https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf)

Also, wir halten zunächst fest: “.site”, “.local” oder ähnlich sind keine guten Suffixe! Besser ist es, offizielle TLD-Suffice wie “.com”, “.net” oder “.de” zu verwenden.

Aber was ist dann mit dem oder den Präfix(en)?

Wie wäre es, wenn man nun als “Firma Foo”, die “www.foo.com” als Webseite verwendet, “foo.com” als internen Domänennamen wählt? Das kann (besser: wird) zu Problemen führen. Hierzu ein kleines Beispiel:

Wenn ein Benutzer sich an einer Workstation innerhalb einer Domäne anmeldet, dann ist hierbei der Name (z.T. auch nur der NetBIOS-Name) der Domäne angegeben. Der Computer muss aber einen Domänencontroller kontaktieren können. Daher wird der Domänen-Name in den Namen eines DCs und dieser wiederum in eine IP-Adresse eines DCs übersetzt. Also, aus “foo.com” wird dann die IP eines DCs, hinter “foo.com” verbirgt sich ebenso die interne DNS-Zone.

Und was passiert, wenn nun jemand in dieser Firma “foo.com” in seinen Browser eingibt? Seine Browser würde versuchen, einen DC per HTTP anzusprechen, was in der Regel scheitert, weil ein DC kein Webserver ist!

Nun gibt es für den (ersten) Präfix zwei Optionen:

  • Man registriert eigens für diesen Zweck eine öffentliche Domäne, die aber nicht öffentlich sondern nur für die interne AD Domäne genutzt wird
  • Man nutzt eine Subdomäne einer bereits existierenden Domäne, die man auch öffentlich verwendet, im Idealfall die, die auch für die Webseite genutzt wird.

Wenn also “Firma Foo” die Domäne “foo.com” als Domäne für ihre Webseite nutzt, dann müsste der Name der obersten (ersten) interne AD-Domäne ABC.foo.com heissen. Dabei sollte “ABC” ein möglichst kurzes Wort sein, um die FQDN aller kommenden AD-Objekte nicht unnötig lang zu machen. Eine Option wäre z.B. “AD.FOO.COM”.

Damit nun bei der Anmeldung nicht “AD\User” sondern “FOO\User” genutzt wird, muss man einfach bei der Installation des ersten (!) Domänencontrollers der Domäne als NetBIOS-Namen anstatt des vorgeschlagenen “AD” das Wort “FOO” verwenden. (Achtung: Das nachträgliche Ändern des NetBIOS-Namen ist nicht trivial!)

Die Verwendung eines solchen DNS- und Domänen-Namens hat viele Vorteile:

  • Es muss nur ein einziger Domänen-Name (auf oberster Ebene) genutzt und verwaltet werden
  • Eine Trennung zwischen intern und extern ist problemlos möglich
  • Jeder interne Domänen- und Hostname ist weltweit einmalig (wer kann das bei “SERVER1.corp.local” schon behaupten?)
  • Für Zertifikate, E-Mail und co., wo naturgemäß externe Domänen nötig sind, ist bereits alles passend
  • Eine Anmeldung an den Systemen des Unternehmens kann mit der (öffentlichen) E-Mail-Adresse der Benutzer erfolgen. Niemand muss sich neben seiner Mail-Adresse noch einen (u.U. komplizierten) Benutzernamen merken.

Als Referenz und zum Weiterlesen empfehle ich folgende Links:

Schreibe einen Kommentar...

Exchange Server aus Domäne entfernen – auf die harte Tour

Offiziell wird von MS das Entfernen eines Exchange-Servers nur durch dessen Deinstallation unterstützt.

Ein mögliches Szenario, in dem die händische Entfernung dennoch notwendig sein kann, ist aber recht schnell umschrieben: Beim Update bzw. einer Versions-Migration ist etwas schief gegangen und die Exchange-Installation eines Exchange-Servers ist defekt. In der Exchange-Verwaltungskonsole der anderen Server taucht er aber weiterhin auf und ist Bestandteil des ActiveDirectoy – das kann zu Problemen führen. Hier hilft es auch nichts, den Server aus der Domäne zu entfernen oder gar sein Computerkonto zu löschen.

Eine weitere Möglichkeit wäre, dass einer der Mailserver (z.B. physikalisch) defekt ist, und smit nicht mehr sauber deinstalliert werden kann.

Also muss eine Lösung her. Die (in meinen Augen) einfachste ist die Verwendung des ADSI-Editors. Dazu startet man eine mmc (Start -> Ausführen -> mmc) und fügt das Snap-In für den ADSI-Editor hinzu (Datei -> Snap-In hinzufügen / entfernen).  Dort muss man mit einem Rechtsklick auf „ADSI-Editor“ eine Verbindung zu dem entsprechenden Domänencontroller herstellen und als Namenskontext „Konfiguration“ auswählen.

Hier muss man nur zu folgendem Zweig navigieren:

  • CN=Configuration,DC=DOMAIN,DC=NAME
    • CN=Services
      • CN=Microsoft Exchange
        • CN=NAME
          • CN=Exchange Administrative  Group
            • CN=Servers

Dort sind nun alle Exchange-Server, die im AD bekannt sind, aufgelistet. Derjenige, der entfernt werden soll, kann hier einfach entfernt werden und taucht dann z.B. in der Exchange Verwaltungskonsole nicht mehr auf.

9 Comments