Ich hab mal früh am Morgen (kurz vor 9) einen Kunden angerufen, weil ich am Abend vorher festgestellt hab, dass sich seine Firewall verabschiedet hat und man nicht mehr ans Netz und demzufolge höchstwahrscheinlich auch nicht mehr nach extern zugreifen konnte.

Auf meine Aussage hin, dass sein Internetzugang down sei, kam die Antwort, ja das wüsste er bereits, und er hätte mir bereits eine entsprechende Email mit der Fehlermeldung geschickt …

Was sagt man da am Telefon?

Verwandte Beiträge:

1. Drucker, WLAN und Strom
   So, habe gerade per Fernwartung bei einem Kunden einen Drucker...

In vielen Firmen ist die Situation hinsichtlich der Kennwortsicherheit leider katastrophal:

<Story aus der freien Wildbahn>
Da fragt man einen Admin einer großen Organisation nach einem Account, der in der Domäne Rechte hat. Er ruft "Administrator – Passwort ist "Password – hinten mit d"
</Story aus der freien Wildbahn>

Kurzer Ausflug in die Windows-NT-4.0-Geschichte

Vor der Einführung von Windows NT 4.0 SP2 gab es in Windows-Domänen nur die Möglichkeit sehr einfache Kennwortrichtlinien anhand folgender Kriterien zu bilden.

• Kennwortchronik erzwingen
• Maximales Kennwortalter
• Minimale Kennwortlänge
• Minimales Kennwortalter

Seit Windows NT 4.0 Service Pack 2 gibt es zusätzlich die Möglichkeit, eine von MS fest vorgegebene Kennwortkomplexität zu erzwingen.

Diese sieht vor, dass Kennwörter aus mindestens sechs Zeichen bestehen, nicht den Anmeldenamen bzw. Teile davon beinhalten und zusätzlich drei von vier der folgenden Kriterien innerhalb eines Kennwortes einhalten.

• Kennwort beinhaltet Großbuchstaben
• Kennwort beinhaltet Kleinbuchstaben
• Kennwort beinhaltet Sonderzeichen
• Kennwort beinhaltet Ziffern

Gegenwart seit Windows 2000

Was unter Windows NT 4.0 noch umständlich per manuellem Bearbeiten der Registry auf dem PDC (nur da werden Kennworte geändert), umgesetzt werden musste (http://support.microsoft.com/?scid=kb;en-us;1611990), wurde mit Windows 2000 fest in den Sicherheitsrichtlinien des Systems verankert. Die Kriterien allerdings haben sich nicht geändert. Bis heute ist es nicht "out-of-the-box" möglich, eigene Kennwortrichtlinien zu generieren. Lediglich die Länge und Geltungsdauer eines Kennwortes kann vorgegeben werden.

Die Schwächen dieses Systems liegen auf der Hand: Trotz Einhaltung der geforderten Regeln sind relativ einfache Passworte machbar. Jeder Brute-force-Angriff wird diese innerhalb von Sekunden bzw. Minuten cracken. Beispiele hierfür sind "Sommer2005", "Mutti1956" oder ähnlich triviale Konstrukte. Wer sich schon mal @stake LC 5 ( www.atstake.com ) angeschaut hat und damit auf eine Test-SAM losgegangen ist, der weiß, wie schnell so etwas geht.

Abbildung: Crackzeit von "normalen" Kennworten

Problemlösung 1 (Beten/Hoffen)

Man glaubt einfach an das Gute im Menschen und hofft, dass die Benutzer nicht gemerkt haben, dass "Sommer2005" funktioniert. (Darauf sollte man sich aus Sicherheitsgründen natürlich nicht verlassen – Stichwort: Murphy)

Problemlösung 2 (Selber machen)

Man programmiert sich seine eigene passfilt.dll, um die eigenen Richtlinien durchsetzen zu können. Nachteil dabei ist, dass man jemanden kennen sollte, der sich mit C++ auskennt, sofern man das selbst nicht kann. Zusätzlich kommt natürlich immer noch das Risiko dazu, dass der Code nicht so funktioniert, wie es erwartet wird, denn immerhin kommt die .dll dann in einem sicherheitsrelevanten Bereich innerhalb des Betriebssystems zum Einsatz. Im MSDN stellt Microsoft einige Artikel und eine Beispiel passfilt.dll im Sourcecode zur Verfügung.

http://msdn.microsoft.com/library/en-us/secmgmt/security/sample_password_filter.asp

Im Internet finden sich noch einige wenige andere Seiten, die sich mit diesem Thema beschäftigen:

http://www.opencoe.com/accountpassword.htm

http://ntsecurity.nu/toolbox/strongpass

Wie man sieht, gibt es nicht wirklich viele Infos zu solch einem wichtigen Sicherheitsthema in Windows-Netzwerken.

Problemlösung 3 (Kaufen)

Als Drittes besteht noch die Möglichkeit kommerzielle Programme zu verwenden. Eines davon ist Passfilt Pro von Altus Network Solutions, Inc. ( http://www.altusnet.com ).

Es bietet neben der freien Definition von komplexen Kriterien auch noch eine Funktion, die in den Newsgroups immer wieder angefragt wird, aber bisher immer mit der Antwort "geht nicht bzw. nur mit mehreren Domains" beantwortet werden musste. Denn normalerweise existiert nur eine Kennwortrichtlinie pro Domäne. Passfilt Pro MPE hebt diese Begrenzung auf und gestattet bis zu 4 verschieden konfigurierte Richtlinien.

Einen ausführlichen Testbericht bringt der IT-Administrator (www.it-administrator.de) in der Oktoberausgabe 2005, deswegen hier nur eine kurze Gegenüberstellung der Kriterien, die man mittels Passfilt Pro konfigurieren kann.

Vielen Dank an Greg Branham von Altusnet für das Bereitstellen einer Testversion von Passfilt Pro MPE sowie die schnelle Unterstützung bei einigen Fragen, die während der Testphase auftraten.

Verwandte Beiträge:

1. Abgestufte Kennwortrichtlinien endlich komfortabel
   Update 13. April 2012: Das hier vorgestellte Tool scheint nicht mehr...
2. Mehrere Kennwortrichtlinien in einer Domäne
   Endlich ist es soweit! Unterschiedliche Kennwortrichtlinien können innerhalb einer Domäne...
3. Kennwörter selbst zurücksetzen
   Welcher Admin kennt nicht die Anrufe von Benutzern, die ihr...

Basierend auf dem Artikel "Eigene Funktionen in die AD-Tools integrieren" von Nils habe ich das dort vefügbare Beispiel erweitert. Zweck dieser Erweiterung ist es, das extensionAttribute3 modifzieren zu können. Im konkreten Fall wird dieses Attribut genutzt, um eine Kostenstellenzuordnung für eine Cisco-VOIP-Telefonanlage zu schaffen.

Ziel ist es, diese Kostenstelle mittels Kontextmenü direkt über das Nutzerobjekt in Active Directory modifizieren zu können. Hierzu zählt auch die Möglichkeit, einen einmal gesetzten Wert auch komplett löschen zu können.

Das folgende Skript speichert man als extension3.hta z. B. unter c:\windows\system32 ab.

Die Löschroutine löscht den gesetzten Wert ohne nochmalige Sicherheitsabfrage. Also bitte aufpassen.

——– Extension3.hta —————-

1. <HTML>
2. <HEAD>
3.   <TITLE></TITLE>
4.   <HTA:APPLICATION ID="oHTA">
5.   <META NAME="author" CONTENT="Nils Kaczenski und Norbert Fehlauer">
6. </HEAD>
7. <BODY onload="start();">
8. <H2 ID="head"></H2>
9. <TABLE>
10.   <TR>
11.   <TD>Benutzer:</TD>
12.   <TD><P ID="anzeige"></P></TD>
13.   </TR>
14.   <TR>
15.   <TD>[K]ostenstelle</TD>
16.   <TD><input ID="Kosten" accesskey="k"></TD>
17.   </TR>
18.   <TR>
19.   <TD><button onclick="eintragen();"accesskey="e"><U>E</U>intragen</button></TD>
20.   <TD><button onclick="window.close();"accesskey="s"><U>S</U>chließen</button></TD>
21.   <TD><button onclick="loeschen();"accesskey="l"><U>L</U>öschen</button></TD>
22.   </TR>
23. </TABLE>
24. <BR clear="all">
25. <HR>
26. <P Class="klein">© 2003-2007 Nils Kaczenski und Norbert Fehlauer – keine Gewähr! Nutzung auf eigene Gefahr!</P>
27. <SCRIPT language="VBScript">
28. Dim rootDSE
29. Dim objUsr
30. dim strUserDN
31. const ADS_PROPERTY_CLEAR = 1
32. strAdsPath = ""
33. strTitel = "Kostenstelle eintragen"
34. Function auswerten()
35.   strText = oHTA.CommandLine
36.   ' CommandLine enthält, durch Blanks getrennt:
37.   ' – Pfad der HTA-Datei (in Anführungsstrichen)
38.   ' – LDAP-Pfad des AD-Objekts (fallweise mit Anführungsstrichen; inkl.Serverangabe)
39.   ' – Objektklasse ' Das macht die Auswertung etwas aufwändig:
40.   intPosUser = InStrRev(strText," user")
41.   intPosLDAP = inStr(strText, "LDAP://")
42.   if intPosUser <> 0 then 'ist ein Benutzerobjekt
43.   auswerten = mid(strText, intPosLDAP, intPosUser – intPosLDAP)
44.   auswerten = replace(trim(auswerten),"""","")
45.   ' Jetzt sind Gänsefüßchen und Leerzeichen am Anfang/Ende weg
46.   ' auswertung enthält nur noch den distinguishedName,
47.   ' der weiter verwendet werden kann
48.   else
49.   msgBox "Kein User angegeben!"
50.   exit function
51.   end if
52. End Function
53. Sub start()
54.   ' Funktion:
55.   ' Eingabeparameter:
56.   ' Kommentar:
57.   window.resizeTo 400,200
58.   document.title = strTitel
59.   arrText = auswerten
60.   strUserDN = auswerten
61.   if strUserDN = "" then
62.   document.all.anzeige.innerText = "keine Argumente"
63.   Exit Sub
64.   End If
65.   Set rootDSE = GetObject("LDAP://RootDSE")
66.   strDomainname = rootDSE.Get("defaultnamingcontext")
67.   Set domain = GetObject("LDAP://" & strDomainname)
68.   Set objUsr = GetObject(strUserDN)
69.   strName = objUsr.get("displayName")
70.   document.title = strTitel & ": " & strSamName
71.   On Error Resume Next
72.   strKostenstelle = objUsr.get("extensionAttribute3")
73.   if err.number <> 0 then Err.clear ' kein Eintrag da!
74.   On Error Goto 0
75.   document.all.anzeige.innerText = strName
76.   if strKostenstelle <> "" then document.all.Kosten.value = strKostenstelle
77. End Sub
78. Sub eintragen()
79.   ' Funktion:
80.   ' Eingabeparameter:
81.   ' Kommentar:
82.   If strUserDN = "" Then
83.   MsgBox "Kein User angegeben!"
84.   Exit Sub
85.   End If
86.   strCheck = document.all.Kosten.value
87.   If IsNumeric(strCheck) Then
88.   objUsr.Put "extensionAttribute3", strCheck
89.   objUsr.SetInfo
90.   MsgBox "Kostenstelle eingetragen!", vbInformation, strTitle
91.   window.close
92.   Else
93.   MsgBox "Keine Zahl angegeben: " & strCheck, vbCritical, strTitle
94.   End If
95. End Sub
96. Sub loeschen()
97.   ' Funktion:
98.   ' Eingabeparameter:
99.   ' Kommentar:
100.   If strUserDN = "" Then
101.   MsgBox "Kein User angegeben!"
102.   Exit Sub
103.   End If
104.   objUsr.PutEx ADS_PROPERTY_CLEAR, "extensionAttribute3", vbNullString
105.   objUsr.SetInfo
106.   MsgBox "Kostenstelle gelöscht!", vbInformation, strTitle
107.   window.close
108. End Sub
109. </SCRIPT>
110. </BODY>
111. </HTML>

——– Extension3.hta —————-
Mit folgendem Script wird die extension3.hta im Rechtsklickmenü verfügbar. Hierzu adminmenu.vbs ausführen. Der Wert "strValue", der angibt, wie der Menüpunkt heißen soll, muss entsprechend angepasst werden.
——— Adminmenu.vbs ———————

1. Set root= GetObject("LDAP://rootDSE")
2. strConfig = root.Get("configurationNamingContext")
3. strPath = "LDAP://cn=user-Display,cn=407,cn=DisplaySpecifiers," & strConfig
4. Set obj= GetObject(strPath)
5. strValue = "5,Kostenstelle modifizieren,Extension3.hta"
6. arrValue = Array(strValue)
7. obj.PutEx 3, "adminContextMenu", arrValue
8. obj.SetInfo
9. msgBox "Kontextmenüeintrag hinzugefügt: " & strValue

Verwandte Beiträge:

1. Eigene Funktionen in die AD-Tools integrieren
   Das Schema ist erweitert worden. Wie können die neuen Attribute...
2. Wie kann ich meine Benutzer als "Nachname, Vorname" anzeigen?
   In der Standardeinstellung werden in Active Directory die Namen von...
3. Wie frage ich gezielt Benutzerobjekte ab?
   Der LDAP-Standard sieht unglücklicherweise vor, dass die Objektklasse "user" nicht...

Das Problem

Stellen Sie sich vor, Sie sind der Administrator eines mittelgroßen bis großen Netzwerkes. In diesem Netzwerk nutzen Sie Active Directory als Verzeichnisdienst und Exchange als Mailsystem. Als Clientbetriebssystem setzen Sie jedoch auf freie Auswahl. (Wie ich erfahren durfte, ist das in manchen Institutionen so üblich.)

Aus Sicherheitsgründen wurde im Active Directory eine Kennwortrichtlinie definiert und ein maximales Kennwortalter festgelegt. Windows-PCs, die ins Active Directory integriert sind, benachrichtigen die Benutzer beim Anmelden über ein Ablaufen des Kennworts. Auch Outlook, Outlook WebAccess oder Entourage 2004 sind in der Lage, den Benutzer auf ein ablaufendes Kennwort hinzuweisen.

Abbildung 1: Kennwortänderungsmeldung Entourage 2004 (Quelle: Microsoft-Webseite)

Benutzen Ihre User allerdings Protokolle wie IMAP4 oder POP3, melden sich über VPN-Netzwerk an oder fahren ihren PC nur in den Ruhezustand, dann werden sie nicht über die anstehende Passwortänderung benachrichtigt. Auch Windows Mobile auf mobilen Geräten kann keine Erinnerung erzeugen. Schlecht, wenn man auch im Urlaub auf den Zugang zum Postfach angewiesen ist.

Die Lösung

1. Abhilfe kann man sich wie fast immer über Skriptlösungen schaffen. Beispielsweise hat Michael B. Smith ein entsprechendes Skript auf seinem Blog veröffentlicht (Link korrigiert am 8. November 2008):
   [Sending an e-mail to users whose password is about to expire - Michael's meanderings...]
   http://theessentialexchange.com/blogs/michael/archive/2007/11/13/sending-an-e-mail-to-users-whose-password-is-about-to-expire.aspx
   Das setzt natürlich voraus, dass man entweder selbst skripten kann oder jemanden kennt, der das kann.
2. Wie immer gibt es aber auch Produkte von kommerziellen Anbietern, die das Ganze einfach verpackt und mit zusätzlichen Features versehen vertreiben. Ein solches Tool ist "Password Reminder Pro" von Sysoptools.

Password Reminder Pro 

Die Funktionsweise des Programms ist dabei relativ einfach. Benutzerkonten mit ablaufenden Kennworten werden aus dem Active Directory ausgelesen und anhand des vordefinierten Wertes der Passwortrichtlinie benachrichtigt. Die Benachrichtigung erfolgt dabei mittels SMTP. Ist kein Exchange-Server im Einsatz, so sind die Emailadressen der Nutzer manuell in das Active Directory einzupflegen, damit die Benachrichtigung durch Password Reminder Pro zugestellt werden kann.

Der Hersteller bietet eine 60-Tage-Testphase ohne Funktionseinschränkungen an. Diese ist über die Registrierung auf der Webseite anzufordern http://www.sysoptools.com/customerform.aspx. Nachdem man seine Aktivierung erhalten hat, kann das Programm heruntergeladen werden. Dabei fällt sofort auf, dass das ganze sehr "schlank" gehalten wurde (Dateigröße 1,08 MB).

Die Software läuft als Dienst auf einem Server oder Workstation in der Domäne. Auch ein DC ist kein Problem. Das Setup erfordert kaum Einstellungen. Nachdem das Setup abgeschlossen ist, ist noch eine Änderung an der Dienstekonfiguration durchzuführen: Der Dienst darf nicht als LocalSystem ausgeführt werden, sondern benötigt einen Benutzeraccount, um die Benachrichtigungs-Emails zu versenden. Dazu wird das Recht "Ausführen als Dienst" benötigt sowie Schreibrechte für diesen Account auf den Registrypfad:
HKEY_LOCAL_MACHINE\SOFTWARE\SysopTools.

Im Programm selbst sind nun die Konfigurationen vorzunehmen: Registrierungsschlüssel, Mailserver (über den die Benachrichtigungen verschickt werden), Absendername und seine Emailadresse und natürlich das maximale Kennwortalter, welches identisch zur Einstellung in der Domänenkennwortrichtlinie sein sollte.

Abbildung 2: Password Reminder Pro Programmfenster

Der Benutzer wird insgesamt drei Mal mittels Email aufgefordert sein Kennwort zu ändern. Hierzu lassen sich entsprechend drei verschiedene Templates einbinden, die man selbst editieren kann. Abbildung 3 zeigt ein Beispiel, welches auf der Herstellerseite heruntergeladen werden kann.

Abbildung 3: Beispielvorlage für eine Benachrichtigungsemail

Auch der Zeitpunkt, wann die Benachrichtigungen versandt werden, kann definiert werden.

Damit die Benutzer nicht fälschlicherweise benachrichtigt werden, kann das Programm in einen Testmodus versetzt werden, in dem noch keine Nachrichten an die Benutzer versandt werden, sondern nur an den Administrator. Über die PRPConsole ist es möglich, einen Report und die einzelnen Benachrichtigungen zu erhalten.

Abbildung 4: Password Reminder Pro Console

Mit der Reportkonsole (siehe Abbildung 2) kann man die lizenzierten Benutzer, demnächst ablaufende Benutzerkonten, deaktivierte Benutzerkonten usw. anzeigen. Auch der Export z.B. nach Excel ist möglich.

Abbildung 5: Reportkonsole mit Exportmöglichkeit

Lizenzierung:
Lizenziert werden Benutzerobjekte, welche ein ablaufendes Kennwort besitzen. Benutzerobjekte, die kein ablaufendes Kennwort besitzen, oder die deaktiviert sind, müssen nicht lizenziert werden. Die kleinste Lizenzierung pro Domain beinhaltet 100 und die größte 2500 lizenzierungspflichtige Objekte. Domänen mit mehr als 2500 lizenzierungspflichtigen Objekten werden als "unlimited users license" behandelt.

Beispielstaffelung der Lizenzkosten:

100 user, single domain w/ annual maintenance  ~ 300$
600 user, single domain w/ annual maintenance  ~ 800$
1500 user, single domain w/ annual maintenance ~ 1500$

Die jährliche Wartungspauschale (Maintenance) ist nicht zwingend erforderlich, wird jedoch dringend empfohlen. Sie beinhaltet bspw. die versionsübergreifenden Programmupdates (1.3 > 2.0). Versionsupdates von bspw. 1.3 nach 1.4 sind auch ohne diese Maintenance möglich.
Um sich vor der Testphase einen Überblick zu verschaffen, wie viele Lizenzen benötigt würden, kann das folgende Tool genutzt werden.
http://www.sysoptools.com/support/files/PRPLicenseRequirements.zip

Abbildung 6: Lizenzcheck-Tool

Genaue Preise und Bedingungen für Ihre Umgebung sollten Sie beim Hersteller erfragen.

Achtung!

Falls Userkonten mittels Script angelegt oder aus NT4 migriert wurden, kann es dazu kommen, dass das UserAccountControl Attribut nicht korrekt gesetzt wurde. Dies führt dazu, dass diese Konten nicht von Password Reminder Pro bei Ablauf des Passwortes beachtet werden und der Nutzer keine Email erhält. Die Lösung hierfür steht im Whitepaper "Fixing user accounts flagged as system accounts – the UserAccountControl AD attribute"

Fazit

Das Programm erweist sich als erstaunlich einfach und praktisch im Alltag, und wird jedem Administrator, der die obige Ausgangssituation kennt, eine Menge an Telefonanrufen ersparen. Mein bisheriger Kontakt mit dem Produktsupport über Email erfolgte schnell und unkompliziert. Nach Aussage der Entwickler werden Kunden ermutigt, Vorschläge und Kritikpunkte einzureichen, um diese in das Produkt mit einfließen zu lassen. Auch die Lizenzkosten bewegen sich in einem Rahmen, der die Eigenentwicklung mittels Skript durchaus kostenintensiver werden lassen kann, sollte man diese oder ähnliche Funktionalitäten im Skript mit abdecken müssen.

Ein paar kleine Kritikpunkte muss ich trotzdem loswerden.

1. Das manuelle Einsetzen des Diensteaccounts sollte meiner Meinung nach direkt im Setup erfolgen. Genau wie die Berechtigungsanpassung in der Registry.
2. Das Setzen des maximalen Kennwortalters sollte nicht manuell erfolgen, sondern vom Programm automatisch aus dem AD ausgelesen werden. Zumindest bis zum Erscheinen von Windows Server 2008 sollte das relativ einfach zu implementieren sein.
3. Das Programm hat Probleme bei der Darstellung der deutschen Umlaute. Laut Support wird an diesem Problem bereits gearbeitet und soll in Version 2.0 behoben werden.

Herstellerwebseite:
http://www.sysoptools.com/
Support über die Webseite:
http://www.sysoptools.com/support.html
Beispieltemplates: http://www.sysoptools.com/support/files/Custom_Email_Templates_12162006.zip

Verwandte Beiträge:

1. Kennwörter selbst zurücksetzen
   Welcher Admin kennt nicht die Anrufe von Benutzern, die ihr...
2. Das lokale Admin-Passwort auf allen PCs ändern
   Windows bringt leider keine einfache Möglichkeit mit, das lokale Administratorpasswort...
3. Abgestufte Kennwortrichtlinien endlich komfortabel
   Update 13. April 2012: Das hier vorgestellte Tool scheint nicht mehr...

Ein schönes Beispiel der Kategorie "Sachen, die die Welt nicht braucht" bringen die Admin-Werkzeuge von Windows Server 2008 mit. Um das Ganze wirklich auszukosten, vergleiche man zunächst die beiden Varianten eines Dialogs aus Windows Server 2003 und Windows Server 2008. Gezeigt wird dasselbe Objekt derselben Domäne. Die Preisfrage: Wer findet den Unterschied?

Erstens: Der Dialog in Windows Server 2008

Zweitens: Der Dialog in Windows Server 2003

Und bevor die Frage kommt, wie man denn jetzt unter Windows Server 2008 eine Kontosperrung erkennt: Siehe nächsten Screenshot. Grins. Im Übrigen aktualisiert sich der Reiter natürlich nicht, wenn man den Haken gesetzt hat und auf Übernehmen klickt .

Verwandte Beiträge:

1. RDP-Neuerungen unter Windows Server 2008
   Für die tägliche Arbeit der Administratoren gehört mittlerweile die RDP-Verbindung...
2. Wie aktualisiert man einen Domänencontroller auf Windows Server 2003 R2?
   Das Release Windows Server 2003 R2 basiert auf zwei CDs....
3. Exchange 2007 SP2 und Windows Server 2008 R2
   Es besteht jetzt die Möglichkeit, Exchange 2007 SP2 auf Windows Server...

Mit dem Servicepack 1 für Exchange 2010 kommt eine neues Feature hinzu, welches sicherlich der einige Administratoren schon lange erwartet haben – die Passwort-Änderungsmöglichkeit bereits abgelaufener Benutzerkonten.

Bestimmt ist dem einen oder anderen Administrator schon das Problem aufgefallen, dass der Haken „Benutzer muss Kennwort bei der nächsten Anmeldung ändern“ keine gute Idee ist, wenn der Nutzer sich per Outlook Web App (OWA) anmelden muss. Die Anmeldung wird in diesem Fall scheitern. Genauso wie die eines Nutzers, der sein Kennwort nicht innerhalb des definierten Passwortalters geändert hat. An dieser Stelle greift die oben erwähnte neue Funktion. Der Nutzer meldet sich am OWA an und Exchange überprüft die Passwortgültigkeit.

Ist das Passwort abgelaufen, wird der Nutzer automatisch auf eine Passwortänderungswebseite geleitet.

Nach erfolgreicher Änderung kann sich der Nutzer an der OWA-Seite anmelden und erhält Zugang zu seinem Postfach.

Diese Funktion ist von Microsoft allerdings nicht per Default aktiviert, sondern muss manuell in der Registry des Client Access Servers (CAS) konfiguriert werden.

HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchange OWA

Dort muss ein zusätzlicher Wert ChangeExpiredPasswordEnabled vom Typ DWord angelegt und auf 1 konfiguriert werden.

Danach muss nur noch der IIS mittels iisreset neugestartet werden, um das Feature aktiv zu schalten.

Hinweis: Exchange 2007 SP3 wird identisch konfiguriert!

Hinweis: Erfolgt die OWA Veröffentlichung mittels ISA Server oder TMG, funktioniert dieses Feature nicht!

Verwandte Beiträge:

1. Das Benutzerkennwort unter OWA ändern
   Der Exchange Server 2003 bietet eine nette, hilfreiche, aber leider...
2. Admin-Kennwort ganz einfach zurücksetzen
   Dieser Beitrag erschien zuerst auf Ralfs Blog. Es gibt sicher...
3. Kennwortänderungsaufforderung per Email mittels Password Reminder Pro
   Das Problem Stellen Sie sich vor, Sie sind der Administrator...

Nicht immer hat man als Administrator die Möglichkeit, die Verwendung von POP3- oder IMAP4-Clients zu verhindern. Damit man aber nicht allen Nutzern persönlich die Servereinstellungen mitteilen muss, gibt es seit Exchange 2010 innerhalb des OWA für Benutzer die Möglichkeit, sich diese Einstellungen anzeigen zu lassen.

Standardmäßig steht dort allerdings keine Information, so dass diese zuerst konfiguriert werden muss.

Dies erfolgt mittels der nachfolgenden PowerShell-Befehle, welche auf jedem CAS Server durchgeführt werden müssen:

Set-POPSettings -ExternalConnectionSettings "mail.mydomain.tld:995:ssl"

Set-IMAPSettings -ExternalConnectionSettings "mail.mydomain.tld:993:ssl"

Die SMTP-Einstellungen lassen sich mittels des folgenden Befehls veröffentlichen. Die dabei verwendeten Daten können direkt in der EMC im Connector eingetragen werden.

ReceiveConnector -Identity "myserver\Client myserver" -AdvertiseClientSettings:$true

Die Änderungen treten nach einem Neustart des IIS mittels iisreset in Kraft.

Verwandte Beiträge:

1. SMTP richtig eingerichtet unter Windows 200x
   Die zuständigen Mailserver für eine Domäne werden über den sog....
2. Wie kann ich die Terminal-Server-Einstellungen im AD verändern?
   Wie so oft, muss auch beim Bearbeiten der Terminal-Server-Attribute in...
3. Eventlog-Monitoring via SMTP – zentral verwaltet und kostenfrei
   Dieser Beitrag erschien zuerst auf Bents Blog. Wer (wie ich)...

In den Installationsvoraussetzungen für Exchange Server 2010 [http://technet.microsoft.com/de-de/library/bb691354(EXCHG.140).aspx] befindet sich unter anderem der Punkt:

Inzwischen gibt es natürlich auch bereits das “Office 2010 Filter Pack”, welches statt der Version 2007 genutzt werden kann.

http://www.microsoft.com/downloads/details.aspx?FamilyID=5cd4dcd7-d3e6-4970-875e-aba93459fbee&displayLang=de

Mit Hilfe dieser Filter können entsprechende Dateitypen/Dokumente Volltext-indiziert werden, um auch Suchergebnisse innerhalb dieser Dokumente an den Benutzer zurückzuliefern. Seit Exchange 2007 wird automatisch ein entsprechender Index erstellt und Nutzern von Outlook Web App und Outlook im Online-Modus bereitgestellt. Nutzer von Outlook im Cachemodus greifen auf einen lokalen Index zurück.

Die Microsoft Webseite listet die folgenden Dokumente:

• Filter für ältere Office-Versionen (97-2003; .doc, .ppt, .xls)
• Filter für Metro-Office (2007; .docx, .pptx, .xlsx)
• Zip-Filter
• OneNote-Filter
• Visio-Filter
• Publisher-Filter
• Filter für Open Document-Format

Wie man sehen kann, fehlt ein wichtiges Dateiformat – nämlich PDF.

Abhilfe schafft der “Adobe PDF iFilter”, welchen man unter folgendem Link herunterladen kann.

http://www.adobe.com/support/downloads/detail.jsp?ftpID=4025

Im Gegensatz zu den Microsoft-iFiltern muss der PDF-Filter allerdings manuell für Exchange registriert werden. Dies erfolgt in mehreren Schritten und muss auf jedem Hub Transport- und Mailbox-Server durchgeführt werden.

1. Installieren des obigen “Adobe PDF iFilter 9 for 64-bit platforms” auf den entsprechenden Exchangeservern
2. Standardmäßig wird der iFilter in das Verzeichnis C:\Program Files\Adobe\Adobe PDF iFilter 9 for 64-bit platforms\bin installiert. Dieser Pfad muss in die Pfadvariable zusätzlich eingetragen werden.
   
3. Nun müssen mehrere Registry-Einstellungen vorgenommen werden. Damit es einfacher ist, kann man die unten stehende Vorlage kopieren und als .reg Datei abgespeichern. Danach diese Datei einfach auf den Exchange-Servern doppelt anklicken.
4. Damit diese Änderung wirksam wird, muss der Server jetzt neugestartet werden.
5. Nach dem Neustart muss noch der Volltext-Index neu erstellt werden. Microsoft liefert hierzu das notwendige Script mit. Zu finden ist dies unter C:\Program Files\Microsoft\Exchange Server\V14\Scripts
   Der Aufruf erfolgt in der Exchange Powershell mittels
   ResetSearchIndex.ps1 -force –all

Unter http://technet.microsoft.com/en-us/library/aa995966(EXCHG.80).aspx wird auch die manuelle Vorgehensweise zum Zurücksetzen des Index‘ beschrieben.

Die Neuerstellung kann erfahrungsgemäß mehrere Stunden dauern!

Hinweis: Exchange 2007 wird identisch konfiguriert.

Reg-Dateien zur Einbindung des PDF-iFilters

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\CLSID\{E8978DA6-047F-4E3D-9C78-CDBE46041603}]
@="PDFFilter.dll"
"ThreadingModel"="Both"
"Flags"=dword:00000001

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\Filters\.pdf]
@="{E8978DA6-047F-4E3D-9C78-CDBE46041603}"

Verwandte Beiträge:

1. Exchange Server 2010: Voraussetzungen installieren
   Exchange Server 2010 lässt sich unter Windows Server 2008 (x64,...
2. Exchange 2007 auf Windows Server 2008 R2 installieren
   Mit dem Service Pack 3 für Exchange Server 2007 ist...
3. Exchange 2010 RC ist da!
   Hm, ich scheine noch zu den ersten zu gehören …...

Über diese Frage kann man vortrefflich streiten. Die eine Seite argumentiert mit der anfallenden Datenmenge und dem Datenschutz, die andere Seite mit dem „personifizierten“ Emailkontakt und sowieso gestiegener Hardwareleistung. Fakt ist, dass seit Windows 2000 die entsprechenden Attribute im AD-Schema vorhanden sind. Fakt ist aber auch, dass erst jetzt mit Outlook 2010 ein Produkt im „Massenmarkt“ ist, welches wirklichen Nutzen daraus ziehen kann.

Deswegen werden in diesem Artikel ein paar Punkte für und wider, sowie die Anwendungs- und Administrationsmöglichkeiten dargestellt.

Pro:

Applikationen wie Outlook 2010 können die gespeicherten Daten anzeigen und ermöglichen dem Nutzer eine auch bildliche Identifizierung des Emailempfängers.

Die anfallende Datenmenge ist „vernachlässigbar“, da das von Outlook genutzte Active-Directory-Attribut (thumbnailPhoto http://msdn.microsoft.com/en-us/library/ms680034%28v=VS.85%29.aspx) auf 102400Byte (100 KB) limitiert ist.

Contra:

Die anfallende Datenmenge mit maximal 100 Kilobyte pro User ist bei 20.000 Usern dann doch etwas größer. Entspräche ca. 2GB an Bilddaten, die repliziert würden.

Der Datenschutz bzw. das Recht am eigenen Bild ist zu berücksichtigen.

Der wirkliche Nutzen ist derzeit wohl kaum zu bewerten. Der administrative Aufwand hingegen lässt sich durchaus berechnen.

Diese paar Punkte sollen bei der Überlegung, ob Fotos ins AD gehören oder nicht, dem Umsetzenden ein paar Argumente an die Hand geben. Sie erheben natürlich keinen Anspruch auf Vollständigkeit oder aber Fehlerfreiheit.

Praxis:

Microsoft Outlook 2010 ist in der Lage, die Bilder der Nutzer aus der Globalen Adressliste anzuzeigen. Beispielsweise direkt nach einem Doppelklick auf einen Kontakt innerhalb der GAL, aber auch an diversen anderen Stellen des Programms.

Leider liefert erst Exchange 2010 ein cmd-let (http://technet.microsoft.com/en-us/library/dd351252.aspx) mit dessen Hilfe ein Import der Bilder ins Active Directory überhaupt erst möglich wird.

Benötigt man deswegen also Exchange 2010? Die Antwort ist ein klares Jain. Exchange 2010 liefert das cmd-let zum Import. Für die Anzeige des Bildes benötigt Outlook 2010 aber keinen Exchange 2010, sondern das ginge auch mit Exchange 2003 oder 2007, denn das Bild wird im Active Directory gespeichert und nicht im Exchange-Server. Allerdings bietet Exchange 2010 natürlich trotzdem Funktionen, die vorherige Versionen in dieser Form nicht besitzen. So werden diese Bilder bei Exchange 2010 auch in das Offline Adressbuch verlinkt bzw. kopiert und stehen dann auch Usern zur Verfügung, die Outlook Anywhere mit aktiviertem Cache Mode nutzen.

Auf dem Exchange Team Blog sind noch einige weiterführende Infos hinsichtlich der Offline Adressbuch-Funktionen beschrieben:

http://msexchangeteam.com/archive/2010/03/10/454223.aspx

Da also Exchange 2010 nicht direkt benötigt wird, gibt es inzwischen auch diverse Tools (Freeware, Skripte oder auch kommerziell) anderer Hersteller, die sich genau dieses Themas annehmen. Diese werden nachfolgend kurz vorgestellt.

http://www.mikepfeiffer.net/2010/05/manage-exchange-2010-thumbnail-photos-with-a-powershell-based-gui/

Hier bietet der Autor Mike Pfeiffer ein Powershell-Skript mit GUI an, welches den Import und die Anzeige der Bilder ermöglicht. Benötigt wird hierfür aber mindestens ein Exchange 2010, der das entsprechende cmd-let liefert.

http://www.dewdney.co.uk/adext/adext.zip

wird von Oli Dewdney angeboten und ermöglicht die Anzeige und Pflege der Bilder innerhalb der “Active Directory-Benutzer und -Computer”-Konsole.

Wer etwas mehr Features wie bspw. Bearbeitungsmöglichkeiten oder Massenimport benötigt, wird bei http://www.thumbnailphoto.net/de oder http://www.dovestones.com/products/Active_Directory_jpegPhoto_thumbnailPhoto.asp fündig.

Und schließlich gibt es auch ein Tool professioneller Qualität kostenlos:

[Outlook Photos - Update your Outlook photo for free]
http://www.exclaimer.com/products/outlook-photos/Default.aspx

Hinweise:

• Auf 32-Bit-Domänencontrollern ist das Anwachsen der Active-Directory-Datenbank zu überwachen, da sich hier die Datenbankgröße stärker auf die Performance auswirkt als bei x64-Systemen.
• · Das AD-Attribut thumbnailPhoto ist nur für Administratoren beschreibbar. Nutzer können also (zum Glück) nicht einfach beliebige Fotos abspeichern. Über entsprechende AD Delegation kann das Attribut für weitere Nutzer als beschreibbar definiert werden.

Wer, trotz in der GAL vorhandener Fotos, von den "Gesichtern" seiner Kollegen verschont bleiben will, kann folgende Anleitung befolgen, die die Kontaktfotos in Outlook komplett deaktiviert. Dies gilt dann allerdings auch für die Fotos innerhalb der eigenen Kontakte.

Unter folgendem Link ist die entsprechende ADM-Vorlage des Outlook Social Connectors herunterzuladen.

OutlookSocialConnector.zip

Nun nur noch die entsprechende Policy definieren und schon hat man seine Ruhe.

Im Übrigen ermöglicht es der Outlook Social Connector, die Daten auch in Outlook 2007 anzuzeigen. Allerdings nicht in der GAL, sondern dann in jeder Email im unteren Bereich.

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=b638cc14-11e5-448a-b5a6-4f553ce81b94

Fazit:

Wer sich für die Speicherung von Nutzer-Bildern im Active Directory entscheidet, sollte entsprechende Werkzeuge nutzen, die eine Administration sinnvoll ermöglichen. Microsoft liefert hier wie so oft derzeit nur rudimentäre Funktionen, die mit den oben gezeigten Tools aber deutlich geschlagen werden. Die Anzeige in Outlook erfolgt problemlos, und in der Praxis ist es ein Feature, welches man nach einer Eingewöhnungsphase wahrscheinlich nicht mehr abgeben will.

Verwandte Beiträge:

1. Fallen und Auswege beim Recovery von Active Directory
   Der Microsoft-Supportmitarbeiter Herbert Mauerer hat einen sehr lesenswerten Artikel zum...
2. Kann ich NT4 im Active Directory betreiben?
   Workstations oder Server unter Windows NT 4.0 können grundsätzlich problemlos...
3. Outlook 2010: Adressvorschläge beim Update manuell übertragen
   Kai Schneider hat in einem interessanten Artikel beschrieben, wie man...

Welcher Admin kennt nicht die Anrufe von Benutzern, die ihr Kennwort vergessen haben? Kommt das seltener als 1-2 mal pro Tag vor, ist alles noch einfach zu handhaben. Wie verhält sich so etwas aber bei tausenden von Benutzern, die möglicherweise nur peripher mitbekommen, dass das Kennwort überhaupt abläuft? Oder bei Nutzern, die sich nicht täglich an einem Windows PC anmelden, der über den Ablauf von Kennworten informiert? Oder bei Nutzern, die einmalig bei Ersteingabe das Kennwort im Mailprogramm oder Browser abspeichern und deswegen bis zum Ablauf des Kennwortes keine Notwendigkeit haben, sich an das Kennwort zu erinnern?

Dann hat man entweder regelrechte Sprechstunden für vergessliche Nutzer (an die sich diese natürlich nicht halten), eine Passwort-Hotline oder man beschafft eine entsprechende Password Self Service Software.

Password Self Service kennt man üblicherweise entweder von diversen Webmailanbietern wie Hotmail oder auch von Webforen. Bei letzteren bekommt man im Allgemeinen sein neues Kennwort an die Emailadresse gesandt, mit der man sich registriert hat. Das ist bei einer Lösung mit Exchangepostfächern natürlich wenig hilfreich, da man das Passwort für das Active Directory Konto auch für den Zugriff auf das Postfach benötigt. Genau darauf hat man aber keinen Zugriff, da man sein Kennwort vergessen hat. Eine andere Lösung sind sogenannte Frage und Antwort Modi, bei denen sich der Benutzer aus diversen Fragen eine oder mehrere aussucht und dazu entsprechende Antworten vergibt, die nur er kennt. Bspw: “Wie ist der Name Ihres ersten Haustieres?” oder “Wie lautet der Mädchenname Ihrer Mutter?”

Nach der Eingabe der korrekten Antworten kann man sich ein neues Kennwort vergeben und damit wieder anmelden.

Eine Lösung für Password Self Service bietet Sysop Tools mit Password Reset Pro für Active Directory.

Wie genau funktioniert das also?

Damit ein nicht authentifizierter Nutzer (er hat ja schliesslich sein Kennwort vergessen), ein neues Kennwort vergeben kann, benötigt er eine Möglichkeit sich gegenüber dem System zu legitimieren. Dies kann in Password Reset Pro über zwei Modi erfolgen.

1. Profile Enrollment Mode
2. Active Directory Data Mode

Zusätzlich gibt es einen dritten Modus „Domain Authentication only“, mit dem Benutzer ihr Kennwort ändern können. Ein Zurücksetzen eines vergessenen Passwortes ist hiermit allerdings nicht möglich, weswegen dieser Modus im Artikel nicht weiter berücksichtigt wird.

Profile Enrollment Mode

Im Profile Enrollment Mode muß sich der Anwender einmalig eine Kombination aus vorgebenem Bild und frei definierbaren Sicherheits-Wort wählen. Über beide Informationen wird dann ein Hash gebildet und verschlüsselt im Active Directory gespeichert. Mit Hilfe dieser Kombination ist es ihm möglich, das vergessene Passwort zurückzusetzen. Natürlich kann der Administrator auch Worte und User ausschließen. Bspw. sind Worte die das gewählte Bild bezeichnen dann doch zu einfach. Administrative Accounts können ebenfalls ausgeklammert werden.

Abbildung 1: Einstellungen des Sicherheits-Wortes

Sobald der Nutzer die Webseite von Password Reset aufruft, kann er sich „einschreiben“. Hierzu muß er sich mit seinem Nutzernamen und seinem (nicht vergessenem Kennwort) identifizieren. Er wählt aus den angezeigten Bildern eines aus, und gelangt so zum zweiten Schritt.

Abbildung 2: Gewähltes Bild anklicken

Hier wählt er ein Wort, welches nur den Bedingungen aus Abbildung 1 entsprechen muss. Danach ist der Einschreibevorgang abgeschlossen.

Kommentare, dass sich die Nutzer die Kombination von Bild und frei wählbarem Wort ebenfalls nicht merken können sind verständlich. Aber anscheinend fällt es vielen Nutzern doch einfacher, als sich ein ein komplexes Kennwort allein zu merken.

Abbildung 3: Sicherheits-Wort eingeben

Abbildung 4: AD Passwort zurücksetzen

Info: Alle Daten werden innerhalb des Active Directory gespeichert. Es sind keine zusätzlichen Datenbanken wie SQL o.ä. notwendig. Beim „Enrollment“ generiert der Masterservice mit den beiden Komponenten (Bild und Sicherheits-Wort) einen AES-256 verschlüsselten „logischen Zeiger“. Dieser Zeiger wird im Attribut „altSecurityIdentities“ des Benutzerobjekts im Active Directory gespeichert. Dieses Attribut existiert in jedem Active Directory und ist für solche Zwecke vorgesehen:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms675221(v=vs.85).aspx

Abbildung 5: Eingeschriebener AD-Benutzeraccount

Wie erwähnt, ist hierzu ein einmaliges Einschreiben aller Nutzer notwendig, damit obige Methode funktioniert. Password Reset Pro stellt dem Administrator hierzu eine Konsole zur Verfügung, in welcher erkennbar ist, wie viele seiner Nutzer bereits eingeschrieben sind. Säumige Nutzer können per Emailvorlage über die Notwendigkeit zum Einschreiben informiert werden.

Über den Stand des Enrollments wird der Administrator mit täglichen Reports oder durch einen Blick in die Report-Konsole unterrichtet.

Active Directory Data Mode

Im Active Directory Data Mode ist das Einschreiben (Pre-Enrollment) nicht notwendig. Der Administrator legt entsprechende Attribute im Administrationstool fest, auf deren Basis die Frage(n) gestellt werden soll(en). Beispielsweise kann in einem AD-Attribut die Information über Telefonnummer oder Büro gespeichert werden. Dem Nutzer werden im Webportal die Fragen „Wie lautet Ihre dienstliche Telefonnummer? und „In welchem Bürogebäude sitzen Sie?“ präsentiert und er muss alle korrekt beantworten. Die Antworten werden dann mit den Werten im entsprechenden AD-Attribut verglichen und als korrekt oder fehlerhaft gewertet. Es sind alle verfügbaren AD-Attribute möglich. Das Active Directory hält jedoch viele Attribute für Domänenbenutzer lesbar bereit. Deswegen sollte man sich im Klaren darüber sein, sein, dass zwar keine Vorbereitung durch den Nutzer erforderlich ist, aber dass es durchaus Nutzer mit genügend „Elan“ gibt, die Kennworte anderer Nutzer auf Basis „freiverfügbarer“ Informationen zurücksetzen.

Technische Informationen zu Password Reset Pro

Password Reset Pro besteht aus den zwei Komponenten Webportal und Masterservice. Beide können entweder auf einem Server installiert werden ("single tier"), oder getrennt als sogenannte "two tier" Installation. Das Webportal bietet die Schnittstelle, welche der vergessliche Benutzer zu Gesicht bekommt. Der Masterservice ist die Komponente, welche die eigentliche Änderung im Active Directory vornimmt. Dieser Dienst benötigt entsprechend delegierte Rechte im AD, um die Kennworte der Nutzer zurücksetzen zu können. Die Verwendung von Domänenadminrechten ist nicht empfohlen.

Getestet wurde die Version 3.1.67, welche sowohl als 32- als auch 64-bit Applikation installiert werden kann. Allerdings sind Installationen derzeit nur auf englischsprachigem Betriebssystem möglich. Der Hersteller SysOp Tools hat aber Internationalisierung angekündigt (s. geplante Features).

Die Installation ist einfach zu erledigen, und wird vom Hersteller mit einer ausführlichen englischsprachigen Anleitung unterstützt.

http://www.sysoptools.com/support.aspx?tbc=0

Geplante Features

Natürlich gibt es auch Funktionen, die sich derzeit noch nicht im Produkt befinden, aber vom Hersteller bereits angekündigt wurden. Hierzu gehören u.a.

• Mobile Device Zugriff – Passwortänderungen und –entsperrungen vom iPhone, Windows Mobile, iPad, BlackBerry aus.
• Windows Vista, Windows 7 and Server 2008 Self Service Integration im Anmeldefenster
• Sharepoint-Plugin zum Anzeigen der Restlaufzeit des Passwortes
• Mehrsprachige Weboberfläche des Portals

Fazit

Das Programm erweist sich als erstaunlich einfach und praktisch im Alltag, und wird jedem Administrator, der die oben beschriebene Ausgangssituation kennt, eine Menge an Telefonanrufen ersparen. Mein bisheriger Kontakt mit dem Produktsupport über Email erfolgte schnell und unkompliziert (notwendig geworden wegen der Installation auf einem deutschsprachigen System). Wie der Punkt „geplante Features“ zeigt, ist trotzdem noch jede Menge Potenzial, welches in zukünftigen Veröffentlichungen realisiert werden sollen.

Die Lizenzkosten bewegen sich in einem Rahmen vergleichbarer Lösungen anderer Hersteller. Über die Webseite des Herstellers kann ein Angebot angefordert werden.

Verwandte Beiträge:

1. Kennwortänderungsaufforderung per Email mittels Password Reminder Pro
   Das Problem Stellen Sie sich vor, Sie sind der Administrator...
2. Abgestufte Kennwortrichtlinien endlich komfortabel
   Update 13. April 2012: Das hier vorgestellte Tool scheint nicht mehr...
3. Liza: Berechtigungen in Active Directory analysieren
   Philipp Föckeler hat ein Programm namens “Liza” veröffentlicht, mit dem...

Im folgenden How-To werde ich die exemplarische Veröffentlichung von Dell Hardwareupdates (Bios) mit Hilfe des WSUS Package Publisher (WPP) und dem Dell System Center Update Katalog darstellen. Ab der Version v1.3.1309.01 unterstützt der WPP den Import von Updates aus Herstellerkatalogen. Diese werden von einigen Hard- und Softwareherstellern bereitgestellt, damit Updatevorgänge schneller und übersichtlicher durchgeführt werden können. Ursprünglich sind diese für die Verwendung von System Center Update Publisher in Verbindung mit System Center Configuration Manager vorgesehen, können aber auch mit einem WSUS und dem WPP verwendet werden. In diesen Katalogen stellen Hersteller wie Adobe bspw. die letzten Updates für den Adobe Reader XI oder den Flash Player bereit. Außerdem gibt es von den Hardwareherstellern Dell, HP und Fujitsu solche Kataloge um Treiber, Managementtools und Hardware auf aktuellem Stand zu halten.

Nach dem Start des WPP muss als erstes der entsprechende Katalog abonniert werden, um daraus Updates zu veröffentlichen. Das Abonnement erreicht man über den Menüpunkt „Updates/Katalog abonnieren…“

Mittels Klick auf „Freigegebenen Katalog laden“ können die bereits mitgelieferten Kataloge abonniert werden. Alternativ kann man sie aber auch in das Adressfeld eintragen. Nach einem Klick auf „Verbindung testen“ und „Auf Aktualisierung prüfen“ ist man mit dem aktuellsten Katalog in der Lage Updates zu importieren.

Abbildung 1: Katalog abonnieren

Hierzu klickt man auf „Importiere Updates aus diesem Katalog…“, nachdem der entsprechende Katalog in der Liste ausgewählt wurde.

Es öffnet sich das Import Fenster, in dem man den Katalog öffnet. Mittels entsprechender Filterkriterien kann das entsprechende Update schneller gefunden werden.

Abbildung 2: Import Dell OpenManage Inventory Agent (for Dell Business Client Systems)

Damit der Windows Update Agent erkennen kann, ob für ihn zutreffende Dell Updates auf dem WSUS bereitgestellt sind, muss als erstes der „Dell Open Manage Inventory Agent (for Business Client Systems) veröffentlicht werden. Informationen zu diesem Paket liefert die Dell Webseite: http://en.community.dell.com/techcenter/os-applications/w/wiki/2542.dell-custom-updates-faq.aspx

Q: What is the Dell OpenManage Inventory Agent?

A: The Dell OpenManage Inventory Agent is a service that must be installed on every system to detect Dell Hardware Updates. There is a separate update for servers and workstations. The service runs at system startup to detect the current state of Dell Hardware (firmware versions, driver versions, etc), and then stops within a few minutes. The service will remain stopped until the next system restart.

Für alle WSUS Systeme, welche keine englischsprachigen Updates beinhalten, muss der Haken bei „Updates sprachunabhängig importieren“ aktiviert werden. Danach kann das Update in den WSUS importiert werden.

Abbildung 3: Download des Update Pakets von der Dell Webseite

Das Update wird dann von der Dell Website heruntergeladen. Der Computer von dem aus WPP gestartet wurde benötigt also einen Internetzugang (ftp und http).

Nachdem das Update erfolgreich importiert ist, kann es genehmigt werden und wird im nächsten Updatezyklus von den Clients erkannt und zum definierten Installationszeitpunkt installiert.

Abbildung 4: Bereitgestelltes Update für den Dell OpenManage Inventory Agent in der WSUS Konsole

Der Dell OpenManage Inventory Agent (for Dell Business Client Systems) benötigt hierbei keinen Reboot nach der Installation. Es kann jedoch bis zum nächsten Reboot dauern, bis Ergebnisse zurückgeliefert werden.

Nachdem somit die Voraussetzungen für die korrekte Erkennung von Dell Systemen geschaffen sind, können die notwendigen Updates aus dem Katalog importiert werden. Dies wird nachfolgend anhand eines Bios-Updates exemplarisch gezeigt.

Der Katalog wird erneut geöffnet, und mittels Filter auf das entsprechende Dell PC Modell, ein passendes Bios-Update importiert.

Abbildung 5: Import Dell Optiplex 7010 Bios

Anders als andere Update Pakete benötigen die Dell Bios Updates zwingend einen Reboot und keinen Shutdown und späteren Neustart. Wird nach der Installation kein Reboot durchgeführt, wird das Bios Update solange auf dem Client als benötigtes Update angeboten, bis ein Reboot des Systems und das Bios Update erfolgreich durchgeführt wurde.

Dell gibt zu diesem Thema folgendes Statement:

· The BIOS will not upgrade without the reboot; the installer simply loads the image file into memory and waits for the reboot.

· If a system goes into a low-power state, such as sleep or hibernate, then the memory space where the upgrade image is stored will be erased, and the end user will get an error when it eventually reboots. There is no harm done, but the error message may cause calls into your help desk and the BIOS upgrades will not have taken place.

http://en.community.dell.com/techcenter/os-applications/w/wiki/dell-bios-upgrades-for-enterprise-clients-with-microsoft-system-center-configuration-manager-2007.aspx

Es bestehen mindestens zwei Möglichkeiten, diesen Reboot zu veranlassen.

1. Das Bios Update wird mit dem auf obiger Webseite angegebenen Parameter /NOPAUSE bzw. /R (je nach Bios Paket) verteilt, was allerdings den Nachteil hat, dass der Reboot sofort und ohne Eingriffsmöglichkeit des angemeldeten Nutzers erfolgt. Die möglichen Parameter lassen sich bei einigen Updatepaketen mittels /? herausfinden.

Abbildung 6: Beispiel von Dell Bios Update Parametern

2. Die WSUS Policies müssen umkonfiguriert werden, um den Benutzer über die Reboot-Notwendigkeit zu informieren und den Neustart auch bei angemeldeten Nutzern durchzuführen.

In den meisten Fällen dürfte Variante 1 ausfallen, es wird im Folgenden die notwendige GPO Konfiguration erläutert.

Computerrichtlinien

Abbildung 7: Automatischen Neustart auch mit angemeldetem Nutzer durchführen

Abbildung 8: Reboot-Timer auf 30 Minuten setzen

Bei der Neustartverzögerung muss man den für die jeweilige Umgebung sinnvollen Wert finden.

Benutzerrichtlinien

Für den Nutzer darf die Rebootbenachrichtigung natürlich nicht unterdrückt werden, da er sonst trotz entsprechender Maschinenkonfiguration keinen Reboot-Timer sehen kann.

Abbildung 9: Rebootnotwendigkeit anzeigen lassen

Wurden diese Richtlinien entsprechend konfiguriert und ein Update erfordert einen Neustart, wird dem Nutzer ein Reboot-Timer angezeigt.

Abbildung 10: Reboot-Timer unter Windows 7

Normalerweise hat der Nutzer nur noch die Möglichkeit den Neustart zu verzögern, indem er auf „Später erinnern:“ und den entsprechenden Wert klickt. Damit auch diese Möglichkeit nicht mehr gegeben ist und nach einem Bios Update innerhalb von 30 Minuten gebootet wird, muss für das Bios Update ein Stichtag zur Installation konfiguriert werden.

Abbildung 11: Stichtagkonfiguration in der WSUS Konsole

Damit schnellstmöglich installiert wird, wählt man einen benutzerdefinierten Zeitpunkt, welcher in der Vergangenheit liegt. Somit wird automatisch bei der ersten Installation der Reboot ohne Verzögerungsmöglichkeit durch den Nutzer durchgeführt.

Abbildung 12: Reboot Time bei Updates mit Stichtaginstallation

Damit ist dann die Konfiguration für die Verteilung von Dell Bios Updates abgeschlossen.

Drei wichtige Hinweise zum Abschluss:

1. Ich übernehme keine Haftung für fehlerhafte Systeme, Datenverlust oder defekte Hardware.
2. Alle Updates sollte man vorab an einzelnen Testsystemen testen. Dies sowohl manuell, um eventuell notwendige Parameter zu erfahren, als auch über die WSUS Verteilung, um deren Erfolg und Rebootrichtlinie zu testen.
3. Bei der Verwendung von Bitlocker muss die Verschlüsselung vorab gestoppt werden, da ansonsten die Eingabe des Bitlocker Recovery Keys beim Reboot mit einem neuen Bios notwendig ist. Wenn dieser nicht im AD gespeichert wurde, fängt man in solchen Fällen panisch zu suchen an. Datenverlust ist hierbei möglich. Weitere Infos dazu hier:

http://technet.microsoft.com/de-de/library/ee449438(v=ws.10).aspx

We recommend that you suspend BitLocker before changing locales or installing a language pack, just as you would before making any major computer configuration change, such as updating the BIOS.

In Windows 10 findet ein bisher kaum im Einsatz befindliches Feature den Weg in den breiten Markt. Die Rede ist von WiFi-Sense; auf deutsch: WLAN-Optimierung. Einfach erklärt, handelt es sich bei dieser Funktion um die Möglichkeit, seine WLAN Zugangsdaten mit seinen Outlook.com-, Skype- oder Facebook- Kontakten zu teilen. Hierzu muss die Funktion WLAN-Optimierung entsprechend konfiguriert sein (nach derzeitigen Kenntnissen ist sie standardmäßig aktiv).

Warum das vielleicht keine gute Idee ist, beleuchte ich im Folgenden.

Die folgenden Abbildungen zeigen die WiFi-Sense-Einstellungen in Windows 10.

Abbildung 1: „schlecht"

Abbildung 2: „gut"

Wer seine Daten also nicht mit allen „seinen" Facebook-, Skype- usw. „Freunden" teilen will, sollte diese Funktion in seinem Windows deaktivieren. Dazu ein Zitat aus Microsofts FAQ:

Kann ich WLAN-Netzwerke gezielt für einzelne Kontakte freigeben?

Nein, die Freigabe ist nur für Gruppen von Kontakten möglich. Wenn Sie beispielsweise kennwortgeschützte WLAN-Netzwerke für Ihre Skype-Kontakte freigeben, können all diese Kontakte über die Netzwerke auf das Internet zugreifen. Es ist nicht möglich, einzelne Kontakte für die Freigabe auszuwählen.

Die Freigabe gilt nur für Ihre Kontakte, nicht aber für deren Kontakte. Die Kontakte Ihrer Kontakte können nicht auf die von Ihnen freigegebenen Netzwerke zugreifen. Um eines Ihrer Netzwerke für ihre Kontakte freizugeben, müssten Ihre Kontakte Ihr Kennwort tatsächlich kennen und es beim Anmelden eingeben.

Natürlich werden nicht einfach alle WLANs automatisch freigegen, sondern man muss diese auswählen und mit dem WLAN Kennwort “freigeben”. WLANs, die 802.1x verwenden, können nicht freigegeben werden. Ein Grund mehr, endlich einzusehen, dass WLANs mit WPA und WPA2 mit Pre-shared Keys nicht für Unternehmen geeignet sind.

Als Betreiber eines WLANs kann man ebenfalls etwas dagegen tun. Hierzu ist die WLAN-SSID zu ändern, indem man “einfach” _optout an den bestehenden SSID anhängt.

(Das Bild stammt von Microsoft.)

Von Microsoft gibt es weiterführende Infos, die allerdings primär auf Benutzer und nicht auf technische Umsetzung abzielen.

http://windows.microsoft.com/de-de/windows-10/wi-fi-sense-faq

https://www.windowsphone.com/de-de/how-to/wp8/connectivity/wi-fi-sense-faq

https://www.windowsphone.com/de-de/how-to/wp8/connectivity/how-do-i-opt-my-network-out-of-wi-fi-sense

http://stadt-bremerhaven.de/windows10-wi-fi-sense/

Und wer schon mal beim Umbenennen seiner privaten SSID ist, kann das hier ja noch gleich mitberücksichtigen.
http://www.heise.de/netze/meldung/Google-Einfaches-WLAN-Opt-Out-aus-Geo-Datenbank-1379160.html

Eine Kombination aus _optout_nomap sollte also ebenfalls machbar sein. Wichtig dabei: Während „_optout" auch in der Mitte der SSID stehen kann, muss Googles „_nomap" am Ende sein.

Kommentar: Wer also nicht möchte, dass seine WLAN Zugangsdaten über bisher technisch nicht nachvollziehbare Art und Weise auf andere Geräte gelangen und dass dafür auch noch Facebook-Accounts genutzt werden, damit Microsoft auch gleich diese Verknüpfung noch kennt, der deaktiviert diese Funktion am besten auf seinen Geräten (Windows 10 und neuer, sowie Windows Phone 8.1). Und nein, eine Gruppenrichtlinie gibt es (derzeit) nicht dafür …

Wer kennt das nicht? Einfach per Gruppenrichtlinien das Kennwort des lokalen Administrators ändern oder Tasks mit Nutzer anlegen usw. usf. Seit Windows Server 2008 konnte man mit der Software von Policymaker aus der DesktopStandard-Übernahme viele Aufgaben mittels GPO konfigurieren. Der Nachteil daran war, dass die verwendeten Kennworte zwar verschlüsselt im SYSVOL-Verzeichnis abgelegt waren, allerdings muss jeder Client diese natürlich wieder entschlüsseln können. Also kann immer nur symmetrisch verschlüsselt werden. Der Schlüssel ist bei Microsoft entsprechend dokumentiert http://msdn.microsoft.com/en-us/library/cc422924.aspx. Damit ist grundsätzlich jeder mit Zugriff auf das SYSVOL-Verzeichnis in der Lage die Kennworte auch auszulesen: http://www.gruppenrichtlinien.de/artikel/get-gpppasswordps1-kennworte-im-xml-in-plaintext-umwandeln/ und http://www.faq-o-matic.net/2014/07/02/ms14-025-das-ende-der-gespeicherten-gpo-passwoerter/

Aus diesem Grund hat Microsoft schon im Mai 2014 mit einem Patch die Funktion zur Eingabe von Passworten entfernt: https://support.microsoft.com/de-de/kb/2962486. Das hatte allerdings zur Folge, dass bereits vergebene Kennworte auch nicht mehr entfernt werden konnten und seitdem im SYSVOL-Nirvana schwebten und damit immer noch entschlüsselt werden können. Das von Microsoft im obigen Link empfohlene Vorgehen zum Entfernen ist relativ unhandlich durchzuführen und führt dazu, dass offenbar viele das Problem ignorieren oder nicht bis zum Ende durchführen (https://www.us-cert.gov/ncas/current-activity/2015/08/07/Required-Group-Policy-Preference-Actions-Microsoft-Security).

Deswegen wurde von Darren Mar-Elias‘ Firma „SDM Software“ ein kleines Freeware-Tool veröffentlicht, welches alle notwendigen Schritte mittels weniger Klicks durchführt. Das Tool hört auf den etwas sperrigen Namen „SDM Software GP Preference Password Remediation Tool 1.0“.

Nach der Installation wird das Tool gestartet und mittels Klick auf Suche (ggf. nach der Eingabe der zu durchsuchenden Domäne) erfährt man, ob man Aufräumbedarf hat oder nicht.

Die einzelnen GPOs können dann mittels Rechtsklick und „Remediate CPassword Entries“ bereinigt werden. Das Tool legt vorher ein Backup jedes zu bearbeitenden GPOs an.

Sollte man keine betroffenen GPOs im Einsatz haben, erhält man eine entsprechende Rückmeldung.

Es gibt also keinen Grund mehr, diese Sicherheitslücke weiterhin offen zu lassen.

Mehr über die Arbeitsweise, weiterführende Informationen und Downloadmöglichkeit finden sich im folgenden Blogeintrag beschrieben: https://sdmsoftware.com/group-policy-blog/security-related/remediating-group-policy-preference-passwords/

Microsoft selbst hat inzwischen eine Möglichkeit für das Handling lokaler Administratorkennworte veröffentlicht. Mit Hilfe der Local Administrator Password Solution erhält man eine umfassende Lösung. Siehe hierzu folgenden Artikel:

http://www.faq-o-matic.net/2015/07/01/laps-lokales-admin-passwort-endlich-sicher/

Nach den diesjährigen Angriffen auf Netzwerke durch Verschlüsselungstrojaner wie WannaCry oder NotPetya sollte man die Gelegenheit nutzen und das durch die Sicherheitslücke EternalBlue betroffene Protokoll SMBv1 netzwerkweit deaktivieren bzw. deinstallieren. Seit Windows Vista (erschienen Januar 2007) nutzt jede Windows Version mindestens auch das Protokoll SMBv2 oder neuer. Nur Windows XP oder Windows Server 2003 können nur mit der alten SMBv1-Variante kommunizieren. Wer also kein Windows XP oder ähnliche alte Windows-OS mehr im Einsatz hat, benötigt mit hoher Wahrscheinlichkeit das alte Protokoll nicht mehr und wird es im Normalfall nicht mal benutzen. Da es aber standardmäßig immer noch aktiv ist, können Schwachstellen im Protokoll auch bei neuen Betriebssystemen ausgenutzt werden.

Nachfolgend wird die Herangehensweise beschrieben, wie man das Protokoll in einem Domänen-Netzwerk mittels Gruppenrichtlinie deaktiviert. Ab Windows 8.1 und neuer kann das komplette Protokoll auch deinstalliert werden, was natürlich die bessere Option darstellt.

Bevor man den folgenden Artikel komplett abarbeitet, hilft Blick auf diese Liste, welche Produkte SMBv1 verwenden:

SMB1 Product Clearinghouse
https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse

Deaktivierung SMBv1

Für Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10 sowie Windows Server 2008, Windows Server 2008R2, Windows Server 2012, Windows Server 2012R2 und Windows Server 2016 kann die Deaktivierung mittels Gruppenrichtlinie erfolgen. Die notwendigen admx-/adml-Dateien finden wir in den ehemaligen Security Compliance Manager Vorlagen, die mittlerweile als Zip geliefert werden:

Security baseline for Windows 10 „Creators Update“ (v1703) – DRAFT
https://blogs.technet.microsoft.com/secguide/2017/06/15/security-baseline-for-windows-10-creators-update-v1703-draft

Für Betriebssysteme älter als Windows 8.1 sind drei Richtlinien zu konfigurieren. Hierbei ist zwingend die Richtlinie „Configure SMB v1 client (extra setting needed for pre-Win8.1/2012R2)“ korrekt zu konfigurieren. Ältere Windows-Versionen besitzen eine Dienstabhängigkeit des Anmeldedienstes vom SMBv1-Client. Wird der SMBv1-Client also deaktiviert, startet der Anmeldedienst nicht mehr. Die erwähnte Richtlinie entfernt diese Abhängigkeit.

Zusätzlich sind dann noch die clientseitige Komponente (euer Windows kann nicht mehr mit einem SMBv1-Server kommunizieren) und die serverseitige Komponente (euer Windows stellt keine SMBv1-Schnittstelle mehr zur Verfügung bspw. für Admin- oder Druckerfreigaben) zu berücksichtigen. Es sollten also sowohl für Serverbetriebssysteme als auch für Clientbetriebssysteme sowohl clientseitige als auch serverseitige SMBv1 Komponenten deaktiviert werden!

Zum Testen kann das Tool „Eternal Blues“ verwendet werden, welches hier zur Verfügung steht: http://omerez.com/eternalblues
Mit Hilfe des Tools kann das eigene Netzwerk auf EternalBlue Schwachstellen gescannt werden. Zusätzlich zeigt es aber auch an, ob SMBv1 in Verwendung ist.

Deinstallation SMBv1

Ab Windows 8.1 kann SMBv1 auch komplett deinstalliert werden. Das kann bspw. über Powershell erfolgen.

# check OS version as we can only run on Winodws 2012R2/Windows 8.1 or later
If ([int](Get-CimInstance Win32_OperatingSystem).BuildNumber -lt 9600){
    '#' * (76 + ($LocalHostName).Length)
    "Sorry, the script cannot execute on $LocalHostName. It needs at least Windows Server 2012R2 or Windows 8.1."
    Return
}
$check = Get-WindowsOptionalFeature -online | Where-Object {$_.FeatureName -eq "SMB1Protocol"}
if ($check.State -eq 'enabled') {
    Disable-WindowsOptionalFeature -FeatureName "SMB1Protocol" -Online -Norestart
    Restart-Computer<
}

Das Skript kann bspw. mittels GPO als geplanter Tasks auf die Computer verteilt werden. Das Skript prüft, ob es auf einem Windows 8.1 oder höher ausgeführt wird und danach, ob das SMBv1 Protokoll installiert ist. Falls ja, dann wird es deinstalliert und direkt ein Neustart ausgeführt. Man den geplanten Task also auf den Computerstart triggern.

Als Aktion für den Task wählt man „Programm starten“ aus:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Und als Argument dann das entsprechende Powershellskript:

-executionpolicy bypass -file \\fileserv.domain.tld\sharename\SMB1\SMB1.ps1

Für neue Deployments sollte man natürlich gleich darauf achten, dass SMBv1 gar nicht erst installiert ist.  Microsoft hat bereits angekündigt, Windows 10 RS3, welches im Herbst 2017 erscheinen soll, standardmäßig ohne SMBv1 zu installieren.

Weiterführende Links zum Thema SMBv1:

https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1

https://blogs.technet.microsoft.com/secguide/2017/06/15/disabling-smbv1-through-group-policy

https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse

http://omerez.com/eternal-blues-worldwide-statistics

https://blogs.technet.microsoft.com/secguide/2017/06/15/security-baseline-for-windows-10-creators-update-v1703-draft

https://www.heise.de/security/meldung/Cyber-Attacke-NotPetya-Unternehmen-haben-immer-noch-viel-Arbeit-mit-dem-Fallout-des-Angriffs-3782794.html

Im Rahmen einer Überprüfung einer Serververöffentlichung mittels des Qualys SSL Server Test ist dem einen oder anderen vielleicht schon der Punkt CAA Record aufgefallen.

Mittels des weiterführenden Links können weitere Infos über diesen neuen Resource Record abgerufen werden. Wer es ganz genau wissen will, kann sich das entsprechende RFC 6844 durchlesen (https://tools.ietf.org/rfc/rfc6844.txt). Eine deutschsprachige gut verständliche Zusammenfassung gibt es hier: https://gnuheidix.de/archives/64-DNS-CAA-Resource-Record.html

„Der CAA RR ist im RFC6844 beschrieben und definiert, dass man im DNS hinterlegen kann, welche CA einem ein Zertifikat ausstellen darf …“

Unter https://sslmate.com/labs/caa/ befindet sich ein Syntax-Generator, welcher für die Kombination der eigenen Domain und diverser Zertifizierungsstellen die entsprechenden CAA Ressource Records erstellt. Das Ergebnis sieht dann etwa folgendermaßen aus:

So weit, so einfach. Interessant wird es, wenn man versucht, diese Einträge in einen Windows Server 2016 DNS zu bekommen.

Windows 2016 unterstützt mittels RFC 3597 Syntax das Anlegen unbekannter Einträge (unknown records).
https://docs.microsoft.com/en-us/windows-server/networking/dns/what-s-new-in-dns-server

„Unknown record support

An „Unknown Record“ is an RR whose RDATA format is not known to the DNS server. The newly added support for unknown record (RFC 3597) types means that you can add the unsupported record types into the Windows DNS server zones in the binary on-wire format. The windows caching resolver already has the ability to process unknown record types. Windows DNS server will not do any record specific processing for the unknown records, but will send it back in responses if queries are received for it.“

Damit hat sich aber auch schon mehr oder weniger die komplette Dokumentation dieses Features erledigt. Es ist naheliegend, dass sich das Eintragen solcher Resource Records mittels Powershell erledigen lässt. Da sich offenbar kaum jemand einen DNS Server mit Windows für die public DNS Zone „hält“, findet sich aber auch nach längerer Recherche leider kein Beispiel oder Ähnliches. Deswegen hier kurz die Powershell-Syntax, sollte man selbst vor diesem Problem stehen.

Add-DnsServerResourceRecord -Name faq-o-matic.net -RecordData 0005697373756564696769636572742E636F6D -Type 257

Ich habe keinen Weg gefunden, diese Art Einträge mittels der DNS-Konsole anzulegen, aber wenn sie mittels Powershell oder Editieren des Zonenfiles erstmal erzeugt sind, sieht das in der GUI folgendermaßen aus.

Das Ergebnis sieht dann so aus wie auf dem folgenden Screenshot.

Wer allerdings keinen eigenen DNS-Server betreibt, muss wohl noch eine Weile warten, bis die ganzen DNS-Hoster eine entsprechende Funktion direkt in der GUI ihrer Adminoberfläche oder zumindest mittels Support anbieten. Nachfolgend eine kleine Aufstellung meiner Nachfragen und Recherchen, die natürlich keinen Anspruch auf Vollständigkeit erheben. Sollten Ergänzungen oder Korrekturen benötigt werden, bitte ich um eine kurze Benachrichtigung über https://www.faq-o-matic.net/impressum/

• All-inkl.com – mittlerweile hat der Provider seine CAA-Unterstützung umgesetzt und bietet eine Anleitung dafür: https://all-inkl.com/wichtig/anleitungen/kas/tools/dns-werkzeuge/caa-record_501.html.
• DomainFactory – im Support Forum findet sich die folgende Aussage: https://www.df.eu/forum/threads/80683-Unterstützung-für-CAA-Records?p=519285&viewfull=1#post519285
• Hosteurope – wird auf Nachfrage bis auf Weiteres diese Einträge nicht unterstützen.

Es bleibt also abzuwarten, wann und welche Provider mitziehen. Ist wohl ähnlich wie beim SPF Record, der auch relativ lange benötigte, bis man ihn endlich setzen konnte.

Seit vielen Jahren bietet das Standard-AD-Tool “Active Directory-Benutzer und -Computer” eine Option, wichtige Container vor versehentlichem Löschen zu schützen:

[“Objekt vor zufälligem Löschen schützen” per Skript setzen | faq-o-matic.net]
https://www.faq-o-matic.net/2010/05/21/objekt-vor-zuflligem-lschen-schtzen-per-skript-setzen/

In einem Projekt habe ich festgestellt, dass sich dies nun auch per PowerShell recht simpel erreichen lässt:

Get-ADOrganizationalUnit -SearchBase 'name -like OU=MeineOU' | Set-ADObject -ProtectedfromaccidentialDeletion $true

Anmeldedaten im Klartext zu übermitteln ist eine schlechte Idee. Das trifft sowohl für externe wie auch für interne Netzwerke zu. Niemand sollte heutzutage davon ausgehen, dass ein Lokales Netzwerk sicher ist, nur weil es lokal ist. Die meisten Emailprovider haben inzwischen die Übermittlung der Anmeldedaten über ungeschützte Protokolle wie POP3, IMAP4 und SMTP unterbunden und auf die jeweils gesicherte Protokollversion umgestellt. Interne Ressourcen wie Webserver verwenden oftmals auch schon https statt http und wer sich im Eventlog seiner Domänencontroller (Verzeichnisdienst-Protokoll) mit folgenden Event IDs konfrontiert sieht, sollte wissen, dass dies die Übermittlung von Anmeldedaten im Klartext bedeutet.

Diese können selbstverständlich mit Hilfe von Netzwerktraces mitgeschnitten und verwendet werden.

Eventid 2286

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd941829(v=ws.10)

Eventid 2287

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd941856(v=ws.10)

Im worst case sind es privilegierte Kontodaten, die dort leichtfertig übertragen werden. Mitarbeiter werden aber auch die Übertragung ihrer persönlichen Kennworte in ungesicherter Form nur schwerlich akzeptieren, nachdem der Administrator ihnen vorab eine entsprechend komplizierte Kennwortrichtlinie auferlegt hat.

Per Gruppenrichtlinie kann dieser Zustand behoben werden. Allerdings sollten dazu erst einmal die Systeme identifiziert werden, welche dort per Klartext Anmeldungen durchführen, damit kein Ausfall wichtiger Systeme erfolgt.

Als erstes muss das Logging der LDAP Schnittstelle auf jedem DC erhöht werden.

Logging erhöhen

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v „16 LDAP Interface Events“ /t REG_DWORD /d 2

Wer das lieber per Regedit erledigen möchte, kann das natürlich tun.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

16 LDAP Interface Events auf 2 setzen

Ab jetzt werden weitere Ereignis-IDs im Verzeichnisdienst-Log erzeugt, wenn wieder eine Anmeldung stattfindet. Ein Reboot ist nicht notwendig. In diesem Event 2889 steht dann die IP Adresse des sich anmeldenden Systems sowie die Nutzeridentität, welche sich gerade anmeldet.

Das Logging kann je nach Umgebung sehr viele Ereignisprotokolleinträge erzeugen. Es sollte also darauf geachtet werden, dass die sehr häufig auftretenden Systeme schnell identifiziert und entsprechend konfiguriert werden. Damit das Eventlog etwas einfacher zu überblicken ist, kann ein Filter verwendet werden oder gleich eine „Benutzerdefinierte Ansicht“ erstellt werden. Gefiltert wird das Verzeichnisdienstprotokoll auf die folgenden IDs:

2886, 2887, 2888, 2889 (alternativ 2886-2889)

Danach sieht das Ereignisprotokoll etwas aufgeräumter aus.

Sind die Systeme identifiziert, kann das Logging vorerst deaktiviert werden und die Problemlösung begonnen werden.

Logging deaktivieren

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v „16 LDAP Interface Events“ /t REG_DWORD /d 0

Alternativ kann natürlich der Wert per regedit wieder auf 0 gesetzt werden (siehe oben).

Je nach Applikation kann das Problem mit der Umstellung auf eine sicherere Authentifizierung statt „Simple Bind“ oder die Verwendung von ldaps (Port TCP 636) erfolgen. Letzteres setzt die Verwendung entsprechender Zertifikate auf den Domaincontrollern voraus.

Sind die Applikationen neu konfiguriert, kann das Logging wieder erhöht werden, um gegebenenfalls weitere Systeme zu identifizieren. Diese Vorgänge werden solange wiederholt, bis sichergestellt ist, dass alle relevanten Systeme erkannt und deren Konfigurationen geändert wurden.

Gründe warum solche Systeme im eigenen Netzwerk vorhanden sind gibt es viele. Die Active Directory Dienste mit Hilfe einer ungesicherten LDAP Bind Authentifizierung zu monitoren, sollte also keine Option darstellen. Andere Dienste wurden in der Vergangenheit möglicherweise zu einem Zeitpunkt implementiert, als noch keine Zertifikate auf den Domänencontrollern zur Verfügung standen, oder die Zertifikatskonfiguration wurde als zu komplex empfunden. Eventuell finden sich auch Systeme, welche keine ldaps- oder sichere Bindungsmöglichkeiten bieten. Diese Systeme sollten nicht mehr zum Einsatz kommen, sondern gegen modernere Versionen oder Lösungen ersetzt werden.

Damit zukünftig keine erneute Implementierung dieser Bindungsform oder Systemen ohne ldaps Möglichkeit stattfinden kann, wird die ldap Signierung auf den Domänencontrollern erzwungen. Die entsprechende Konfiguration kann mit Hilfe von Gruppenrichtlinien auf die OU der Domänencontroller durchgeführt werden.

Nach dieser Konfiguration sind Simple Bind Anforderungen über ldap nicht mehr möglich. Über ldaps funktionieren Simple Binds weiterhin.

Weiterführende Lektüre:

http://setspn.blogspot.de/2016/09/domain-controller-ldap-server-signing.html

https://blogs.technet.microsoft.com/russellt/2016/01/13/identifying-clear-text-ldap-binds-to-your-dcs/

http://www.msxfaq.de/windows/event2887.htm

Manchmal fragt man sich, was sich Microsoft bei manchen Übersetzungen so denkt.

Ist zwar korrekt, aber ob man das in der Form wirklich in Server 2019 übernehmen sollte?

Wenn tiefere Einblicke in den Netzwerktraffic benötigt werden, kommt regelmäßig das Tool Wireshark zum Einsatz. Das ist quasi das Schweizer Taschenmesser für diese Zwecke. Allerdings gibt es auch immer wieder Netzwerke, bei denen man keine Zusatztools auf sensitiven Systemen installieren will oder darf oder die Einrichtung eines Mirrorports nicht so schnell möglich ist. In solchen Fällen kann man sich mittels netsh helfen, welches seit Windows 7/2008R2 in der Lage ist, Netzwerktraces zu ziehen. Diese Dateien können dann bspw. mit dem Microsoft Network Monitor oder dem Microsoft Message Analyzer ausgewertet werden.

Beispiel, welches den Netzwerktrace startet und nur IPv4-Traffic von der Quelladresse 192.168.160.29 in der Zieldatei mynetshtrace.etl im Ordner c:\preinst aufzeichnet:

netsh trace start capture=yes Ethernet.Type = IPv4 IPv4.Address = 192.168.160.29 tracefile = c:\logfiles\mynetshtrace.etl

Beispiel in der Powershell, welches mehrere Quell-/Zieladressen berücksichtigt und die Trace-Datei mit dem Computernamen versieht, welcher den Trace aufzeichnet. Die Datei kann maximal 2GB groß werden und wird per Umlaufprotokollierung überschrieben, wenn diese Größe erreicht wird.

$filename = "c:\logfiles\${env:computername}_netsh_trace.etl"
$IPs = "({0},172.25.28.12,172.25.28.11,172.25.28.13,172.25.28.14,172.25.28.15)" -f (Get-NetIPAddress -AddressFamily IPv4 -InterfaceAlias *-Verbindung).IPAddress 
netsh trace start capture=yes tracefile=$filename maxsize=2048 filemode=circular overwrite=yes report=no correlation=no IPv4.SourceAddress=$IPs IPv4.DestinationAddress=$IPs Ethernet.Type=IPv4

Der Trace kann schnell sehr groß werden und sollte entweder mit Umlaufprotokollierung laufen oder rechtzeitig gestoppt werden. Das Anhalten des Netzwerktraces erfolgt mittels folgenden Befehls:

netsh trace stop

Danach erzeugt netsh eine cab-Datei, in welcher sich zusätzliche Infos wie Ereignisprotokolle, Registryauszüge usw. finden. Für die Auswertung wird in diesem Fall aber nur die erzeugte .etl-Datei benötigt. Diese wird auf das System kopiert, auf welchem bspw. der Microsoft Message Analyzer installiert ist. Das Tool kann hier heruntergeladen werden:

https://www.microsoft.com/en-us/download/details.aspx?id=44226

Nach der Installation wird das Tool gestartet und die .etl-Datei geladen.

Je nach Größe dieser Datei und der Leistungsfähigkeit des Computers kann das Einlesen der Datei einige Minuten dauern. Über Filter kann das Ganze etwas übersichtlicher dargestellt werden. Bspw. kann man sich nur den Netzwerktraffic des LDAP-Protokolls anschauen, indem als Filter tpc.port==389 definiert wird.

Wenn man analysieren will, mit welchem User ein LDAP Simple Bind durchgeführt wurde, kann folgender Logeintrag weiterhelfen:

Mittels Rechtsklick auf einzelne Spalten kann man bspw. nach den Modulen gruppieren lassen.

Im Detailfenster ist dann die gewünschte Information zu sehen.

Ein Grund mehr, warum man auf Klartextprotokolle im Normalbetrieb verzichten sollte.

Weiterführende Links für Anwendungszwecke und Beispiele:

https://blogs.msdn.microsoft.com/canberrapfe/2012/03/30/capture-a-network-trace-without-installing-anything-capture-a-network-trace-of-a-reboot/

https://community.ipswitch.com/s/article/Use-Netsh-to-capture-the-network

… bei Fehlern wird man dann schon förmlicher und siezt wieder.