Markus Bäker

Bei einigen Automatisierungen ist es notwendig den Profilpfad eines Benutzers auszulesen und einen eventuellen DFS Pfad in einen physikalischen Pfad aufzulösen.

Hierfür habe ich eine kleine Batch-Datei geschrieben:

@echo off
set samaccountname=%~1
for /f "tokens=* usebackq" %%a in (`AdFind.exe -f "samaccountname=%samaccountname%" profilePath /list`) do (
set profilePath=%%a
)

for /f "delims=<> usebackq tokens=1,2,3,4,5" %%a in (`dfsutil diag viewdfspath %profilepath%`) do (
     if NOT %%e.==. set profilePath=%%e
)

echo %profilePath%

Der Profilpfad wird in Zeile 3 mit Hilfe von adfind anhand des Benutzernamens ermittelt, per for ausgewertet und an eine Umgebungsvariable übergeben.
Diese wird in Zeile 7 an dfsutil übergeben, dass mit dem Befehl diag den physikalischen Pfad anzeigt (ermittelt mit dem aktuellen Standort). Die Ausgabe wird erneut mittels for ausgewertet, wobei die Zeilen an den Größer- und Kleinerzeichen getrennt werden. An fünfter Stelle steht dabei der physikalische Pfad. Handelt es sich bei dem Profilpfad um keinen DFS basierten, dann ist die fünfte Stelle leer und wird daher nicht an die Variable übergeben.

Innerhalb einer anderen Batch-Datei kann diese einfach per call getprofilepath.cmd SAMACCOUNTNAME aufgerufen und die Variable profilePath später weiterverwendet werden.

Probembeschreibung: In einigen sichereren Umgebungen sollen servergespeicherte Profile beim Abmelden gelöscht werden. Nach einem Upgrade auf IE8 war dies bei einem Kunden nicht mehr der Fall. Es blieben immer Reste von Anwendungsdateien zurück. Im Speziellen fiel dabei die index.dat vom IE8 auf.

Fehleranalyse: Um der Ursache auf den Grund zu gehen, wurde das Debugging bei der Profilverarbeitung erhöht: Aktivieren des Environment Debug Loggings von Winlogon (http://support.microsoft.com/kb/221833/en-us). Die dabei im Log gefundenen Fehler wurde an Google übergeben

Ursache: Ursache ist ein Fehler im IE8 mit einer speziellen Gruppenrichtlinieneinstellung (Hinzufügen von Trusted Domains per GPO). Das Problem ist hier beschrieben: http://support.microsoft.com/kb/974277/en-us

Der darin beschriebene Workraround mit einer manuellen Registryeinstellung wurde getestet und war erfolgreich. Folgende Einstellung muss durchgeführt werden:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_USE_IETLDLIST_FOR_DOMAIN_DETERMINATION]

"winlogon.exe"=dword:00000000

Diese Einstellung ist natürlich auch per GPO verteilbar.

Mir begegnen regelmäßig Situationen, in dem im ADDS und Eventlog bestimmte Dinge nachgeschaut werden müssen. Dabei gehen viele direkt ins Eventlog und suchen nach dem Namen des gesperrten Users oder ähnliches. Gerade in größeren Umgebungen ist diese Vorgehensweise sehr ineffizient und auch nicht präzise, da andere Ereignisse die Suchergebnisse beeinträchtigen können.

Daher sollte die Devise sein: Zuerst Zeitpunkt und Ort herausfinden und dann im Eventlog nachschauen.

Solange am Objekt nichts geändert wurde, ist der letzte Änderungszeitpunkt und Ort eigenschaftsgenau kontrollierbar.

Dazu ein kleines Beispiel: Ein Anwender beschwert sich, dass sein Konto ständig gesperrt wird. Er hat vor einigen Stunden sein Kennwort geändert.

Bevor das Konto zurückgesetzt wird, werden noch schnell wichtige Eigenschaften mittels repadmin extrahiert:

repadmin /showobjmeta * "CN=User1,OU=Benutzer,,DC=temp,DC=local" > user.txt

Dabei werden die Metadaten des per DN angegebenen Objektes (CN=…) auf allen Domänenkontrollern (*) ausgelesen und in eine Textdatei gespeichert.

In der Textdatei steht jetzt pro Domänencontroller eine Liste aller Attribute des Objektes und weitere wesentliche Parameter. Für dieses Beispiel relevant ist die LockoutTime:

153243532 Standardname-des-ersten-Standorts\dc1   1100175 2010-11-23 11:11:11   37 lockoutTime

Dieser Eintrag zeigt deutlich, dass das Attribut lockoutTime (also wann das Konto gesperrt wurde) auf dem Domänencontroller dc1 um 11:11 geändert wurde.

Somit kann man direkt diese Daten nutzen und ins Securitylog vom dc1 um 11:11 schauen.

Ereignistyp:    Fehlerüberw.

Ereignisquelle: Security

Ereigniskategorie:      (9)

Ereigniskennung:        675

Datum:          23.11.2010

Zeit:           11:11:11

Benutzer:               NT-AUTORITÄT\SYSTEM

Computer:       dc1

Beschreibung:

Fehlgeschlagene Vorbestätigung:

         Benutzername:   user1

         Benutzerkennung:                TEMP\user1

         Dienstname:     krbtgt/TEMP.LOCAL

         Vorauthentifizierungstyp:       0×2

         Fehlercode:     0×18

         Clientadresse:  192.2.0.10

Die Sperrung ging als vom Client 192.2.0.10 aus. Eine Rückfrage beim User ergibt direkt, dass er das Kennwort an einem anderen Client geändert hat, aber an dem oben angegebenen Client schon länger angemeldet ist.

Aufwand: 5 Minuten. Wilde Sucherei: Minimal. Präzision: Hoch

Hier mal eine kleine Batchdatei zur Verteilung von WinZip inkl. des Lizenzfiles:

@echo off

rem alte winzip version deinstallieren

MsiExec.exe /X{CD95F661-A5C4-44F5-A6AA-ECDD91C240B5} /l* %systemroot%\deinstall_winzip111.log /qn REBOOT=REALLYSUPPRESS

rem copy Lizenzfile to all Users profile

md “%ALLUSERSPROFILE%\WinZip\”

copy /y “%~dp0winzip.wzmul” “%ALLUSERSPROFILE%\WinZip\”

rem neue Version installieren:

rem Erklärung der Parameter:

rem /noqp = no quickpick icon in system tray

rem /notip = no tip of the day

rem /noc4u = don’t check for updates

rem /nopredefinedjobs = no predefined sample jobs in the Winzip menu

rem ADDDESKTOPICON=0 (Disable the WinZip Desktop icon to the user’s desktop)

rem ADDMENUGROUP=1 (Add a WinZip Menu Group item to… Start-> All Programs -> WinZip for each user )

rem ADDSTARTMENU=0 (Disable WinZip to the top of each user’s Start Menu)

rem  ALLUSERS=1 (per Machine)

rem Accept=Yes (Accept EULA)

msiexec /i “%~dp0wz121gev.msi” /qn /l* %systemroot%\install_winzip121.log ADDDESKTOPICON=0 ADDMENUGROUP=1 ADDSTARTMENU=0 ALLUSERS=1 Accept=Yes INSTALLCMD=”/noqp /notip /noc4u /nopredefinedjobs /autoinstall” REBOOT=REALLYSUPPRESS /m winzip.mif

In SCCM ein Package mit den Installationsfiles erstellen. Die WinZip MSI Version von der CD kopieren und ins gleiche Verzeichnis die Lizenzdatei hineinstellen. Als Programm die oben beschriebene Batchdatei eintragen. Bei den  Reporting Information wird im Dateinamen winzip eingetragen.

Mein Standardvorgehen:

• Möglichst keine statischen Pfade, sondern immer Variablen (z.B. %systemroot% anstatt c:\windows)
• Möglichst immer absolute Pfade zu Dateien – man weiss ja nie worauf gerade der aktuelle Pfad zeigt. Daher immer ein %~dp0 (%0: Pfad zu Batchdatei, ~: Falls “, dann entfernen, d: Laufwerksbuchstabe, p: Pfad, %~dp0: Pfad zur Batchdatei ohne Name der Batchdatei (aber mit \ am Ende))
• Möglichst viel loggen, dass hilft beim Debuggen
• Möglichst immer die original Setupdateien verwenden. Der Hersteller dürfte dort bereits sein KnowHow eingebaut haben.

Noch Fragen? -> Comment!

Um genaue Portangaben bei einer AD Replikation machen zu können, habe ich innerhalb eines VMWare Servers 2.0 eine Testumgebung mit zwei Domänencontroller und einer Firewall dazwischen aufgebaut. Leider ermöglicht VMWare dort nur sehr eingeschränkte Netzwerkeinstellungen (im ESX wäre es einfacher).

Als einfache Firewall nutzte ich M0n0wall: Eine sehr kleiner Linuxfirewall mit vielen netten Features.  Bei VMWare existiert eine fertige Appliance zum herunterladen.

Da ich nur eine interne Netzwerkkarte zur Verfügung hatte, habe ich Monowall drei Netzwerkkarten ins gleiche “Host-Only” Netz gegeben. Eine davon wurde als externes Interface definiert und nicht weiter verwendet – die nächste als internes Interface (LAN) und die letzte als optionales Interface.

Über die Weboberfläche habe ich dann das optionale Interface als LAN2 umbenannt.

LAN hat eine Adresse im Subnetz 192.168.58.0/24 erhalten. LAN2 eine Adresse im Netzwerk 192.168.59.0/24. Die DCs wurden ebenfalls jeweils in unterschiedliche Subnetze gepackt und als Gateway die jeweilige Adresse der Netzwerkkarte von M0n0wall angegeben.

Um die beiden Netzwerkkarten zu verbinden müssen statische Routen in der Firewall hinterlegt werden:

Statische Routen:

Interface Network Gateway Description

LAN2 192.168.58.0/24 192.168.58.15

LAN 192.168.59.0/24 192.168.59.1
Normalerweise gehen Pakete auf diesen internen Routen nicht über die Firewall. Um diese doch zu filtern, ist ein Einstellung zu ändern:

Filtering bridge Enable filtering bridge
This will cause bridged packets to pass through the packet filter in the same way as routed packets do (by default bridged packets are always passed). If you enable this option, you’ll have to add filter rules to selectively permit traffic from bridged interfaces.

Danach gelten auch die Firewallregeln für den Verkehr zwischen LAN und LAN2.

Mit diesem Setup konnte ich dann genau die notwendigen Ports für die Replikation inklusive der festgelegten dynamischen RPC Ports für die AD Replikation und dem FRS ermitteln.

Ein kleines Skript um 2000 User und 20 OUs mit jeweils weiteren 10 OUs anzulegen:

setlocal ENABLEDELAYEDEXPANSION
set basedn=OU=Test-OUs,dc=bktest,dc=intern

dsadd ou %basedn%

for /L %%i in (1,1,20) DO (
dsadd ou “OU=Test%%i,%basedn%”
FOR /L %%a in (1,1,10) do (
dsadd ou “OU=Test%%a,OU=Test%%i,%basedn%”
for /L %%e in (1,1,10) do (
dsadd user “CN=User%%i-%%a-%%e,OU=Test%%a,OU=Test%%i,%basedn%” -samid User%%i-%%a-%%e -fn Test%%a -ln User%%i%%e -pwd T%%i-%%a-%%eest
)
)
)
endlocal

Die Variable BaseDN muss entsprechend des eigenen ADDS Aufbaus angepasst werden.

Um schnell ein Zertifikat eines ADDS Servers zu überprüfen, bietet sich überraschender Weise ein Webbrowser wie der Firefox auf. Trägt man dort in der Adressleiste https://dns-name-des-domänencontrollers:636 ein. Beim Aufruf erscheint unten links das bekannte SSL-Schloss, dass man zur genaueren Inspektion nutzen kann.

Aber: Neuere Firefoxversionen verhindern https Verbindungen auf ungewöhnlichen Ports. Daher muss hier eine Ausnahme für ldaps eingetragen werden:
Um in die erweiterten Einstellungen des Firefoxes zu gelangen muss man in die Adressleiste about:config eingeben. Dort als zusätzlichen Eintrag network.security.ports.banned.override hinzufügen und als Wert den Port 636 hinterlegen (weitere Ports kann man durch Komma getrennt eingeben):

Details s.a. http://kb.mozillazine.org/Network.security.ports.banned.override

Heute konnte ich mir endlich die Zeit nehmen einen Alert im SCOM genauer zu betrachten. Obwohl über 2GB auf der NTDS Platte des DCs frei waren und die Subdomäne nur eine Datenbankgröße von 512MB hat, meldete SCOM regelmäßig, dass die Platte zu voll sei.

In diesem Fall sieht die Berechnung folgendermaßen aus:

Name der Regel im MP: AD Database Drive Free Collection

Aktuelle Größen:

ntds.dit: 454672 kbytes
ntds.logs: 10240 kbytes (das MP Skript betrachtet nur das edb.log File)

Folgende Defaultparameter werden an das Skript übergeben (sind überschreibbar):
<Threshold_DIT>0.2</Threshold_DIT> (also 20%)
<Boundary_DIT>500000</Boundary_DIT>
<Boundary_LOG>200000</Boundary_LOG>
<Threshold_LOG>0.05</Threshold_LOG>

Die Berechnung sieht so aus (aus dem Skript kopiert):

lReserveLog = lSizeDB * CDbl(LOG_THRESHOLD)
If (lReserveLog < LOG_BOUNDARY) Then
lReserveLog = LOG_BOUNDARY
End If
lReserveDB = lSizeDB * CDbl(DIT_THRESHOLD)
If (lReserveDB < DIT_BOUNDARY) Then
lReserveDB = DIT_BOUNDARY
End If

Anhand dieses Beispiels:

• DIT: 454MByte*0.2 -> 90,8MB (<500000) -> Boundary 500MByte
• LOG: 454MByte*0,05 -> 22,7MB (<200000) -> Boundary 200MByte

Die Berechnung der Logfilegröße basiert auf der ADDS Datenbankgröße (DIT)

Die Logdateien und die DB liegen auf der gleichen Partition. Daher gilt:

If (lFreeSpaceDB < (lReserveDB + lReserveLog)) Then
bSuccess = False

strMessage = “Free space (” & lFreeSpaceDB & “KB) on drive ” &  UCase(Left(strPathDB, 2)) & ” is lower than the required reserved space for AD Database and Log file. It should be at least ” & (lReserveLog + lReserveDB) & ” KBytes.”

Somit muss der freie Platz größer als 700MByte sein. Was in diesem Beispiel zutrifft.

Trotzdem erscheint im Eventlog und im SCOM die Fehlermeldung:

AD Database and Log : Free space (2614404KB) on drive D: is lower than the required reserved space for AD Database and Log file.
It should be at least 3182704 KBytes.

Wenn man 3182704 durch die DB Größe (454672) teilt erhält man exakt 7. Die entspricht 2+5, d.h. es gibt ein Problem mit dem Komma-Trenner (, in deutsch, . in english)

Ich habe dies überprüft, in dem ich das Skript angepasst habe, damit es die erhaltenen Parameter auch in die Registry speichert (setData..):
Die Boundary Werte sind korrekt, aber Threshold Werte sind auf 5 (log) und 2 (dit) !

Lösung:

Override auf deutschen DCs mit 0,05 und 0,2

Test:
Die Datenbankplatte wurde etwas gefüllt. Kurz darauf wurde folgende korrekte Meldung generiert:

AD Database and Log : Free space (225996KB) on drive D: is lower than the required reserved space for AD Database and Log file. It should be at least 700000 KBytes

Natürlich könnte man als Alternativen Workaround immer die 7fache Größe der Datenbank als freien Speicherplatz bereitstellen, aber gerade wenn man Domänencontroller virtualisiert und die Platten vollständig reserviert, ist dies kein gangbarer Weg. Microsoft sollte hier wie üblich auf die Ländereinstellungen achten! (Oder Nachkommastellen vermeiden. Die Prozentwerte könnten auch als 5% angegeben werden, anstatt 0.05)