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

Schlagwort: Active Directory

AD Domänen Controller: Zeitdifferenz / Time Skew zum PDC-Emulator

Bei der Prüfung von SCOM-Warnungen fiel mir diese hier besonders ins Auge:

ADTime0

ADTime1

Die Meldung “The Time Skew latency is above the configured threshold” besagt im Wesentlichen, dass die Zeitdifferenz zwischen einem “normalen” DC und dem PDC-Emulator zu hoch ist, in diesem Fall bei 267 Sekunden liegt und damit über der Warnungs-Schwelle von 5 Sekunden. Und tatsächlich, die Server haben eine sichtbare Zeitdifferenz:

ADTime2

Nun ist es ja so, dass alle Server einer Domäne die Uhrzeit beim PDC-Emulator abholen – oder es zumindest sollten. Dieser wiederum sollte so konfiguriert sein, dass er die Zeit von einer gültigen externen Zeitquelle empfängt. Das erreicht man recht einfach mit folgenden Aufrufen:

w32tm.exe /config /manualpeerlist:”0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org” /syncfromflags:manual /reliable:YES /update

w32tm.exe /config /update

PS: Restart-Service w32time

Im festen Glauben, dass dies auch in meiner Umgebung so ist, habe ich dies dennoch gegengeprüft:

Der Aufruf

netdom query fsmo

liefert die Verteilung der FSMO-Rollen, u.a. erfährt man eben auch, welcher DC aktuell der PDC-Emulator ist.

ADTime3

Nun kann man mit

w32tm /monitor

auf einem der DCs prüfen, welcher DC woher seine Zeit bekommt:

ADTime4

Und siehe da – die beiden DCs, die nicht PDC-Emulator sind bekommen ihre Zeit von irgend einem Server “frei im Internet”. Dies kann z.B. daran liegen, dass diese DCs früher mal PDC-Emulator waren und daher noch auf die Synchronisierung mit einer externen Quelle eingestellt sind. Dies lässt sich sehr leicht auf den betreffenden DCs (also denjenigen, die kein PDC-Emulator mehr sind) beheben. Dazu ist lediglich der Aufruf

w32tm /config /syncfromflags:domhier /update

net stop w32time

net start w32time

notwendig:

ADTime5

Nach kurzer Zeit sollte die Uhrzeit dann wieder passen. Zur Sicherheit kann man dies nun noch einmal mit

w32tm /monitor

überprüfen:

ADTime6

Jetzt sieht man, dass die beiden ersten DCs (beide kein PDC-Emulator) von HVSRV10 (dem PDC-Emulator) synchronisieren und dieser wiederum von einer externen Zeitquelle (stammt aus dem NTP-Pool).

Nun stimmen auch die Zeiten aller DCs wieder überein:

ADTime7

Schreibe einen Kommentar...

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...

Walk-Through: Bereitstellen einer IPAM-Umgebung unter Windows Server 2012

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):

ipam1

ipam2

ipam3

ipam4

ipam5

ipam6

Die benötigten, abhängigen Komponenten wie eben die WID oder auch die GPO-Verwaltung, werden automatisch mit installiert:

ipam7

ipam8

ipam9

ipam10

ipam11

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:

ipam_rsat

Die Einrichtung selber besteht aus 6 (bzw. eigentlich 7) Schritten, welche in einer Art Assistenten im Servermanager (links im Menü unter “IPAM”) abzuarbeiten sind:

  1. Verbindung mit IPAM-Server herstellen
  2. IPAM-Server bereitstellen
  3. Serverermittlung konfigurieren
  4. Serverermittlung starten
  5. Server zum Verwalten und Überprüfen des IPAM-Zugriffs auswählen oder hinzufügen
  6. 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.

ipam13

Ansonsten ist durch einen Klick auf den ersten Punkt eine Verbindung mit dem gewünschten IPAM-Server herzustellen:

ipam14

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:

ipam14-2

ipam15

ipam16

ipam17

ipam18

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:

ipam19

ipam20

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”:

ipam20a

ipam20b

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:

ipam21

Dabei wird eine “IP-Adress-Verwaltungsaufgabe” gestartet, deren Fertigstellung man abwarten muss:

ipam22

ipam23

Nun können im Schritt 5 die zu verwaltenden Server ausgewählten werden. Dabei werden diese jeweils in den Zustand “Verwaltet” gesetzt.

ipam24

ipam25

ipam26

ipam27

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.

ipam-gpo

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.

ipam-serverzugriff

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”.

invoke-gpupdate

ipam28

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.

ipam29

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:

ipam30

Durch einen Rechtsklick auf diesen lässt sich die nächstfreie IP-Adresse suchen und zordnen:

ipam31

ipam32

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:

ipam33

 

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:

ipam34ipam35

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.

Schreibe einen Kommentar...

Walk-Through: Dynamic Access Control praktisch angewendet

 

Der Windows Server 2012 bringt eine neue Funktion mit, welche die Bereiche Active Directory und Fileserver betrifft. Die Rede ist von “Dynamic Access Control“ (DAC) bzw. der “Dynamischen Zugriffssteuerung”.

 

Bisher wurden in der Praxis Zugriffsrechte auf Ressourcen eines Fileserver auf einzelne Benutzerkonten (schlecht) oder auf Active Directory Gruppen (besser) vergeben. Ist der Benutzer Mitglied der Gruppe, so hat er den Zugriff; andernfalls nicht. Diese Konstruktion ist aber sehr statisch und macht den Zugriff einzig vom Benutzer bzw. seiner Gruppenmitgliedschaft abhängig.

 

Dynamic Access Control hingegen ermöglicht es, den Zugriff auch von anderen Faktoren abhängig zu machen, z.B. von Eigenschaften der Dateien oder auch vom Computer, von dem aus der Zugriff erfolgt. Dadurch ist beispielsweise möglich, dem Benutzer den Zugriff von seiner Workstation zu gestatten, vom Notebook aus aber zu verbieten, um somit dem Datendiebstahl vorzubeugen.

 

Diese etwas abstrakte Technik möchte ich im Folgenden an einem praktischen Beispiel illustrieren. Dabei soll es darum gehen, den Zugriff auf Dateien und Ordner eines Fileservers so zu gestalten, dass es abhängig ist von der Abteilung des Benutzers (“department” ist eines der AD-Attribute, welches standardmäßig vorhanden ist).

Für die folgende Demonstration wird ein (virtueller) Windows Server 2012 verwendet, welcher bereits als Domänencontroller inkl. Verwaltungswerkzeugen konfiguriert ist. Eine separate Rolle oder ein Feature ist hierzu nicht notwendig, allerdings muss innerhalb der ohnehin vorhanden “Datei- und Speicherdienste”-Rolle der “Ressourcen-Manager für Dateiserver” aktiviert werden.

Zuerst werden sogenannte “Anspruchstypen” (“Claims”) benötigt. Das sind die Attribute, von denen wir später den Zugriff abhängig machen wollen. Das anlegen der Claims erfolgt wie auch ein Großteil der restlichen Konfiguration über das grafisch aufgewertete “Active Directory Verwaltungscenter” (ADAC):

dac1

Hier sind bereits die im AD bekannten Attribute der Benutzerklasse sowie der Computerklasse (nach Setzen der Checkbox) zu finden. In unserem konkreten Beispiel verwende ich das Attribut “department”:

dac2

Als nächstes sind nun Eigenschaften unserer späteren Ressourcen nötig. Hier werde ich eine Eigenschaft verwenden, die ebenfalls “department” heißt, um später eine Regel in der Form zu gestalten:

WENN Benutzer.Abteilung == Ressource.Abteilung DANN Zugriff_gewährt

Diese Eigenschaften heißen “Ressource Properties” (auch in der Deutschen GUI) und es sind bereits einige nützliche Eigenschaften vorhanden, die nur noch aktiviert werden müssen:

dac3

Diese Eigenschaft “department” hat bereits einige vorgeschlagene Werte eingetragen, die bei Bedarf geändert bzw. angepasst werden können:

dac4

Da ich eine bereits vorhandene Eigenschaft verwende, ist diese bereits auf der “Global Ressource Property List” – andernfalls müsste Sie dort noch hinzugefügt werden:

dac5

Nun müssen noch eine “Zentrale Zugriffsregel” (“Central Access Rule”) sowie eine “Zentrale Zugriffsrichtlinie” (“Central Access Policy”) angelegt werden. Als erstes legen wir hierzu eine Regel („Rule”) an. Diese regelt später den Zugriff auf die Ressourcen.

Unter “Zielressourcen” ist hier default “Alle Ressourcen” eingetragen. Das könnte aber später dazu führen, dass NIEMAND auf eine Datei zugreifen kann, beispielsweise dann, wenn diese GAR KEINE Abteilung als Eigenschaft besitzt.Daher ändere ich diesen Eintrag dahingehend, dass diese Regel nur auf Ressourcen abzielt, die die Eigenschaft “department” haben:

dac6

Bei den Berechtigungen hat man zwei Möglichkeiten: Man kann die im Folgenden konfigurierten Berechtigungen als “vorgesehene Berechtigungen” oder als “aktuelle Berechtigungen” (“tatsächliche” trifft es besser) verwenden:

dac7

Die erste Option ist insbesondere für Erprobungs- und Protokollierungszwecke nütze, wohingegen die zweite Option die kommenden Einstellungen direkt “scharf schaltet”.

In den Berechtigungen kann man nun über “Bearbeiten” die eigentlichen Einstellungen festlegen:

dac8

“Prinzipal” ist die Benutzergruppe, auf die die kommenden EInstellungen wirken sollen, in meinem Fall die “Domänen-Benutzer”. Dann folgt die eigentliche Berechtigung, in meinem Beispiel wähle ich das “Ändern”-Recht, welches Lesen und Schreiben beinhaltet. Ganz unten folgen hier die Bedingungen, in meinem Fall eben “Benutzer.Department == Ressource.Department”. Diese kann man bequem per Dropdown-Liste wählen:

dac9

Man könnte hier auch mehrere Bedingungen kombinieren. So könnte man eben auch fordern, dass der Computer, von dem aus der Zugriff erfolgt, in einer bestimmten AD-Gruppe enthalten sein muss.

Am Ende sieht die Regel dann in etwa so aus:

dac10

Nun ist noch eine Policy nötig, welche die angelegte Regel enthält:

dac11

Damit sind die Schritte im “Active Directory Verwaltungscenter” abgeschlossen. Nun sind noch zwei Einstellungen nötig, die man am besten per Gruppenrichtlinie setzt. Da in meinem einfachen Beispiel der Domänencontroller gleichzeitig der Fileserver ist, genügt hier ein GPO:

dac12

Die nötigen Einstellungen sind:

  • Computerkonfigurationen / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Dateisystem / Zentrale Zugriffsrichtlinie
    • Hier muss die angelegte Policy aktiviert werden
    • Gilt für den Dateiserver
  • Computerkonfigurationen / Richtlinien / Administrative Vorlagen / System / KDC / Unterstützung des Kerberos-Domänencontrollers für  Ansprüche…
    • Muss aktiviert werden
    • Gilt für den/die Domänencontroller

Spätestens nach einem GPUpdate sollten die gesetzten Einstellungen auf die betreffenden Systeme wirken, vorausgesetzt, das GPO wurde korrekt verknüpft. Dabei sollte im “Ressourcenmanager für Dateiserver” geprüft werden, ob die “Ressource Property” dort unter “Klassifizierungsverwaltung / Klassifizierungseigenschaften” auftaucht. Notfalls muss rechts “Aktualisieren” gedrückt werden:

dac15

Nun lege ich 2 Test-Benutzer im Active Directory an. Karl Auer ist hierbei Mitarbeiter der Marketing-Abteilung, Franz Iskaner arbeitet für die Sales-Abteilung:

dac13

Weiterhin lege ich ein Verzeichnis “Abteilungen” und darin je einen Ordner für “Sales” und für “Marketing” an. Den Ordner “Abteilungen” gebe ich im Netzwerk frei. An der Freigabe bekommen “Authentifizierte Benutzer” das Recht “Ändern”. In den erweiterten Sicherheitseinstellungen des Abteilungs-Ordners aktiviere ich die Abteilungs-Policy:

dac14

Nun werden noch die beiden Unterordner entsprechend klassifiziert. Dies geschieht über die Eigenschaften des jeweiligen Ordners. Dabei stehen mir die vorgeschlagene Werte der “Ressource Proptery” zur Verfügung:

dac16

Legt man nun beispielsweise im Marketing-Ordner eine neue Datei an, wird diese automatisch als “department: Marketing” klassifiziert. Diese Klassifizierung bleibt auch dann erhalten, wenn man das Dokument später z.B. an einen anderen Ort verschiebt. Bei den klassischen NTFS-ACL-Konstrukten wäre dies ander: Da würde das Dokument u.U. am Zielort andere Berechtigungen erben. Dabei wäre es z.B. denkbar, dass ein Benutzer, der auf beide Abteilungs-Ordner Zugriff hat, eine Marketing-Datei in den Sales-Ordner verschiebt. Bei den klassischen ACLs hätten nun die Sales-Benutzer Zugriff auf dieses Marketing-Dokument, was allerdings gar nicht gewünscht ist. Da die Klassifizierung sich beim Verschieben nicht verändert, haben die Sales-Benutzer hier auch dann keinen Zugriff, selbst wenn das Marketing-Dokument in “ihrem” Abteilungsverzeichnis landet.

dac17

dac18

Wenn man sich nun die Berechtigungen auf diesem Marketing-Dokument (im Sales-Ordner) ansieht, dann erkennt man, dass Karl Auer als Marketing-Mitarbeiter Zugriff hat, Franz Iskaner als Sales-Mitarbeiter hingegen nicht:

dac19

dac20

Genau so soll es auch sein!

Dynamic Access Control lässt sich für viele weitere Szenarien einsetzen. So kann man beispielsweise auch den “Ressourcen Manager für Dateiserver” nutzen, um Dateien automatisch zu klassifizieren, z.B. abhängig vom Inhalt. Denkbar wäre, Dokumente als “geheim” einzustufen, wenn diese das Wort “geheim” mindestens drei mal enthalten und dann nur noch einer gewissen AD-Gruppe den Zugriff auf geheime Dokumente zu gewähren.

Schreibe einen Kommentar...

Windows Server 8 / 2012 – Wie man einen Domain Controller klont

Eine der Neuerungen in Windows Server 8 (oder  evtl. auch Windows Server 2012, offiziell gibt es wohl noch keinen endgültigen Namen) wird die Möglichkeit sein, Domänen-Controller klonen zu können (dies bezieht sich auf virtuelle Server). Das ganze möchte ich hier einmal kurz erläutern.

Bedingung:

  • Hypervisor muss „VM-Generation ID“ unterstützen. Hyper-V 3.0 tut dies zum Beispiel
  • Der Inhaber der FSMO-Rolle „PDC-Emulator“ muss unter Windows Server 8 laufen und erreichbar sein
  • Der zu klonende DC muss unter Server 8 laufen

Was ist zu tun?

  • Der zu klonende Domänen-Controller muss in die AD-Gruppe „Klonbare Doänen-Controller“ („Clonable Domain Controllers“) aufgenommen werden
  • In dem Pfad, in dem die ntds.dit (Default: C:\Windows\NTDS) liegt, muss eine Datei mit dem Namen DCCloneConfig.xml liegen (Inhalt siehe unten)
  • Es müssen diejenigen Anwendungen auf dem DC identifiziert werden, die nicht kompatibel mit dem Klon-Vorgang sind (Get-ADDCCloningExcludedApplicationList)
  • Diese Anwendungen müssen in die Datei CustomDCCloneAllowList.xml eingetragen werden, welche ebenfalls im NTDS-Ordner abgelegt werden muss (Beispiel-Inhalt siehe unten)
  • Nun muss nur noch eine Kopie der virtuellen Festplatte erzeugt werden und diese mit einem neuen virtuellen Server verbunden werden (für Tests kann man auch zwei differenzierende VHDs erzeugen und diese auf VHD des Quell-DCs verweisen; der Quell-DC bekommt die eine, der neue DC die andere differenzierende VHD)
  • Zuerst den Quell-DC booten, danach den Klon
  • Nach der Installation von Treibern und Systemdiensten sollte der Klon nun beginnen, sich als DC-Klon zu erzeugen

Beispiel-Dateien:

DCCLoneConfig.xml

<?xml version="1.0"?>
<d3c:DCCloneConfig xmlns:d3c="uri:microsoft.com:schemas:DCCloneConfig">
    <ComputerName>VirtualDC3</ComputerName>
    <SiteName>Default-First-Site-Name</SiteName>
    <IPSettings>
        <IPv4Settings>
            <DynamicSettings>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <PreferredWINSServer></PreferredWINSServer>
                <AlternateWINSServer></AlternateWINSServer>
            </DynamicSettings>
        </IPv4Settings>
        <IPv6Settings>
            <DynamicSettings>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
                <DNSResolver></DNSResolver>
            </DynamicSettings>
        </IPv6Settings>
    </IPSettings>
</d3c:DCCloneConfig>

 

CustomDCCloneAllowList.xml

<AllowList>
    <Allow>
      <Name></Name>
      <Type>Service</Type>
    </Allow>
    <Allow>
      <Name></Name>
      <Type>Program</Type>
    </Allow>
</AllowList>
Schreibe einen Kommentar...

Umstellen, wie im ActiveDirectory Anzeigenamen gebildet werden

Wenn man auf einem Windows Server, der als DomainController fungiert, einen neuen Benutzer anlegt, dann wird dessen Anzeigename aus dem Vor- und dem Nachnamen nach dem Schema „VORNAME NACHNAME“ gebildet. Will man dies z.B. auf „NACHNAME, VORNAME“ oder „VORNAME NACHNAME (DEPARTMENT)“ umstellen, so muss man folgende Schritte gehen:

  • Über „Start“ / „Verwaltung“ den „ADSI-Editor“ starten
  • Rechtsklick auf „ADSI-Editor“ / „Verbindung herstellen…“
  • Bei den Verbindungseinstellungen „Bekannten Namenskontext auswählen“ den Punkt „Konfiguration“ auswählen und den Dialog mit „OK“ schliessen
  • In der Baumstruktur zu „Konfiguration / CN=Configuration,DC=DOMAIN,DC=LOCAL / CN=DisplaySpecifiers / CN=407“ navigieren (407 steht für Deutsch, bei einem englischen System muss 409 gewählt werden
  • „CN=user-display“ mit einem Doppelklick öffnen
  • Den Wert „createDialog“ bearbeiten
  • Für das Schema „NACHNAME, VORNAME“ muss z.B. „%<sn>, %<givenName>“ eingetragen werden
  • Mit „OK“ bestätigen und den ADSI-Editor schliessen
2 Comments

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