Welcome to TechNet Blogs Sign in | Join | Help

News

  • Haftungsausschluß: Alle Postings / Einträge werden zur Verfügung gestellt, wie sie sind, ohne jede Gewährleistung und ohne, daß daraus Rechte resultieren. Diese Web-Einträge repräsentieren nicht die Gedanken, Absichten, Pläne oder Strategien von Microsoft. Da Web-Einträge lediglich Momentaufnahmen von zum Zeitpunkt des Erscheinens aktuellen Themen sein sollen und keine permanente Referenz, sollten Sie berücksichtigen, daß ältere bzw. veraltete Einträge keine aktuellen Gedanken und Meinungen widerspiegeln.
Harmonie zwischen DFSR und Backup Software ?

Servus, ich möchte heute ein bißchen Licht darauf werfen, was passiert, wenn Daten gesichert werden, die via DFSR repliziert werden.

Eines der klassischen Szenarien, für die DFSR gedacht ist, ist ja: Wir haben viele Außenstellen und eine Zentrale. In den Außenstellen gibt es Server, auf denen den Benutzern Daten lokal zur Verfügung gestellt werden. Um nun nicht in jeder Außenstelle ein eigenes Backup, eine eigene Datensicherung machen zu müssen, mit dem damit verbundenen Aufwand, werden die Daten in die Zentrale repliziert und dort zentral gesichert.

Wenn man die Daten nun noch auf beiden Servern (Außenstelle und Zentrale) via DFSN veröffentlicht, hat man außerdem noch zusätzliche Fehlertoleranz gewonnen.

Aber das nur am Rande … obwohl das evtl. eigene Betrachtungen wert wäre.

Wenn nun die Datensicherung losläuft, während Dateien repliziert werden, könnte dies zu Inkonsistenzen führen, je nachdem, in welchem Stadium die Dateien gerade vom Backup erfaßt werden. Um dies zu verhindern, stoppt DFSR die Replikation, wenn eine Dateisicherung beginnt.

In den Ereignisprotokollen sieht man das entsprechend an Ereignissen wie:

ESENT 100 – 103, die protokollieren, daß die DFSR Datenbank bzw. einzelne DFSR-Datenbankinstanzen angehalten und wieder gestartet werden.

Im Ereignisprotokoll von DFSR sieht man z.B.

Event ID     : 4008

Source       : DFSR

Type         : Information

Generated    : 01.08.2008 09:01:08

Machine      : FS01

Message      : The DFS Replication service stopped replication on the replicated folder at local path E:\DATEN\GRUPPE\folder1.

…

 

Wenn zu diesem Zeitpunkt das Zeitfenster für die DFS-Replikation offen ist, kann es aber auch sein, daß wir auf dem Replikationspartner (z.B. in der Außenstelle, wenn ich mich auf das Beispiel oben beziehe) eine Warnung bekommen, weil er nicht replizieren kann, weil die Replikation auf dem Server in der Zentrale angehalten ist:

Event ID     : 5014

Source       : DFSR

Type         : Warning

Generated    : 03.08.2008 16:00:46

Machine      : FS02

Message      : The DFS Replication service is stopping communication with partner FS01 for replication group RG1 due to an error. The service will retry the connection periodically.

 

Additional Information:

Error: 9033 (Die Anforderung wurde durch Herunterfahren abgebrochen.)

 

Wenn einen diese Einträge im Ereignisprotokoll stören, ist es günstiger, die Datensicherung auf einen Zeitpunkt außerhalb eines Replikationszeitfensters zu legen.

 

Daneben gibt es auch Backup-Software, die gar nicht damit zurechtkommt, wenn Dateien mit DFSR repliziert werden sollen, und hier scheint es nötig zu sein, den DFSR Dienst zu beenden, bevor die Datensicherung von Dateien in Verzeichnissen, die mit DFSR repliziert werden, anfängt.

Dafür kann man sich zwar theoretisch ein Skript basteln, das erst den Dienst beendet, dann das Backup startet und nach einer gewissen Zeit dann den Dienst wieder startet, aber aus der Sicht der Replikationsleistung ist das keine gute Idee, weil DFSR anschließend wieder komplett die Konsistenz überprüfen muß usw.

Eine Backup-Software (z.B. NTBackup), der es reicht, wenn der Dienst die Replikation anhält, ist hier deutlich effektiver.

Warum hebe ich die Variante, die ein Beenden des DFSR Dienstes erfordert, so hervor ?

Das Stoppen des Dienstes hat verschiedene Auswirkungen, die die Leistung der Replikation und evtl. auch die Auslastung der involvierten Server beeinträchtigen können.

Wenn der Dienst längere Zeit gestoppt war, kann es z.B. zu einem sogenannten Journal Wrap kommen.

Das NTFS Journal oder auch USN Journal – beide Namen sind gängig – protokolliert alle Änderungen auf einem NTFS Volume mit. Das hat zunächst nichts mit DFSR zu tun. Aber DFSR nutzt dieses Journal, um festzustellen, ob eine Datei oder ein Verzeichnis in seinem „Hoheitsbereich“ geändert wurde.

Dieses Journal ist zyklisch, d.h. es wächst bis zu einer bestimmten Größe und ab dann werden bei allen weiteren Änderungen jeweils die ältesten Einträge überschrieben. Die Standardgröße ist 512MB bei den aktuellen Betriebssystemen.

Wenn DFSR nun, bevor der Dienst gestoppt wurde, noch den Eintrag N registriert hat, nach dem Neustart aber den Eintrag N+1 nicht mehr im NTFS Journal findet, weil er in der Zwischenzeit bereits überschrieben wurde, dann ist das ein Journal Wrap. Die DFS-Replikation kann nun die Konsistenz der Daten nicht mehr sicherstellen ohne Überprüfung. Das ist zwar nicht mehr so teuer wie noch zu FRS Zeiten – auch FRS hat das USN Journal bereits für den gleichen Zweck verwendet, die Konsistenz konnte aber nur mit einem manuellen Eingriff wiederhergestellt werden –, aber es erfordert im Minimum den Abgleich der Metadaten aller bereits existierenden Dateien. D.h. alle vorhandenen Dateien und Verzeichnisse erhalten eine Markierung „journalWrap“ in der DFSR Datenbank und die in der Datenbank hinterlegten Metadaten werden mit den Metadaten verglichen, die nun für die tatsächlichen Dateien im Dateisystem erstellt werden. Wenn bei einer Datei bzw. einem Verzeichnis ein Unterschied festgestellt wird, wird die Datenbank aktualisiert und die Änderung rausrepliziert (außer auf einem der Partner gibt es eine aktuellere Änderung, dann würde eine Konfliktlösung erfolgen). Anschließend wird die Markierung entfernt. So werden nacheinander alle Dateien / Verzeichnisse abgearbeitet. Je nach Anzahl und Größe der Dateien kann das recht aufwendig sein.

Dateien / Verzeichnisse, die während dieser Überprüfung neu erstellt werden bzw. schon nicht mehr markiert sind und lokal geändert werden, replizieren (auch während für andere Dateien / Verzeichnisse die Überprüfung noch läuft) ganz normal.

Soweit zum Journal Wrap.

Wenn man den DFSR Dienst stoppt, aus welchem Grund auch immer, muß man sich darüber im klaren sein, daß das alle Replikationsgruppen und alle Replicated Folder auf diesem Server betrifft - nicht eine Gruppe oder ein Verzeichnis oder eine Platte sondern ALLE.

Ein weiterer Effekt eines Neustarts des Dienstes ist, daß auf dem Server alle Leistungsindikatoren (Performance Counter) von DFSR zurückgesetzt werden, so daß alle Überwachungsprodukte, die darauf basieren und keine eigene Historie mitprotokollieren, wieder auf „0“ sind.

Alle diese Punkte sprechen dagegen, daß man den Dienst häufig neu startet, insbesondere bei größeren Datenmengen. Und sie sprechen dafür – um auf den Ausgangspunkt zurückzukommen :-) – ein Backup zu verwenden, das nicht das Beenden des DFSR Dienstes erfordert.

 

Gruß

Barbara
Posted: Tuesday, August 26, 2008 10:06 AM by dedsBarbara | 0 Comments
Filed under: ,
Domänencontroller in unterschiedlichen Sprachen - möglich oder nicht?

Hallo, Fabian hier. Ab und an stellt sich bei unseren Kunden die Frage ob es problemlos möglich ist, Domänencontroller in unterschiedlichen Sprachen innerhalb einer Windows Server 2003 Domäne einzusetzen. Die Antwort lautet - wie so oft - ganz eindeutig: Jein - oder: Kommt drauf an. ;-)

Gleich zu Beginn sei gesagt, daß es grundsätzlich auf jeden Fall möglich und supportet ist, Domänencontroller in unterschiedlichen Sprachen innerhalb einer Domäne und damit eines Forests zu betreiben. Die internen Strukturen der Active Directory sind unabhängig von der "Darstellungssprache". Denn mehr als eine Darstellung nach außen ist die Sprachwahl innerhalb einer Domäne nicht.

Ausnahme sind hier MUI (Multilingual User Interface) Packs - hier gab es in der Vergangenheit ab und an Probleme, weshalb ich eher davon abraten würde, MUI Packs auf DCs zu nutzen.

Es kann jedoch trotzdem durchaus Sinn machen, die Domänencontroller in einer einheitlichen Sprache zu betreiben. Daher an dieser Stelle ein paar Stichpunkte, warum dies "Best Practice" ist:

  • Oftmals wird bei der Einrichtung einer Domäne vergessen, daß die Sprache des ersten Domänencontrollers auch die "Darstellungssprache" innerhalb einer Domäne bestimmt. So werden beim DCPROMO des ersten DCs einer Domäne beispielsweise die Namen der Builtin-Accounts über diese Sprache festgelegt. Nutzt man also für dieses DCPROMO der Domäne ein englisches System, werden auch die Standard-Konten wie "Administrator" oder Standard-Gruppen wie  bzw. "Administrators" oder "Domain Admins" in englischer Sprache benannt. Ist der erste Domänencontroller jedoch etwa ein deutsches System, werden diese nach deutschem Namensschema benannt, so z.B. "Administratoren" oder "Domänen Admins".
    Als weiteres Konto ist außerdem der erste Administrator des Forests zu erwähnen, der beim DCPROMO des ersten DCs des Forests benannt wird. Da im Englsichen als auch im Deutschen der "Administrator" gleich heißt, ist das eher kein Problem. In anderen Sprachen / Zeichensätzen kann das jedoch durchaus ein Problem darstellen.

    Zwar läßt sich der sAMAcoountName für diese Builtin-Accounts und -Gruppen problemlos ändern, jedoch gilt dies nicht für den Common Name (cn) und damit verbunden den Distinguished Name (dn). Diese Attribute sind vom SYSTEM geschützt und können nur mit etwas Aufwand geändert werden, was an dieser Stelle jedoch nicht empfohlen wird.

  • Auch wenn sich die Problematik mit Hilfe von Managementsystemen wie MOM / SCOM oder ähnlichen Produkten entschärft, so muß doch weiterhin das Management der Systeme im Auge behalten werden. Will man etwa ein Script gegen die Server laufen lassen, gilt es bei unterschiedlichen Sprachversionen ggf. deren Eigenheiten zu beachten. So sind zum Beispiel die Dienstnamen in unterschiedlichen Sprachversionen meist verschieden oder es gibt andere Besonderheiten in Namensgebung oder Zeichensatz. Dies hat zwar nur indirekt mit der Active Directory als solches zu tun, ist jedoch ein nicht unwesentlicher Faktor bei der Frage, ob man mehrere Sprachversionen einsetzen möchte oder eher nicht.

  • Sind Administratoren aus unterschiedlichen Ländern mit der Wartung bzw. Betreuung der Systeme betraut, macht auch hier eine einheitliche Sprache Sinn. Niemand wird einen Ausfall riskieren wollen, weil der spanische Mitarbeiter gerade kein Kyrillisch in der Fehlermeldung oder im Ereignisprotokoll übersetzen kann und den falschen Schalter drückt (siehe dazu "Hilfe zur Selbsthilfe"). ;-)
    Englisch ist beispielsweise eine Sprache, die die meisten Mitarbeiter innerhalb der IT länderübergreifend sprechen oder zumindest verstehen. Auch im Supportfall oder beim Hinzuziehen eines externen Dienstleisters kann es durchaus von Vorteil sein, wenn nicht nur Muttersprachler die Installationssprache verstehen.

  • Zwar entschärft sich das Problem immer mehr (durch angepaßte "Patchdays", durch WSUS Deployments etc.), jedoch ist auch das Patchmanagement eine kritische Angelegenheit. Früher kamen lokalisierte Hotfixes oftmals zu unterschiedlichen Zeiten heraus, was zu unerwarteten Problemen führen konnte. Gerade in Bezug auf Hotfixes von diverser Drittsoftware existiert diese Einschränkung oft immer noch, so daß auch hier einheitliche Installationssprachen die Situation entschärfen können. Gleiches gilt natürlich auch grundsätzlich für die Software, die ggf. auf den Systemen zusätzlich installiert werden soll (sei es die GPMC, Backup-Software, Monitoring-Software etc.).

  • Kennwortrichtlinien können ebenfalls ein Problem darstellen, denn einige andere Zeichensätze (wie zum Beispiel Japanisch) kennen keine Sonderzeichen wie etwa " $ % & ?". Hier kann es Sinn machen die Umgebung in einer einheitlichen Sprache aufzusetzen, so z.B. in Englisch (und nicht Japanisch).

Bleibt also unter dem Strich stehen, daß es im Normalfall also kein technisches Problem ist, verschiedene Installationssprachen einzusetzen. Die Frage ist viel eher, wie viele "Mehrprobleme" man sich ins Haus holt, wenn man keine einheitliche Sprache der Domänencontroller (oder weiter gefaßt: auch der Memberserver und -clients) wählt.

 Viele Grüße, Fabian.

Posted: Tuesday, August 19, 2008 8:26 AM by dedsFabian | 0 Comments
Filed under: ,
Viele Zufälle führen fast zu einer „Endlos“-Schleife bei forest-weiter Gruppenauswertung

Servus Beianand.

Ich hatte vor einiger Zeit eine recht kuriose Anfrage mit unangenehmen „Nebenwirkungen“, sprich Symptomen.

Darauf gestoßen sind wir, weil einzelne wechselnde DCs immer wieder mal hohe CPU-Last, scheinbar verursacht durch LSASS, zeigten.

Wir haben dann herausgefunden, daß der Auslöser die SMS Hardware Inventur war, die beim Erstellen der Inventur auch Infos über die Eventlogs sammelt, z.B. wer Zugriff auf die einzelnen Eventlogdateien hat. Dazu ermittelt WMI die effektive Berechtigung auf diese Dateien. Die hohe Last beobachteten wir vor allem, wenn die Inventur auf etlichen Client-Rechnern gleichzeitig ausgeführt wurde. Allerdings war die Inventur nur das unschuldige Opfer in diesem Fall.

Die Win32 NTEventlogFile WMI Klasse benutzt für die Auswertung der Berechtigungen GetEffectiveRightsFromAcl.

GetEffectiveRightsFromAcl wandert dann durch die ACL (Zugriffsliste) der Datei und überprüft, ob der aufrufende Benutzer in einer der Gruppen der ACL oder direkt in der ACL ist. Also z.B.:

ACL is: ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
ACL is: ->Ace[0]: ->AceFlags: 0x10
ACL is: ->Ace[0]:             INHERITED_ACE
ACL is: ->Ace[0]: ->AceSize: 0x18
ACL is: ->Ace[0]: ->Mask : 0x001f01ff
ACL is: ->Ace[0]: ->SID: S-1-5-32-544

S-1-5-32-544 ist die Gruppe der lokalen Administratoren auf der Maschine.

Usw. für alle Gruppen, die in der ACL direkt aufgelistet sind.  Anschließend fragt die API rekursiv die Mitglieder dieser Gruppen ab (die ja auch wieder Gruppen sein können - Stichwort group nesting) und überprüft wieder , ob der Benutzer in einer der Gruppen ist, indem es die SID des Benutzers mit den Mitgliedern der Gruppen vergleicht. Die API imitiert sozusagen eine Anmeldung des aufrufenden Benutzers.

Dieses rekursive Vorgehen kann schon zu einer relativ hohen Last auf DCs führen, wenn wir hier die entsprechende Anzahl solcher Abfragen gleichzeitig haben.

Hinzu kam nun folgendes: Mit Windows 2000 wurden Universal Groups (Universale Gruppen) eingeführt. Intern werden sie von den NT4 APIs (die u.a. GetEffectiveRightsFromAcl verwendet) wie Globale Gruppen behandelt. Zwischen Universalen und Globalen Gruppen gibt es aber einen bedeutenden Unterschied: Universale Gruppen können Mitglieder aus allen Domänen der Gesamtstruktur (des Forests) enthalten, Globale Gruppen können nur Mitglieder aus der eigenen Domäne haben.

In der Security Accounts Manager API wird von Mitgliedern von Globalen (und Universalen) Gruppen lediglich die RID (Relative ID) zurückgegeben.

Jedem Benutzer einer Domäne wird seit Windows NT eine SID (Security ID) zugewiesen, die je Domäne eindeutig ist. Sie setzt sich aus einem Domänenteil, der für alle Objekte der Domäne gleich ist, und der RID zusammen, die quasi eine fortlaufende Numerierung ist. Durch diese Konstellation – Domänenteil + RID – ist die SID dann eindeutig.

Ein Beispiel:
S-1-5-21-112233445-2233445566-3344556677-98765
Hier ist „98765“ die RID
und S-1-5-21-112233445-2233445566-3344556677 der Domänenteil.

Das bedeutet aber nun für uns, daß in der  Security Accounts Manager API für Universale Gruppen die Information der domänenübergreifenden Mitgliedschaften verloren geht, weil nur die RID zurückgegeben wird. Wenn es nun in der Domäne des Benutzers, der die Abfrage aufgerufen hat, ein Objekt mit dieser RID gibt, so hat sie dort eine völlig andere Bedeutung. Ist ja auch ein anderes Objekt.

In unserm konkreten Fall war es so, daß die RID einem Benutzer einer anderen Domäne zugeordnet war und die gleiche RID in der Domäne des aufrufenden Benutzers einer Gruppe gehörte. Und diese Gruppe wiederum war zufällig auch in der Gruppenliste des aufrufenden Benutzers.

Dadurch lief die Abfrage in eine Schleife, die nur deshalb nicht wirklich endlos war, weil irgendwann der Zähler zuschlug, der die Verschachtelungstiefe der Rekursion zählt.

 

Gruß

Barbara

Posted: Thursday, August 14, 2008 2:49 PM by dedsBarbara | 0 Comments
Filed under:
Probleme bei VMWare ESX 3.5 Update 2 - was ist für Microsoft Gast-Systeme zu beachten?

Hallo, Fabian hier. Gestern wurde ein Problem mit dem Starten von virtuellen Maschinen nach einem Update des VMWare ESX Servers bekannt, welches in einigen unserer Kundenumgebungen durchaus relevant sein kann:

http://communities.vmware.com/thread/162377?tstart=0
http://www.heise.de/newsticker/Vorsicht-Zeitbombe-in-VMware-ESX-3-5--/meldung/114126

Zwar ist der Support für Installationen unserer Software innerhalb von Virtualisierungslösungen von Drittherstellern eingeschränkt, das heißt jedoch nicht, daß es von unseren Kunden nicht trotzdem eingesetzt wird. Daher der folgende Hinweis:

Der von VMWare empfohlene Workaround, die Zeitsynchronisierung des Host-Systems mittels NTP (gegen einen externen Zeitserver) abzuschalten und danach die Systemzeit bzw. das Systemdatum des Host-Systems zurückzusetzen, kann größere Probleme nach sich ziehen, wenn für die Gast-Systeme die Zeitsynchronisierung mit dem Host-System aktiviert wurde. In Domänenumgebungen kann dies bei Domänenmitgliedern als auch auf den Domänencontrollern zu Kerberos- und damit verbunden Authentifizierungs- und Replikationsproblemen führen (siehe http://technet.microsoft.com/en-us/library/bb742516.aspx).

Weiterhin ist auf Domänencontrollern oder FRS Systemen zu beachten, daß ein Zeitsprung FRS beeinträchtigen und einen inkonsistenten FRS Replikationsstatus nach sich ziehen kann, siehe http://support.microsoft.com/default.aspx?scid=kb;EN-US;289668.

Da der Zeitrücklauf zum jetzigen Zeitpunkt nur wenige Tage beträgt, sollten keine weiteren Probleme in Bezug auf Stichworte wie „Tomstone Lifetime“ und / oder „Lingering Objects“ auftreten. Trotzdem hier noch ein Link zu generellen Erwägungen beim Einsatz von Domänencontrollern als virtuelle Maschine: http://support.microsoft.com/default.aspx?scid=kb;EN-US;888794 und http://www.microsoft.com/downloads/details.aspx?FamilyID=64db845d-f7a3-4209-8ed2-e261a117fc6b&displaylang=en.

Es ist aus den genannten Gründen und auch grundsätzlich in jedem Fall zu empfehlen, die Zeitsynchronisierung zwischen Host- und Gast-System zumindest in Domänenumgebungen auf den Gästen zu deaktivieren und zu prüfen, ob danach die Uhr des Gast-Systems noch korrekt läuft. Es findet zwar ein Abgleich der Zeit innerhalb der AD statt, jedoch kann die Zeit trotzdem stark auseinander laufen, sollte die emulierte Hardware Uhr des Gast-Systems nicht ganz sauber laufen (was wir oft in virtuellen Umgebungen gesehen haben).

Grundsätzlich sei an dieser Stelle auch noch einmal der Hinweis auf unsere Support Policy in Bezug auf virtuelle Domänenumgebungen gegeben: http://support.microsoft.com/kb/897615/en-US.

Viele Grüße, Fabian.

Posted: Wednesday, August 13, 2008 11:51 AM by dedsFabian | 1 Comments
Filed under: , ,
Schema Erweiterungen – Riskant oder unkritisch?

Das Schema ist quasi die Vorlage für alle Objekte die im Active Directory vorhanden sind oder angelegt werden können, basierend auf den im Schema definierten Klassen und Attributen. Wobei mit der Installation des AD nur das Default Schema angelegt wird (siehe dazu auch Details unter http://msdn.microsoft.com/en-us/library/ms674984(VS.85).aspx sowie http://msdn.microsoft.com/en-us/library/ms675085(VS.85).aspx). Vielen Anwendungen reichen diese Standard Attribute jedoch nicht und möchten daher eigene Attribute im Schema anlegen oder bestehende Attribute umwandeln oder ergänzen. Ist dies nun kritisch?

 

Aus unserer Erfahrung heraus gibt es da zwei Kategorien:

-       Einmal Anwender die vor dem Einsatz einer Schema Erweiterung prinzipiell bei uns Nachfragen und die Schema Erweiterung überprüft haben möchten

-       Und zum anderen die Anwender, die in irgendeinem Internet Forum als Workaround eine Schema Erweiterung empfohlen bekommen haben, dort auch eine DLL runter laden und damit dann das Schema erweitern. Ohne weiteres Testen.

 

Beides ist vielleicht nicht der ideale Ansatz. Doch zunächst etwas Theorie. Attribute im Schema werden eindeutig gekennzeichnet, mit einer sog. OID (Object Identifier) muss nach RFC 2251 ein Directory Service Klassen und Attribute identifizieren. Diese OIDs identifizieren die Attribute in einer Baumstruktur und nützen dafür eine mit Punkten getrennte Syntax. Z.b. die OID  1.2.840.113556.1.5.9

Dies bedeutet:

Value

Meaning

Description

1

ISO

Identifies the root authority.

2

ANSI

Group designation assigned by ISO.

840

USA

Country/region designation assigned by the group.

113556

Microsoft

Organization designation assigned by the country/region.

1

Active Directory

Assigned by the organization.

5

Classes

Assigned by the organization.

9

user class

Assigned by the organization.

 

Soviel zur Theorie. Die OIDs sind schon einer der Hauptproblempunkte. Aus dieser Syntax (und natürlich der RFC) kann man erkennen, dass die OID bis zu einer gewissen Ebene von Öffentlichen Institutionen vorgegeben ist und ab einem Punkt dann einer Organisation „gehört“. Grundsätzlich müssen OIDs eindeutig sein, da es sonst zu Konflikten kommen würde. Zumindest das AD wehrt sich gegen eine Erweiterung mit einer bereits vergebenen OID. Es muss also eine eindeutige OID her. Doch woher? Hmm, ganz einfach (dachten viele): Microsoft bieten ein Script an um eindeutige OIDs zu generieren (http://www.microsoft.com/technet/scriptcenter/scripts/ad/domains/addmvb03.mspx?mfr=true ). Oder doch nicht? Nun, Microsoft gehört nicht zu den Organisationen (wie ANSI, IANA, oder andere ISO Name Registration Authorities) die OIDs vergeben können. Daher garantiert das Script keine eindeutige OID. Prinzipiell raten wir unbedingt dazu offiziell registrierte OIDs zu verwenden, nur so lässt sich vermeiden, das man eine Anwendung installieren möchte und diese Anwendung sich verweigert weil die OIDs schon genutzt sind. Oder vielleicht sogar der Name des Attributes? Auch hier ist die Empfehlung klar: Wir raten unbedingt dazu eigene Schema Attribute mit dem Namen der Organisation zu verknüpfen.

 

Das ist das eigentliche Problem leider nicht nur bei der „Wald-und-Wiesen-Schema-Erweiterung“ aus dem Internet Forum, sogar auch bei verschiedenen Anwendungen. Auch in unserem Hause gab es da zugegebenermaßen schon Probleme. Wenn nun also eine Schema Erweiterung implementiert wurde und später eine andere Anwendung sich nicht mehr installieren lässt weil das Attribut schon existiert (aber leider in einer falschen Definition) oder die OID schon vergeben ist. Was dann?

 

Nun, hier muss zunächst festgestellt werden wer dafür Verantwortlich ist, welches Attribut, welche OID ist falsch? Ist es die Anwendung die gerade installiert werden sollte? Dann Glück gehabt. Hier hilft nur sich beim Hersteller zu melden und diese Problematik zu erklären. Der Hersteller steht dann in der Pflicht diesen Fehler auszubügeln. Im Nachhinein geht das natürlich immer schwerer.

 

Nicht nur einmal hatte ich das Problem, das ein Kunde unsere Software installieren wollte (z.B: Windows 2003, 2008 Forestprep, Office Communication Server, SFU o.ä.) und dabei über bereits existierende Attribute mit gleichem Namen oder bereits vergebene OIDs gestolpert ist. Hier wieder raus kommen ist nicht ganz einfach. Eine Schema Erweiterung kann nicht rückgängig gemacht werden, das ist ein Fakt. Wie jedoch nun den Kunden weiterhelfen? Wenn man das Attribut nicht löschen kann, das falsche Attribut schon im Schema drin ist und daher eine wichtige Anwendung nicht eingesetzt werden kann – bleibt dann etwas anderes als eine Migration in einen neuen Forest? Meistens – ja. Doch es kann durchaus sein, das eine Migration die einzige Lösung ist. Wie kann man das also umgehen?

 

Zunächst muss man sich klar sein, welche Anwendung für einen wichtiger ist. Die, die schon installiert ist und den Fehler verursacht oder die, die neu installiert werden soll und sich aufgrund des Fehlers verweigert? In meinen Fällen hat hier immer die neue Anwendung gesiegt, die Kunden haben immer bewusst in Kauf genommen, dass die alte Anwendung nicht mehr funktionieren wird. Das ist leider ein Grundübel wenn man schon soweit ist. „Es kann nur einen geben“ – dieses Prinzip gilt auch hier.

 

Hier nun eine Script Vorlage für eine LDIF Datei mit der man bestehende Attribute „überarbeiten kann“. Selbstverständlich ist dies nur eine Vorlage und kann nicht ohne Anpassung eingesetzt werden. Wer das macht und hierbei einen Fehler macht, dem sei die Lektüre zu ADMT empfohlen: „Wie migriere ich in einen neuen Forest.“

 

Die Schritte sind im einzelnen:

-       Überprüfen ob das Attribut Referenzen im „mayContain“ hat bzw. bei anderen drin steht

-       Diese Referenzen entfernen

-       Die LinkID entfernen

-       Das Schema Attribut umbenennen

-       Evtl. den alten RDN entfernen

-       Dann das Attribut neu und korrekt anlegen

-       Evtl. „mayContain“ Einträge wieder ergänzen

 

Dies noch ergänzt mit schemaUpdateNow an den richtigen Stellen. Wie bereits erwähnt, das Beispiel enthält alle notwendigen Schritte, muss aber noch mit Kleinigkeiten für den SchemaUpdate ergänzt werden. Da ich mich ja im Anfang über „Wald-und-Wiesen“ Schema Erweiterungen aus Internetforen mokiert habe, kann ich hier natürlich keine Anleitung liefern mit der man per Copy & Paste sein Schema unwiderruflich schädigen kann. Daher ist dies hier bitte als theoretische Abhandlung und Aufzeigen des Machbaren zu verstehen. Wer also in solch einen Fehler reinläuft, dem sei geraten bei uns eine Anfrage zu eröffnen damit wir entsprechende Hilfestellung leisten können. Es gibt im Internet durchaus Anleitungen wie man ein Attribut einfach aus dem Schema löschen soll, doch unsere Erfahrungen damit lassen definitiv von solchen Versuchen abraten.

 

Rename + Defunct + Re-create Schema object

 

# +----------------------------------------------------------------+

# I    Der Forest MUSS im Forest Functional Level 2003 sein,

# I    andernfalls geht das mit dem Fehler "duplicate OID" schief

# +----------------------------------------------------------------+

 

# +----------------------------------------------------------------+

# I           Entferne  hjs-MyAttribut von

# I           hjs-MyOtherAttribut maycontain

# +----------------------------------------------------------------+

dn: CN= hjs-MyOtherAttribut,CN=Schema,CN=Configuration,DC=domain,DC=com

changetype: modify

delete: mayContain

mayContain: hjs-MyAttribut

-

 

# +----------------------------------------------------------------+

# I               Entferne   L I N K I D

# +----------------------------------------------------------------+

 

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: Modify

replace: LinkID

LinkID: 0

-

 

# +----------------------------------------------------------------+

# I               Umbenennen des   A T T R I B U T

# +----------------------------------------------------------------+

 

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: Modify

replace: lDAPDisplayName

lDAPDisplayName: hjs-MyAttribut -Defunct

-

 

# +----------------------------------------------------------------+

# I       Note:

# I       kein abschließendes "-" in der Zeile nach deleteoldrdn

# +----------------------------------------------------------------+

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: modrdn

newrdn: CN= hjs-MyAttribut -Defunct

deleteoldrdn: 1

 

# +----------------------------------------------------------------+

# I           D E F U N C T  hjs-MyAttribut

# +----------------------------------------------------------------+

 

dn: CN=ms- hjs-MyAttribut -Defunct,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: modify

replace: isDefunct

isDefunct: TRUE

-

 

# +----------------------------------------------------------------+

# I          Neu Erstellen des Attributes

# +----------------------------------------------------------------+

 

dn: CN= hjs-MyAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: add

adminDescription: hjs-MyAttribut

adminDisplayName: hjs-MyAttribut

description: Beispiel Attribut für Schema Erweiterungsblog.

objectclass: attributeSchema

attributeID: <hier nun die korrekten Werte aus der Schema LDIF Datei>

schemaIDGUID:: <hier nun die korrekten Werte aus der Schema LDIF Datei>

oMSyntax: <hier nun die korrekten Werte aus der Schema LDIF Datei>

attributeSyntax: <hier nun die korrekten Werte aus der Schema LDIF Datei>

linkID: <hier nun die korrekten Werte aus der Schema LDIF Datei>

usw.

 

 

# +----------------------------------------------------------------+

# I           hjs-MyAttribut zuo hjs-MyOtherAttribut

# I           maycontain hinzufügen

# +----------------------------------------------------------------+

dn: CN= hjs-MyOtherAttribut,CN=Schema,CN=Configuration, DC=domain,DC=com

changetype: modify

add: mayContain

mayContain: <hier nun die korrekte Attribut ID des neuen, korrekten Attributes>

-

 

Nun zurück zu der Frage:

-       Was kann oder sollte ich tun um bei einer Schema Erweiterung größtmögliche Sorgfalt walten zu lassen

 

1.)   Entweder gehört Vertrauen zum Vendor der Schema Erweiterung dazu oder man muss überprüfen (geht nur bei den ISO Name Registration Authorities) ob diese Erweiterungen alle korrekt registriert wurden.

2.)   Dann gehört Testen dazu. Ideal ist es (nach der Erstellung eines aktuellen Backups) den Schema FSMO und einen direkten Replikationspartner offline zu nehmen, auf dem Schema FSMO das Schema erweitern und auch noch die Replikation beobachten. Wenn die Erweiterung erfolgreich war und auch die Replikation keine Probleme aufwirft, dann kann ich mit beiden DCs wieder online gehen und diese replizieren die Schema Erweiterung raus.

 

 

Schöne Grüße, Hans-Jürgen
Posted: Tuesday, August 05, 2008 4:06 PM by dedsHansJürgen | 3 Comments
Filed under: ,
Schutz vor Account Lockouts auch für andere Konten als “Administrator”?

Hallo, Fabian hier. Neulich habe ich an einer Kundenanfrage gearbeitet, bei der ich feststellen mußte, daß die Antwort bisher nicht besonders gut dokumentiert bzw. in unseren Dokumentationen nicht sonderlich gut herausgearbeitet wurde:

Ist es möglich, neben dem ersten Administrator Konto (standardmäßig mit dem sAMAccountName “Administrator”) einer Windows Server 2003 Domäne, auch andere Benutzerkonten vor Account Lockouts zu schützen?

Um nicht einfach nur “nein” zu sagen, hier ein paar erläuternde Sätze dazu:

Standardmäßig ist das erste Benutzerkonto einer Domäne vor Account Lockouts (deutsch: “Kontosperrungen”) geschützt. D.h. ist auf einer Domäne eine Password Policy (deutsch: “Kennwortrichtlinie”) inklusive Account Lockout Policies (deutsch: “Richtlinie für Kontosperrung”) verknüpft, die beispielsweise nach 10 ungültigen Anmeldeversuchen das entsprechende Benutzerkonto sperrt, ist das “Administrator” Konto (oder mit anderem Namen, falls manuell umbenannt) davor geschützt, bei fehlschlagenden Logins gesperrt zu werden.

Man kann dieses Verhalten zwar auch ändern (siehe http://msdn.microsoft.com/en-us/library/ms679431(VS.85).aspx und http://support.microsoft.com/default.aspx?scid=kb;EN-US;885119), jedoch ist das selbsterklärend nicht immer und in jeder Umgebung uneingeschränkt empfehlenswert. ;-)

Diese “Sperr-Resistenz” ist über den Schutz der RID (also “Relative Identifier” oder in diesem Fall auch “Benutzer ID”) dieses Kontos gewährleistet. Der entsprechende Account hält die RID “500” als letzten Teil seiner SID, so z.B. “S-1-5-21-105687452-965872365-2697845569-500”. Diese RID wird über die Konstante “DOMAIN_USER_RID_ADMIN” mit dem hexadezimalen Wert “0x000001F4” (= dezimal “500”) zur Verfügung gestellt, siehe http://msdn.microsoft.com/en-us/library/cc245516.aspx. Diese Konstante ist hardcoded in der Funktion, die die Account Lockouts für das “Administrator” Benutzerkonto in einer Domäne verhindert, und kann daher nicht verändert werden. Als Konsequenz ist es unter Windows Server 2003 innerhalb einer Domäne nicht möglich, zusätzliche Konten vor dem Account Lockout / der Kontosperrung zu schützen.

Muß man ein solches Account Lockout verhindern, gibt es im Moment zwei Möglichkeiten:

  1. Jede Domäne stellt eine Sicherheitsgrenze dar. Sind also bestimmte Konten besonders schützenswert, kann man diese in einer (Ressourcen-) Domäne erzeugen, die mit einer eigenen Domain Password Policy ausgestattet wird. In dieser Password Policy kann das das Account Lockout abgeschaltet oder die entsprechenden Werte verändert werden.
  2. Unter Windows Server 2008 gibt es die sogenannten “Fine Grained Password Policies”, die eigene Password Policies (und damit auch eigene Account Lockout Einstellungen) für Benutzer oder Globale Gruppen erlauben. Hierfür muß jedoch die Domäne auf den Domänenfunktionsmodus “Windows Server 2008” angehoben werden. Das bedeutet, daß alle DCs dieser Domäne auf Windows Server 2008 laufen müssen.

Sind zusätzlich “schützenswerte” Accounts von Account Lockouts in Windows Server 2003 Umgebungen betroffen, sollten natürlich die Ursachen dafür herausgefunden werden. In manchen Fällen kann es jedoch Hintergründe für die Lockouts geben, die nicht so einfach behoben werden können (oder sollen) und die beiden oben genannten Workarounds keine Alternative darstellen. In diesem Fall wäre eine denkbare “quick & dirty” Lösung, im besten Fall auf dem PDC-Emulator der entsprechenden Domäne je nach Anforderung alle 5 bis 15 Minuten die entsprechenden Accounts per Script, welches als geplanter Task läuft, wieder zu entsperren. Jedoch muß man sich hier im Klaren darüber sein, daß dies keine empfohlene Variante ist, da man sich damit neben einigen Performance-, Replikations- und Überwachungsschwierigkeiten auch eine große Sicherheitslücke in die Umgebung reißen kann.

Viele Grüße, Fabian.

Posted: Monday, July 28, 2008 5:01 PM by dedsFabian | 2 Comments
Filed under:
Hilfe zur Selbsthilfe - "Deutschinstallierer" und die Knowledge Base

Ich möchte meinen Einstand in diesem Blog mit einem ganz allgemeinen Beitrag beginnen. Im folgenden werde ich also nicht die PKI-Probleme dieser Welt lösen und auch nicht das Ende aller Login-Probleme verkünden.

Die Knowledge Base (KB) ist sicher jedem Leser hier bekannt und jeder hat bestimmt schon viele, viele Suchanfragen abgeschickt. Das Verhältnis zwischen "gesucht" und "gefunden" ist naturgemäß ungleichmäßig verteilt - leider zu Ungunsten des Suchenden. Dabei stellt die KB eine enorme Quelle an Informationen und Lösungen zu bekannten Problemen dar. Aber nicht immer ist es einfach, die gesuchte Information zu finden. Als eine Hürde erweist sich dabei die maschinelle Übersetzung der englischsprachigen Artikel dar. Stilblüte gefällig? Kein Problem:

Aus

"When you use the Microsoft Windows Server 2003 Active Directory Users and Computers Microsoft Management Console (MMC) snap-in to change the Terminal Services Home Folder path on the Terminal Services Profile tab of the user properties dialog box, the Terminal Services Home Folder path will have the following permissions (...)"

wird

"Wenn Sie das Microsoft Windows Server 2003 Active Directory Users and Computers Microsoft Management Console (MMC) verwenden, wird über die folgenden Berechtigungen Snap-In verfügen, den Terminal Services Home Folder Pfad auf der Registerkarte Terminaldienstprofile des Benutzereigenschaftsdialogfelds dem Terminal Services Home Folder Pfad zu ändern (...)"

und damit ist eines klar: wer Englisch kann ist klar im Vorteil  ;)

Wer sein Betriebssystem in Englisch installiert, der hat es also etwas leichter, da die englischsprachigen Fehlermeldungen recht einfach in der Suchmaske der KB verwendet werden können. Nur gibt es eben auch eine signifikante Menge an "Deutschinstallierern" und diese geraten in diesem Zusammenhang etwas ins Hintertreffen: Hilfestellungen zu deutschsprachigen Fehlermeldungen im Web zu finden ist schwieriger. Punkt.

Aber es gibt einen Stern am Horizont: Die "Terminologiesuche" im "Microsoft-Sprachenportal" nutzt eine Datenbank, in der die lokalisierten Strings hinterlegt sind. Es wird also nicht automatisiert übersetzt, was wiederum hat zur Folge, dass die Ergebnisse richtig sind dafür aber weniger Anlass zum Schmunzeln geben.

Um eine deutschsprachige Fehlermeldung ins Englische zu übersetzten, muss als Sprache "Deutsch" ausgewählt sein und der Haken bei "Suchrichtung umkehren" gesetzt werden, da "Englisch" als "Sprache" nicht ausgewählt werden kann. Hier ein praktisches Beispiel basierend auf dem Userenv-Event #1054:

Die Suche nach

"Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden."

führt zu

"Windows cannot obtain the domain controller name for your computer network."

In einem maschinell übersetzten Artikel sieht die gleiche Meldung schonmal so aus:
(http://support.microsoft.com/kb/827182/de)

"kann den Domäne-Controller-Namen für Ihr Computernetzwerk nicht ermitteln."

Wer danach sucht, wird schwerlich fündig werden.

Interessant ist die Terminologiesuche auch für multinationale Unternehmen, die in den Niederlassungen auf einem englischen Betriebsystem das MUI für das jeweilige Land verwenden.

.olaf

Posted: Wednesday, July 23, 2008 1:43 PM by Olaf Knobloch | 0 Comments
Filed under:
Grundsätzliche Informationen zum Security Event Logging / Auditing

Hallo, Fabian am Apparat. Ab und an bearbeiten wir auch Anfragen, in denen wir auf ein Security Logging / Auditing angewiesen sind, so z.B. bei ungewollten Account Lockouts oder Rechteänderungen auf Objekten, die nachvollzogen werden sollen. Es gibt dabei einige Grundsätze, die man nach Möglichkeit bei einem Logging beachten sollte.

Dieser Eintrag behandelt (wie immer) nur einen Teil der Thematik und erhebt keinen Anspruch auf Vollständigkeit. Es wird in diesem Beitrag auf Windows Server 2003 eingegangen. Unter Windows Server 2008 haben sich einige Dinge geändert, auf die hier nicht weiter eingegangen wird. Interessierte können z.B. hier einen kurzen Blick in die Neuerungen werfen: http://blogs.technet.com/askds/archive/2007/10/19/introducing-auditing-changes-in-windows-2008.aspx


Größe der Logfiles / Serverperformance - Allgemeines

Bei einem Auditing von Objektänderungen im Active Directory als auch auf NTFS Filesystem Ebene z.B. auf Fileservern fallen je nach Nutzung der Dienste unter Umständen immense Datenmengen an, die durchaus zu Performanceproblemen auf den jeweiligen Servern führen können.

Hier spielen bei den DCs neben den Änderungen an Objekten auch weitere Prozesse hinein, so z.B. die An- und Abmeldungen von Benutzern oder ggf. der Zugriff auf Objekte wie Drucker o.ä. Schon bei Fileservern mit einer durchschnittlichen Zugriffsfrequentierung in kleineren Umgebungen kann ein Auditing eine große Menge an Audit-Daten generieren, da neben den Änderungen, Löschvorgängen o.ä. das Lesen von Attributen eines AD-Objekts, einer Datei oder eines Ordners (je nach Audit Setting) ebenfalls geloggt werden kann.

In beiden Fällen, also dem Loggen von zusätzlichen Auditing Security Events auf den DCs als auch auf den Fileservern, werden pro zu loggender Aktion mehrere Events geloggt. So kann ein einzelner Zugriff auf eine Datei oder einen Ordner mehr a