Welche IT Abteilung , kennt das nicht das sie unterschiedliche Standard Kennwörter haben für die lok
[Mehr]
Seit der Windows 10 Version 1511 lässt sich die Startseite des neuen innovativen Browsers Edge über
[Mehr]
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: “Auswählen der Gesamtstruktur-Stammdomäne” (https://technet.microsoft.com/de-de/library/cc726016(v=ws.10).aspx) “Namenskonventionen in Active Directory für Computer, Domänen, Standorte und Organisationseinheiten” (https://support.microsoft.com/de-de/kb/909264) “Why you shouldn't use .local in your Active Directory domain name.” (http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html) “ACTIVE DIRECTORY DOMAIN NAMING BEST PRACTICES” (http://blog.varonis.com/active-directory-domain-naming-best-practices/)
Am 15. Juli 2015 endet der Support für Windows Server 2003. Dies Betrifft alle Editionen von Windows Server 2003 und Windows Server 2003R2. Viele Unternehmen haben allerdings noch Domänencontroller (DCs) unter Windows Server 2003 laufen. Hier erfahren Sie, wie Sie Active Directory (AD) von 2003 auf 2012R2 migrieren. Vor Windows Server 2012 war es notwendig, wenn man einen DC mit einer neueren Betriebssystemversion hinzufügen wollte, das AD darauf vorzubereitet. Hierfür stellt Microsoft das Kommandozeilen-Tool adprep.exe zur Verfügung, dass sich auf jeder Installations-DVD von Windows Server befindet (man musste dann immer das adprep von der neuen Windows Server-Version verwenden). Das ist jetzt ab Windows Server 2012 nicht mehr notwendig – das erledigt jetzt der neue Konfigurations-Assistent, der einen Server zu einem DC herauf stuft, automatisch. Unter Windows Server 2012R2 kann zwar keine Domäne oder Gesamtstruktur mit einer Funktionsebene 2003 mehr eingerichtet werden (nur noch ab Funktionsebene 2008), man kann ihn jedoch als zusätzlichen Domänencontroller einer 2003-Domäne hinzufügen. Dies müssen wir auch als ersten Schritt erledigen: Im Server-Manager des Windows Server 2012R2-Servers die Serverrolle “Active Directory-Domänendienste” hinzufügen (“Verwalten” –> “Rollen und Features hinzufügen”). Wenn die Rolle erfolgreich installiert wurde, muss der “Konfigurations-Assistent für Active Directoy-Domänendienste” gestartet werden, in dem man auf den Link “Server zu einem Domänencontroller heraufstufen” klickt (dieser Assistent löst quasi DCPROMO, das bei früheren Windows Server Versionen noch explizit aufgerufen werden musste, ab). Hier wählt man den Bereitstellungsvorgang “Domänencontroller zu einer vorhandenen Domäne hinzufügen” aus, trägt die Domäne ein und hinterlegt noch entsprechende Anmeldeinformationen eines Domänen-Admins. Als nächstes müssen die Domänencontrollerfunktionen “DNS-Server” (nur wenn der DNS-Server bisher auch auf einem DC lief) und “Globaler Katalog” ausgewählt werden. Dann noch ein DSRM-Kennwort angeben. Die nächsten Punkte “DNS-Optionen”, “IFM-Optionen”und “Pfade” können in der Regel mit “Weiter” übersprungen oder (falls notwendig) angepasst werden. Es folgt ein Hinweis, dass die Gesamtstruktur, das Schema und die Domäne während dem Hochstufen zum DC vorbereitet werden müssen – dieser Automatismus löst die manuelle Vorbereitung via ADPREP ab. Nachdem Sie die Optionen geprüft haben, wird eine Voraussetzungsüberprüfung vorgenommen. Erscheint links oben ein grüner Haken, dann kann mit der Installation begonnen werden. Nach dem automatischen Neustart läuft der 2012R2-Server als weiterer DC in der Domäne. Damit jedoch der 2003-Server in “Rente” geschickt werden kann, müssen die FSMO-Rollen (Betriebsmasterrollen) auf den 2012R2-Server verschoben werden. Es gibt insgesamt 5 FSMO-Rollen: PDC-Emulator, RID-Master, Infrastruktur-Master, Domänennamen-Master und Schema-Master. Der Verschiebung der Rollen muss immer an dem DC angestoßen werden, der die Rollen erhalten soll. Auf dem 2012R2-Server muss das Verwaltungs-Snap-In “Active Directory-Benutzer und –Computer” gestartet werden. In diesem Snap-In lassen sich 3 von den 5 Rollen verschieben. Hierzu macht man einen Rechtsklick auf den Domänennamen und geht im Kontextmenü auf “Betriebsmaster…”. Hier stehen die 3 Betriebsmasterrollen “RID-Master”, “PDC-Emulator” und “Infrastruktur-Master” – erreichbar über Registrierkarten – zur Verfügung. Im ersten Eingabefeld wird angezeigt auf welchem DC die Rolle aktuell beheimatet ist. Im zweiten Eingabefeld erhält man die Information mit welchem DC man gerade verbunden ist – hier sollte der Name des 2012R2-Servers aufgeführt sein. Falls das nicht der Fall ist: Im Snap-In Rechtsklick auf “Active Directory-Benutzer und –Computer” (oberster Eintrag in der Ordnerstruktur) –> “Domänencontroller ändern” und dort den 2012R2-Server auswählen. Um die FSMO-Rolle zu verschieben, genügt ein Klick von den Button “Ändern…”. Danach steht im ersten Eingabefeld auch der neue Server drin. Diese Aktion führt man bei allen 3 Rollen durch. Die Betriebsmasterrolle “Domänennamen-Master” kann man im Snap-In “Active Directory-Domänen und -Vertrauensstellungen” verschieben. Statt einen Rechtsklick auf den Domänennamen muss man hier allerdings einen Rechtsklick auf den Namen des Snap-Ins (oberster Eintrag in der Ordnerstruktur) vornehmen, um zum Betriebsmaster zu gelangen. Die letzte Betriebsmasterrolle muss über das Snap-In “Active Directory-Schema” verschoben werden. Problem: Dieses Snap-In ist (aus Sicherheitsgründen) standardmäßig nicht installiert. Über die Eingabeaufforderung (cmd) geben wir “regsvr32 schmmgmt.dll” ein. Danach bekommen wir die erfolgreiche Durchführung bestätigt. Über die mmc haben wir nun Zugriff auf das Snap-In (in der mmc “Datei” –> “Snap-In hinzufügen” –> “Active Directory-Schema” hinzufügen). Da man standardmäßig in diesem Snap-In mit dem Schema-Master verbunden wird, müssen wir über einen Rechtsklick auf “Active Directory-Schema” über “Active Directory-Domänencontroller ändern…” den 2012R2-Server als aktuellen DC auswählen. Danach mit einem weiteren Rechtsklick auf den Snap-In-Namen über “Betriebsmaster…” die letzte Rolle verschieben. Damit wurden alle 5 FSMO-Rollen auf den neuen 2012R2-Server verschoben. Dies kann man sich auch schnell in der Eingabeaufforderung mit “netdom query fsmo” bestätigen lassen. Jetzt können wir den 2003-Server als DC in Rente schicke. Als erstes trägt man in der IP-Konfiguration auf dem 2003-Server als bevorzugten DNS-Server den neuen 2012R2-Server ein und startet danach über “Start” –> “Ausführen” DCPROMO. Nach dem ersten “Weiter” wird man gefragt, ob dieser Server der letzte DC in der Domäne ist. Die Checkbox darf hier NICHT aktiviert werden! Als nächstes vergibt man noch ein Kennwort für das neue lokale Administrator-Konto, dass während dem Herabstufen angelegt wird. Nach einem Neustart ist der Server zwar noch Mitglied in der Domäne, jedoch kein Domänencontroller mehr. Falls es noch weitere ältere DCs gibt, diese ebenfalls wie beschrieben als DC herabstufen. Abschließend muss noch die Domänen- wie auch Gesamtstrukturfunktionsebenen heraufgestuft werden, damit auch alle neuen AD-Funktionen, die nach Windows Server 2003 implementiert wurden, auch zur Verfügung stehen. Dies kann man komfortabel auf dem 2012R2-Server über das neue Verwaltungstool “Active Directoy-Verwaltungscenter” erledigen. Nach dem Start des Tools (im Server-Manager unter “Tools”) einfach in der linken Spalte auf den Domänennamen klicken, dann in der rechten Spalte (“Aufgaben”) auf “Gesamtstrukturfunktionsebene heraufstufen…”. Dort als Funktionsebene “Windows Server 2012R2” auswählen. Damit stehen alle neuen Funktionen zur Verfügung. Es lässt sich dann aber auch kein DC mit einer niedrigeren Betriebssystemversion mehr hinzufügen. Die Domänenfunktionsebene wird automatisch mit hochgesetzt – dies muss nicht manuell gemacht werden. Damit ist die Migration abgeschlossen.
Mit dem Windows Server 2012 hält auch ein neues Werkzeug Einzug in den Administrations-Alltag: Der IP-Adress-Verwaltungsserver, kurz IPAM. Dieses Werkzeug ist in der Lage, die gewachsenen IP-Address-Strukturen zu verwalten, zu analysieren und auch abzufragen. Dabei greift er auf folgende Quellen zu: Domänen-Controller DHCP-Server DNS-Server NPS-Server Damit bietet er die Möglichkeit, die IP-Address-Verwaltung per Excel-Tabelle durch ein modernes, leistungsfähiges Werkzeug zu ersetzen. Leider ist die Installation bzw. Einrichtung nicht ganz trivial, daher möchte ich diese hier Schritt für Schritt erläutern. Bereits vorbereitet für dieses “Walk-through” ist eine kleine Demo-Umgebung bestehend aus einem Domänencontroller samt DNS (DC.hertes.lab), ein DHCP-Server samt Scope (DHCP.hertes.lab) sowie ein Member-Server für die künftig Aufgabe als IPAM (IPAM.hertes.lab). WICHTIG: IPAM darf nicht auf einem Domänencontroller installiert werden. Das TechNet liefert hierfür zwar keine Erklärung, ich vermute aber, dass dies an der nötigen Datenbank (hier: Windows Internal Database, WID) liegt. Ab Server 2012 R2 ist auch ein “richtiger” SQL-Server möglich. Als erstes muss der IPAM als Feature auf dem entsprechenden Server installiert werden. Dies geschieht über den Servermanager (alternativ per PowerShell): Die benötigten, abhängigen Komponenten wie eben die WID oder auch die GPO-Verwaltung, werden automatisch mit installiert: Ein Neustart nach der Installation ist im Allgemeinen nicht erforderlich. Selbst wenn man den Haken für den automatischen Reboot gesetzt hat, wird nur neugestartet, wenn dies nötig ist. Nach der Installation erfolgt die Einrichtung des IPAMs durch den entsprechenden Bereich im Servermanager (ein eigenständiges Werkzeug oder MMC-SnapIn existiert nicht). Die Administration inkl. Einrichtung kann auch remote erfolgen. Dazu ist über die Remoteserververwaltungstools (Feature) der IP-Adressverwaltungsclient zu installieren: Die Einrichtung selber besteht aus 6 (bzw. eigentlich 7) Schritten, welche in einer Art Assistenten im Servermanager (links im Menü unter “IPAM”) abzuarbeiten sind: Verbindung mit IPAM-Server herstellen IPAM-Server bereitstellen Serverermittlung konfigurieren Serverermittlung starten Server zum Verwalten und Überprüfen des IPAM-Zugriffs auswählen oder hinzufügen Daten von verwalteten Servern abrufen Nach dem Schritt 3 ist ein weiterer Schritt nötig, der hier nicht aufgeführt wird und nur per PowerShell erledigt werden kann. Darauf gehe ich später gesondert ein. Die GUI zeigt die 6 Schritte. Der erste Schritt wird automatisch ausgeführt, wenn die IPAM-Konsole auf dem IPAM-Server selber gestartet wird. Ansonsten ist durch einen Klick auf den ersten Punkt eine Verbindung mit dem gewünschten IPAM-Server herzustellen: Als nächstes wird der IPAM-Server bereitgestellt. Dies kann manuell (nicht zu empfehlen) oder per GPO (sehr komfortabel) erfolgen. Bei der GPO-Variante ist nur ein Präfix anzugeben, der den künftigen drei GPOs namentlich vorangestellt wird: Nach diesem Schritt existieren die GPOs nur auf dem IPAM-Server, noch nicht auf dem Domänencontroller. Dazu kommen wir gleich… In Schritt 3 werden die zu verwaltenden Domänen und Server ausgewählt: Hier findet sich auch – etwas unglücklich platziert – der Hinweis auf den (zwingend nötigen) “siebten Schritt”: Das Schreiben der GPOs auf den DC mittels PowerShell-Cmdlet “Invoke-IpamGpoProvisioning”: Schickt man den Befehl ohne Parameter ab, werden diese danach automatisch abgefragt. Wichtig: Das Ausführen dieses Cmdlets muss (interaktiv) auf dem IPAM-Server erfolgen. Es funktioniert weder per Enter-PSSession noch per Invoke-Command! Im Schritt 4 werden nun die Server der ausgewählten Umgebung ermittelt: Dabei wird eine “IP-Adress-Verwaltungsaufgabe” gestartet, deren Fertigstellung man abwarten muss: Nun können im Schritt 5 die zu verwaltenden Server ausgewählten werden. Dabei werden diese jeweils in den Zustand “Verwaltet” gesetzt. Dies muss für jeden Server separat erfolgen. Ist dies abgeschlossen, stehen die Server auf “Blockiert”. Die Blockierung wird aufgehoben, sobald die erzeugten und nun auch per Sicherheitsfilterung für die jeweiligen Server geltenden GPOs wirken. Am einfachsten kann man dies durch ein GPUpdate forcieren. Sobald die GPOs wirken, kann man durch einen Rechtsklick den “Status des Serverzugriffs aktualisieren”. Dies muss wieder für alle Server einzeln und nacheinander erfolgen. Wenn diese Aufgabe erledigt ist, kann man die Ansicht aktualisieren (Kringel / Kreisel oben rechts). Nun sollten alle Server “grün” sein: Falls nicht, hilft etwas warten bzw. müssen die jeweiligen Server evtl. noch einmal mit GPUpdate aktualisiert werden. Alternativ hilft “Invoke-GPUpdate SRVNAME –RandomDelayInMinutes 0 –Force”. Nun darf man den Schritt 6 nicht vergessen! Dieser ruft schließlich (einmalig manuell, später automatisch) die jeweiligen Daten von den verwalteten Servern ab. Auch hier muss man wieder auf Fertigstellung der IP-Adressverwaltungsaufgabe warten. Ist der Schritt 6 fertiggestellt, kann man sich nun den verschiedenen Möglichkeiten im Baum auf der linken Seite widmen. Unter IP-ADRESSRAUM / IP-Adressblöcke kann man z.B. den/die DHCP-Scope(s) sehen: Durch einen Rechtsklick auf diesen lässt sich die nächstfreie IP-Adresse suchen und zordnen: Hier kann man beispielsweise einen Eintrag in DNS oder auch eine DHCP-Reservierung vornehmen. Allerdings werden diese Daten vorerst nur am IPAM-Server gespeichert. Möchte man die Informationen auch auf die jeweiligen Server übertragen, so ist dies unter “IP-Adressbestand” möglich: In der Rubrik “Überwachen und Verwalten” kann man u.a. den Zustand der involvierten Server und DHCP-Scopes sehen. Im Ereigniskatalog werden einerseits Konfigurationsereignisse angezeigt, andererseits kann man gezielt nach IP-Adressen, MAC-Adressen, Hostnamen und Benutzernamen suchen, um damit verbundene Vorgänge (DHCP-Lese-Generation, –Renewal, DC-Authentifizierung, …) zu finden: Da der IPAM seine Daten in einer Datenbank ablegt, kann man hier auch Daten der Vergangenheit abrufen. Die Daten werden 3 Jahre lang in der Datenbank vorgehalten.