Aktives Verzeichnis Blog

TechEd Europe 2009: Tag 5 – oder besser: Fazit

Am Tag 5 habe ich keine Sessions mehr besucht, es gab andere Dinge zu erledigen. Ich hoffe, daß ein, zwei der verpaßten Sessions früher oder später noch für TechEd Teilnehmer online verfügbar sein werden – dann kann ich das noch nachholen.

Daher bleibt an dieser Stelle etwas Platz für ein ganz persönliches (technisches) Fazit. Für mich gab es vier Hauptpunkte, die ich als “Botschaft” aus den Sessions mitgenommen habe:

1. Es wurde immer wieder angekündigt, auch ich persönlich spreche schon eine ganze Zeit lang mit unseren Kunden darüber, doch jetzt führt kein Weg mehr daran vorbei – die PowerShell. Ein Sprecher eines der PowerShell Vorträge auf der TechEd sagte dazu:
   
   “In Windows Server 2003 konnten 97% der Aufgaben mit der Kommandozeile erledigt werden, der Rest nur mittels GUI – heute können 85% der Aufgaben über die GUI erledigt werden, den Rest erreicht man nur noch per PowerShell.”
   
   Viel ist dem nicht mehr hinzuzufügen. Ohne Kenntnisse mit der PowerShell wird man in Zukunft kaum noch alle administrativen Aufgaben auf einem Windows System und dessen Applikationen und Diensten durchführen können – und das ist meiner Meinung nach auch gut so. Zumal sich mit der PowerShell so einiges einfacher gestalten läßt, was bisher mühsam "zusammengescripted" werden mußte. Wer sich also mit dem Thema noch nicht weiter beschäftigt hat, wird nun allerspätestens ab Windows 7 und Windows Server 2008 R2 nicht mehr daran vorbei kommen. JETZT ist es Zeit, sich intensiv damit zu beschäftigen!
   
   
2. Thema Sicherheit: Kaum einer der von mir besuchten Sessions hatte nicht auf die ein oder andere Art und Weise das weite Thema “Sicherheit” im Programm. Es ging um Datensicherheit (Datenschutz als auch Datensicherung), es ging um Verschlüsselung (z.B. der Festplatte, auf Dateiebene, des Datentransports, der Kommunikation) und nicht zuletzt ging es um das Bewußtsein rund um dieses Thema im Management von Unternehmen, den Administratoren als auch den Mitarbeitern.
   
   Mit der rapide wachsenden Anzahl vernetzter Systeme wächst auch dieser Themenkomplex immer weiter – so schnell, daß man kaum noch umhin kommt, sich jedem der daran angrenzenden Themen tiefgreifend zu widmen. Es reicht eben nicht, nur einen Virenscanner und eine Firewall auf einem Client zu installieren und danach zu resümieren, jetzt sei alles “gesichert”. Das Thema ist technisch als auch organisatorisch weit komplexer und man tut gut daran, auf dem Laufenden zu bleiben. In allerseitigem Interesse.
   
   
3. Spätestens seit der Umstellung des IP-Stacks von IPv4 auf IPv6 in Vista / 2008 sollte klar sein, daß man sich vor einer Umstellung nicht mehr “drücken” kann. Wer sich nun in der Produktpalette unserer Produkte umschaut wird unschwer feststellen können, daß nicht nur die IPv4 Adressknappheit hier Pate stand, sondern daß sich einige Features sehr elegant mit IPv6 lösen lassen oder überhaupt erst mit IPv6 möglich werden. Komponenten wie die neue Windows 7 Remote Assistance, Home Groups, Direct Access etc. werden neben anderen Faktoren direkt durch IPv6 ermöglicht.
   
   Jedem Netzwerk-, Server- und Applikationsadministrator als auch den Softwareherstellern muß klar sein, daß eine Umstellung auf IPv6 nicht mehr aufzuhalten ist – im Gegenteil, die “große Umstellung” steht direkt bevor. Wer sich also bis heute vor dem (durchaus komplexen) Bereich IPv6 gedrückt hat sollte sich nun zeitnah diesem Thema nähern. Es wird keinen (NAT-)Aufschub wie im Jahr 1995 mehr geben.
   
   
4. Features, Features, Features: Die “Wave 14” schwirrt nun seit einiger Zeit in meinem Kopf herum – eine Menge Produkte werden 2009 / 2010 veröffentlicht, viele davon mit Meilensteinen in Ihrer Entwicklung. Was mir persönlich jedoch vor der TechEd nicht so stark bewußt war ist die Tatsache, wie viele neue Features rund um die gesamte Produktpalette damit einhergehen – und wie viele Funktionen im Zusammenspiel mit anderen Funktionen anderer Produkte Ihre Kraft erst richtig entfalten.
   
   Die Betreiber bzw. Verwalter (=Administratoren) dieser Funktionen werden eine Menge dazu lernen müssen, vieles ist anders (aber vieles auch besser), sehr vieles ist neu. Aber was dort teilweise direkt mit dem Betriebssystem zusammen ausgeliefert wird, ist meiner Meinung nach wirklich “atemberaubend”.
   
   Ja – einige der Funktionen sind nur nutzbar, wenn man als Basis Windows 7 und Windows Server 2008 R2 einsetzt. Aber wer sich mit der Entwicklung von Software beschäftigt weiß, daß man irgendwann einmal “alte Zöpfe” abschneiden muß. Das Design von Windows Vista unterscheidet sich maßgeblich vom Windows XP Design, rein technisch ist es also an einigen Stellen gar nicht in vertretbarem Zeitrahmen möglich, Funktionen zurück zu portieren. Wer also den Schritt macht und auf Windows 7 und Windows Server 2008 R2 umstellt, hat mittelfristig eine ungeheure Menge an neuen Möglichkeiten dazugewonnen, seine IT effizient zu betreiben, den Nutzern und Kunden wertvolle neue Funktionen zu liefern und vor allen Dingen damit Kosten zu sparen. Die Investition lohnt sich also!

Ich hoffe Euch hat die kleine Beitragsserie “TechEd Europe 2009” gefallen – wir freuen uns wie immer auf ehrliches Feedback.

Viele Grüße
Fabian

TechEd Europe 2009: Tag 4

Der vorletzte Tag der TechEd stand für mich größtenteils im Zeichen des “Auffrischens von Themen”. So ist ein Teil des “daily business” bei uns im Domain Team das Thema “Gruppenrichtlinien”, so daß die drei angebotenen Sessions rund um diesen Bereich sicher nicht verkehrt waren. Es gab zwar für mich persönlich zwar nichts neues zu erfahren, aber es war angenehm, Michael Kleef einmal persönlich kennenzulernen – denn er ist als Program Manager einer unserer Ansprechpartner in den USA zu diesen Themengebieten (für Produktänderungen im Allgemeinen, “design change requests” oder bei “code defects”).

<schleichwerbung>
Ein Kollege und ich halten übrigens zu den Themen “Gruppenrichtlinien”, “GPO Troubleshooting” und “AGPM” auch Workshops – sollte also daran Interesse bestehen, einfach mal beim TAM nachfragen; Premier Vertrag bei uns vorausgesetzt.
</schleichwerbung>

Group Policy Changes for Windows 7 and Windows Server 2008 R2

Wie der Titel vermuten läßt ging es im Beitrag um die Darstellung der neuen GPO-relevanten Funktionen in Windows 7 respektive Windows Server 2008 R2.

Angefangen wurde mit den Änderungen in der technischen Implementierung seit Vista, nämlich daß die Gruppenrichtlinien nun nicht mehr im Winlogon-Kontext laufen, sondern einen eigenen Dienst “spendiert” bekommen haben und nun auch bei Gruppenrichtlinien seit der Network Location Awareness (NLA) eine neue Rolle spielt (so werden GPOs nun etwa nicht mehr nur zyklisch abgearbeitet, sondern auch beim Ändern des Netzwerkprofils, z.B. von “public” auf “domain”).

Danach ging es weiter mit den “Features” (schon in Vista vorhanden), einige davon sind:

• in Vista ca. 800 neue GPO-Einstellungen dazu gekommen, in Windows 7 noch einmal 300 (sehr viel davon Internet Explorer Administrative Templates)
• das Format der Administrative Templates Vorlagedateien hat sich von ADM auf ADMX + ADML geändert, damit sind eine ganze Menge Vorteile verbunden, so etwa Sprachunabhängigkeit
• ADMX / ADML central store
• SYSVOL DFSR Replikation
• multiple lokale GPOs

In Windows 7 kamen dann noch zusätzliche Funktionen dazu, beispielsweise:

• PowerShell CMDlets für GPO Operationen (einige der GPMC Operationen wie Backup / Restore, Bearbeitung von Registry Settings, Verlinkungen, ACL-Änderungen usw.)
• PowerShell Support für Logon- und Startup-Scripts
• Starter-GPOs mit Sicherheitsvorlagen sind nun schon integriert und müssen nicht erst importiert werden (O-Ton: testen, testen, testen)
• ADMX-Verbesserungen
• UI Verbesserungen in GPEDIT.MSC
• neue Wireless Einstellungen
• Audit Policy Group Policy Support, d.h. es muß nicht mehr wie noch unter Vista “auditpol.exe” für Sub-Kategorien der Überwachung genutzt werden
• GPP-Verbesserungen und Erweiterungen, so etwa bei den Scheduled Tasks, Power Plan Settings –> hier kam der Hinweis, daß diese Verbesserungen in Vista erst voraussichtlich Ende des Jahres mit einem CSE Update verfügbar sein werden

Als generelle Empfehlung wurde dann noch mehrfach angemerkt, im Domänen Modus Windows Server 2008 DFSR als SYSVOL Replikationslösung einzusetzen und FRS abzulösen (viele der Probleme, die wir im GPO-Bereich sehen, sind direkt oder indirekt Folge von SYSVOL-Replikationsproblemen im weitesten Sinne) und nicht tausende von GPOs in einer Umgebung einzusetzen. Stichwort hier: Konsolidieren!

Möchte man in einer Umgebung Windows 7 mit den neuen Policies einsetzen, sollte man vorher die Kompatibilität der neuen Einstellungen mit anderen eingesetzten Betriebssystemen prüfen – eine Übersicht gibt es als Excel Datei.

Troubleshooting Group Policy

Um im Problemfall den richtigen Ansatz zu finden, warum Gruppenrichtlinien nicht greifen oder bestimmte Einstellungen scheinbar nicht am Client ankommen, muß man in vielen Fällen das Design von Gruppenrichtlinien verstehen.

Daher wurde zuallererst der Unterschied zwischen Core-Processing und CSE-Processing erläutert. Im Core-Processing werden alle Aufgaben durchgeführt, die notwendig sind um festzustellen, welche Gruppenrichtlinien anzuwenden sind und welche Komponenten (Client Side Extensions (CSE)) aufzurufen sind:

Erst danach startet dann die CSE Abarbeitung, die dann dafür sorgt, daß die Komponenten konfiguriert werden, also etwa Explorer-Einstellungen, IE-Einstellungen, Registry-Werte etc. Einen wichtigen Punkt bei dieser Abarbeitung beschreibt der folgende Artikel: http://blogs.technet.com/deds/archive/2009/05/15/prioritaet-group-policy-objects-vs-group-policy-preferences.aspx

Nun muß man also erst einmal entscheiden, was genau man denn nun eigentlich prüft: Das Core Processing oder das CSE Processing. Für das Core Processing stehen Tools wie “Ultrasound”, “GPOTOOL”, "die Ereignisprotokolle + GPOLOGVIEW, GPMC und GPMC RSOP Group Policy Results zur Verfügung, das USerEnv bzw. GPSVC Logging (und viele mehr) zur Verfügung. Das CSE Processing erfordert dann neben GPMC und den Ereignisprotokollen eigene Logs pro Komponente. Die Group Policy Preferences bringen eigene Logs mit, die sehr übersichtlich gehalten sind und die Fehlersuche stark vereinfachen können.

Das zu verinnerlichen ist die halbe Miete bei der Problemsuche. Danach sind die erforderlichen Tools und Logs schnell gefunden. Nur interpretieren muß man die Angaben dann noch selbst (und wenn möglich natürlich auch richtig ;-) …).

Microsoft Desktop Optimization Pack: Managing GPOs with Advanced Group Policy Management (AGPM) 4.0

Grundsätzlich ist AGPM dafür gedacht, die Verwaltung von Gruppenrichtlinien in Prozesse zu gießen und vor allen Dingen die Editoren, Prüfer und freigebenden Instanzen zu organisieren. Dies ist mit Boardmitteln und der GPMC nicht so einfach möglich – diese Lücke schließt AGPM. So können nun dedizierte Mitarbeiter Veränderungen an Richtlinien durchführen, ohne daß diese gleich live geschaltet werden – erst nach Freigabe durch eine andere Instanz werden die Einstellungen ausgerollt.

Zusätzlich ist das ganze noch in einer Historie dokumentiert, so daß sich der Zeitpunkt der Änderung als auch derjenige bestimmen läßt, der die Änderung durchgeführt hat. Weiterhin kann man über Differenzreporte dann prüfen, was sich geändert hat – und das nicht nur innerhalb einer Policy; die Differenzen lassen sich auch über verschiedene Policies anzeigen.

Mit AGPM 4.0 kommen nun die Funktionen “Suche” von GPOs, Multi-Forest Support und Windows 7 / 2008 R2 Support dazu.

Insbesondere wenn Themen wie gute Verwaltbarkeit von GPOs, Delegierung von GPO-Berechtigungen, Prüfvorschriften vor Rollout, Change Management, Import / Export aus Test und Produktivforest, ITIL oder ISO usw. im Unternehmen eine Rolle spielen, dann sollte man einen Blick auf AGPM werfen. Folgende Screencasts geben einen wie ich finde guten Überblick (Silverlight benötigt), Quelle:

Windows Performance Troubleshooting and Analysis

Daniel Pearson gab einen guten Überblick über verschiedene Tools zum Performance Troubleshooting. Schaut man sich ein potentielles Problem oder eine Fragestellung in dieser Richtung an, dann ist auch hier einer der wichtigsten Punkte, das richtige Programm für die Aufgabe zu finden.

Nach einer kurzen Unterscheidung zwischen dem Event Tracing für Windows (Achtung, PowerPoint Download), zu dessen Vorteile wie geringer Overhead, gute Skalierung und hohe Performance zählen, und dem Auslesen von Kernel Mode Strukturen (etwa mittels dem Performance Monitor “Perfmon”), wurde die in Windows 7 / 2008 R2 stark erweiterte Version des “Resource Monitors” in einer Demo vorgeführt. Zugegeben, die Analyse von Prozessen und deren “Arbeit” auf einem System dürfte damit stark vereinfacht werden.

Aber auch XPerf mit seinen “Teilen” “xperf.exe”, “xbootmgr.exe” und ”xperfview.exe” können hier sehr gute Arbeit leisten. Ich persönlich war erstaunt, wie genau xperf.exe die Analyse von Daten ermöglicht – bis herunter gebrochen auf “context switches” von Threads bzw. Prozessen. XPerf läßt sich normalerweise nur ab Vista installieren – jedoch läßt sich das Mitschneiden (nicht das Auswerten) auch auf einem XP / 2003 System bewerkstelligen, wenn man die Dateien “xperf.exe” und “perfctrl.dll” auf diese Systeme kopiert und nur die Auswertung des *.etl Traces dann auf Vista / 2008 aufwärts durchführt.

Einen Trace erzeugt man am einfachsten während der gewünschten Analysesituation mittels

C:\> xperf.exe –on DiagEasy

Man kann die zu tracenden Daten natürlich auch einschränken, jedoch ist “DiagEasy” ein guter Startpunkt. Danach stoppt man den Trace und speichert ihn als *.etl ab:

C:\> xperf.exe –d trace.etl

Nun kann durch den Aufruf des folgenden Kommandos der Trace grafisch analysiert werden:

C:\> xperf.exe trace.etl

Da es hierbei schier unzählige Möglichkeiten, Optionen und Auswertungsparameter gibt, sollte man vor einem konkreten Problemfall einfach einmal einen Trace ziehen, alle verfügbaren Optionen sichten und mit den Daten “herumspielen”. Andernfalls fällt eine Analyse für den ungeübten Admin sicher nicht ganz einfach aus.

Neben einem Ausflug in die Theorie der CPU-Zeiten, etwa dem Umstand, daß die Prioritätswerte 0-15 für dynamische Zuweisungen stehen und 16-31 dann “real time” Prozesse darstellen, wurde auch Bezug auf die CPU-Zeit Auswertung selbst genommen. Vor Vista waren diese nämlich nicht immer akkurat verteilt, da die Messung anhand von “Meilensteinen” bzw. “Prüfmarken” im Sinne der gerechten CPU-Zeit Verteilung nicht “sauber” war. Ab Vista wird nun anstatt mit Prüfmarken mit Timestamp Countern gearbeitet, so daß es hier gerechter bei der Verteilung zugeht. Gelebte Nächstenliebe vom OS sozusagen. ;-)

Es folgen dann noch einige praktische Analysen per Demo Vorführung, bei der auch der Process Explorer Thema war.

Wer mehr zu dem Thema wissen will, der schaut in das Buch Windows Internals hinein; der Co-Autor Daniel Salomon ist Arbeitgeber von Daniel Pearson.

Viele Grüße
Fabian

TechEd Europe 2009: Tag 3

Windows 7 AppLocker: Configuration and Deployment

Einen guten Start in den Tag legte Paul Cooke (siehe Tag 2: Bitlocker) vor – er stellte das neue Windows 7 AppLocker als Teil eines gesamten Sicherheitskonzepts von Unternehmen dar, die weitere Sicherheitsmaßnahmen wie Anti-Virus Software, DRM, Verschlüsselung, ACLs etc. unterstützen kann. Da Schadsoftware selbst im Benutzerkontext ohne Administrationsrechte zumindest die Rechte des ausführenden Benutzers besitzt, ist dies schon ein ausreichend großes Problem; es wird wohl niemanden geben der behauptet, die Daten seines Vorstandsvorsitzenden oder beispielsweise der Personalabteilung seien nicht weiter wichtig – denn auf die kann ein Angreifer im Benutzerkontext des jeweiligen Nutzers zugreifen. Hier greift nun AppLocker hinein.

AppLocker kann in Unternehmen die Software Restriction Policies ablösen oder aber parallel betrieben werden, solange es noch Systeme “kleiner als” Windows 7 in der Umgebung gibt. Im Prinzip sollte AppLocker jedoch langfristig die SRP ablösen. Und das aus gutem Grund, schließlich sind damit genau die Probleme adressiert, die mit Software Restriction Policies immer wieder zu Tage traten: Es gibt “Allow”, “Deny” oder “Exception” Regelwerke, wobei als Best Practice ganz klar ein Regelwerk aus “Allow” plus “Exceptions” angewendet werden sollte. Whitelisting macht mehr Sinn als das Blacklisting, denn alles zu verbieten, was man nicht möchte, kann in 10 Minuten schon wieder von der Realität “da draußen” überholt worden sein.

Wie auch mit den SRP bietet AppLocker Publisher-, Hash- und Pfad-Regeln – nur sind diese bei weitem Flexibler als die SRPs. So können zusätzliche Attribute festgelegt werden, wie etwa Dateiversion (auch mit größer / gleich Operatoren), Dateiname o.ä., auch wenn eine Publisher-Regel zum Einsatz kommt. Außerdem gibt es “Rule Targets”, d.h. man kann Regeln auf Benutzer oder Gruppen anwenden. Ein Segen für alle Administratoren, die bisher auf den Zielsystemen keine Rechte hatten, obwohl sie Administratoren waren. Auch Ausnahmen lassen sich so gewährleisten, etwa alle Benutzer dürfen Applikation XY nicht benutzen, außer der Personalabteilung.

Zusätzlich kamen weitere “Rule Types” dazu, es können nun neben den bekannten “*.exe” Regeln auch Scripte, Installer oder sogar DLLs gefiltert werden. Aber Vorsicht – DLL-Einschränkungen können das System extrem verlangsamen, so daß dies nicht im Regelfall eingesetzt werden sollte. Weiterhin sollte man darauf achten, einige Standardregeln beizubehalten – denn ohne bestimmte Standardregeln, läßt sich das System auch vollkommen lahmlegen – denn ohne das Zulassen von Betriebssystem-relevanten Dateien, kann keine Benutzeranmeldung mehr erfolgen etc. Hier also der Hinweis, das ganze (wie auch sonst bei anderen Themen) in seiner Testumgebung ausgiebig zu testen.

Es gibt einen Testmodus, indem alle Software, die auf dem System läuft, bei Aufruf ins Eventlog geschrieben wird. So kann man komfortabel eine Basislinie der Applikationen erstellen, die man zulassen müßte / sollte, wenn man Probleme verhindern möchte. Die Dokumentation steht also vor allen weiteren maßnahmen. Da sich selbst APP-V Applikationen filtern lassen, ist dieses Logging wirklich Gold wert.

Was das ganze jedoch noch viel interessanter macht ist die Möglichkeit, aus diesen Eventlog Einträgen per PowerShell CMDlets automatisch Regeln zu erzeugen, zu exportieren oder zu importieren. Dadurch lassen sich Prozesse im Prinzip komplett automatisieren.

Alles in allem noch einmal der eindringliche Hinweis, das Design, die Ausnahmen, die Anordnung, das Testen wirklich sehr ausführlich durchzuführen – alles andere führt fast zwangsläufig zu größeren Problemen. Mit AppLocker kann man dann jedoch die Gesamtsicherheit seiner Umgebung stark anheben – sofern man die Pflege der Regeln dann nicht vernachlässigt.

Einen kleinen mit Screenshots hinterlegten Überblick zu AppLocker findet man auch hier.

BranchCache Deep Dive: An IT Administrator's Primer

Ravi Rao lieferte die nächste Session auf meinem Plan.

Die Problemstellung, die der Branch Cache in Windows 7 und Windows Server 2008 R2 adressiert, lautet unter anderem: Verbindungen von Außenstellen mit geringer Bandbreite und hoher Latenzen wirken sich nicht nur auf die Kosten für die Leitung selbst aus, sondern auch auf die Produktivität der Mitarbeiter. Da in einer globalisierten Welt, in der wir heute leben, immer mehr Zweigstellen angebunden werden, ist dies ein nicht zu unterschätzender Kostenfaktor.

Der Branch Cache stellt zwei Modi zur Verfügung: Einmal einen “distributed cache”, bei dem in einem peer-to-peer Netzwerk Clients untereinander Daten austauschen, und einmal einen “hosted cache”, bei dem ein beliebiger Server in der Zweigstelle diese Aufgabe übernimmt. Es werden in beiden Fällen nur diejenigen Daten geladen, die von einem Client der Zweigstelle angefordert wurden – danach kann diese Datei durch andere Clients direkt lokal in der Außenstelle geladen werden. Das ganze passiert “Protokolltransparent” auf W7 und 2008 R2, d.h. es funktioniert für Protokolle wie SMB, HTTP, FTP o.ä.

So kann etwa SCCM den Branch Cache nutzen, um Software oder Applikationen zu verteilen, die nur einmal aus der Hub-Site heruntergeladen wurden, gleiches gilt für WSUS. SharePoint und generell der IIS kann davon profitieren (HTTP / HTTPS), Dateiserver (SMB) oder auch APP-V Applikations-Streaming. Dritthersteller können die Technik lizenzieren, so daß hier ggf. ebenfalls neue Features denkbar sind.

Technisch wird das ganze über Hashes geregelt, die vor einem Herunterladen der Datei ausgetauscht und über Broadcasts bzw. Multicasts in der Site / dem Link des anfragenden Clients abgefragt werden. Das ganze Prinzip der Aufteilung in Daten-Chunks / Blöcke, geschieht nach dem gleichen Muster wie bei DFSR. Ich vermute also, daß die Clientfunktionalität der “Remote Differential Compression” vom Branch Cache genutzt wird, habe es mir jedoch noch nicht genauer angeschaut. Um das Feature nutzen zu können, muß es auf den entsprechend vorgesehenen Clients und Server installiert worden sein. Da zwischen Branch Cache und Datenzugriff die Applikation selbst steht, die die Authentifizierung und Authorisierung regelt, ist der Branch Cache kein “Sicherheitsrisiko”. Es geht um den reinen Abruf der Daten nach diesen Prozessen, der Transport erfolgt hierbei verschlüsselt.

Das Feature läßt sich per GPO oder NETSH Kommandozeile aktivieren und auch “steuern”. Zur Überwachung stehen SCOM Management Packs, ein eigener Eventlog Channel, Performance Counter und auch NETSH zur Verfügung. Obwohl der Zugriff auf die Daten natürlich geschützt ist, sollte man in Zweigestellen über den Schutz der Branch Cache hostenden Systeme (Clients oder Server, je nach Modus) nachdenken. Entweder auf Festplattenbasis (Bitlocker) oder auf Dateibasis (EFS).

Die DEMOs waren wirklich interessant und vielversprechend, das Thema ist es wert, einen genauen Blick darauf zu werfen (wie die anderen Themen natürlich auch ;-) …).

Zusätzliche Ressourcen zum Thema findet sich hier: http://technet.microsoft.com/en-us/network/dd425028.aspx

Security Best Practices for Hyper-V and Server Virtualisation

Der Titel der Session von Jeff Woolsey lies mich eigentlich andere Themen erwarten, aber insgesamt war die Session sehr breit gefächert – was mir als “nicht Hyper-V Experten” natürlich sehr zuträglich war. ;-)

Es ging unter anderem um Sicherheitsaspekte der Trennung zwischen der “Parent Partition” und den “Child-Partitionen”; sobald die Hyper-V Rolle installiert wurde und der Reboot stattgefunden hat, ist das “installierte System” die Parent Partition, sie läuft also schon “virtuell”. Die Parent Partition vertraut den Gästen natürlich nicht – nur so kann verhindert werden, daß über interne Schnittstellen Schadcode in die Parent-Partition geschleust wird. Außerdem müssen die normalen Netzwerkfunktionen zum Datenaustausch genutzt werden, es gibt keine Möglichkeiten der Interaktion wie in Virtual PC.

Zur Delegierung von Benutzerrechten auf die VMs (also etwa die Berechtigung eine konkrete VM neu zu starten oder aber Konfigurationsänderungen durchzuführen), wird der Authorization Manager (AzMan) verwendet. Der Schutz vor physischem Zugriff (etwa in Zweigstellen) kann durch Bitlocker gewährleistet werden; Bitlocker schützt neben den Daten der HDD auch den Bootcode. Am Thema Bitlocker kommt man scheinbar bei kaum einem Bereich mehr vorbei. ;-)

AV-Applikationen können neben der Installation eines Agents in der VM selbst auch offline VHDs scannen – ein Beispiel hierfür wäre etwa McAfee; der Hersteller bietet ein solches Modul in seiner Produktpalette an. Es ist somit möglich den Inhalt einer VHD zu prüfen, ohne die Maschine zu starten. Auf dem Hostsystem sollten vom AV-Scanner die Dateien “vmms.exe”, "vmwp.exe" und “vmswp.exe” ausgenommen werden, da sonst die Performance des Hyper-V Systems stark sinken kann.

Nach diesen Themenbereichen wurden einige Hinweise zur Verwendung von dynamischen VHDs, fixed VHDs und Differenz-VHDs und deren Performance gegeben: Die Botschaft ist eindeutig – in Windows Server 2008 R2 haben massive Performanceschübe stattgefunden, die die VHDs fast mit “RAW-Disks” gleichziehen lassen, wobei die “fixed disk” immer noch am besten abschneidet (fast 100% so schnell wie RAW disks") und expandierende (dynamische) VHDs zwischen 10% – 15% Performanceinbußen hervorrufen können. Hier muß man also abwegen: Reservierter Speicherplatz gegen Leistungsfähigkeit. 10% klingt nicht viel, kann jedoch bei stark ausgelasteten Systemen eine echte Hausnummer sein.

Bei dem Thema Auslastung: http://www.microsoft.com wird auf Hyper-V Maschinen gehostet – bei ca. 1,2 Milliarden Zugriffen pro Monat zeigen wir also einmal mehr selbst großes Vertrauen in das Produkt. :-)

In Bezug auf die Perfomance spielen natürlich eine Menge Faktoren eine Rolle – man sollte etwa die NIC-Ausstattung gut planen und für das Management des Hosts, ggf. iSCSI Verbindungen etc. jeweils eine NIC zur Verfügung stellen. Je nach Auslastung der VMs kann dann eine oder mehrere NICs pro VM oder aber “shared physical” NICs verwendet werden. Hier muß gut geplant sein, was über die Leitung geht. HDD-Performance (wie viele Spindeln hat das RAID-Set etc.), ausreichend RAM und CPU-Power setze ich hier einfach einmal voraus. Die Flaschenhälse rechtzeitig zu identifizieren spart eine Menge Geld, denn hier sollte man die Konfiguration prüfen anstatt gleich neue Hardware zu bestellen, die ja nicht nur in der Anschaffung Geld kostet, sondern auch im Betrieb.

In Bezug auf die Performance kamen auch noch weitere Hinweise, so zum Beispiel der Tipp, ISOs einzubinden anstatt CD / DVD Laufwerke des Hosts zu nutzen, falls möglich und getestet Jumbo Frames einzusetzen (hier muß die gesamte Netzwerkinfrastruktur mitspielen, also Router, Switches, Netzwerkkartentreiber etc.), für Windows Server 2003 Systeme 2-Wege Multiprozessor Systeme als Gast zu nutzen und – wer hätte das gedacht – in den VMs den Screensaver zu deaktivieren, denn sonst geht beim VGA Treiber eine Menge Rechenzeit für das Rendering des Bildschirmschoners drauf.

Zum Schluß war ich angenehm von dem Angebot überrascht, eine wirklich kostengünstige “Workgroup Edition” des SCVMM erwerben zu können: die System Center Virtual Machine Manager Workgroup Edition, womit bis zu 5 Hosts (unbegrenzt Gäste) verwaltet werden können – da der Windows Hyper-V Server 2008 R2 ja kostenfrei ist, läßt sich so also für wirklich wenig Geld (Preis / Leistung) eine kleine Hyper-V Struktur komplett verwaltet aufbauen. Wer den kostenfreien Hyper-V Server herunterladen möchte, schaut am besten hier.

Neben diversen anderen Themen wurde auch Windows Server Core 2008 R2 angesprochen, der nun (glücklicherweise) ein “Admin-freundliches” Tool mitbringt, den Server zu konfigurieren: SCONFIG.exe . Dazu fällt mir nur eine Beschreibung ein: Ein Segen für uns alle. ;-)

Die Features vom Windows Server 2008 R2 Hyper-V sind hier zusammengefaßt – Kurzform: Es ist eine Menge seit Windows Server 2008 Hyper-V passiert.

Viele Grüße
Fabian

TechEd Europe 2009: Tag 2

Hallo, Fabian hier. Der zweite Tag war recht vollgepackt mit Vorträgen, alle Sessions waren sehr interessant.

How Windows Storage Is Changing: Everything's Going VHD!

Sprecher war Mark Minasi: http://www.minasi.com/

Um es Vorweg zu sagen: Mark Minasi ist der aus meiner Perspektive bisher beste Sprecher auf der TechEd dieses Jahr. Das heißt nicht, daß die anderen Speaker nicht auch super waren / sind; aber wer einmal das Glück hat in einen Vortrag / ein Training von ihm zu kommen, sollte das wahrnehmen. Fachlich absolut sattelfest und vom Vortragsstil her genial und witzig. Es mangelt weder an Rollenspielen (etwa Router vs. Client) noch an vollem Körpereinsatz. ;-)

Die gute Performance von ihm hat mich dann am Dienstag dazu bewogen, zwei weitere Sessions von ihm anzuschauen (siehe unten), obwohl ich eigentlich andere Vorträge besuchen wollte.

Im Zentrum der Session standen die Änderungen bei “Windows Speichern” seit Vista, insbesondere jedoch Windows 7. Seit Vista wurde der Bootmanager (Stichwort boot.ini) durch die “Boot Configuration Database (BCD)” abgelöst, die mittels BCDEDIT bearbeitet werden kann. Nähere Informationen dazu finden sich etwa hier (kostenfreier Download): click here to download chapter 1

Seit Windows 7 liegt die Datenbank auf einer separaten (standardmäßig) 100MB großen Partition und nicht mehr auf “C:”. Auf diesem Volume können nun auch Bitlocker Daten oder etwa Recovery Environment Daten abgelegt werden, das 1,5GB Volume ist für Bitlocker seit Windows 7 also nicht mehr notwendig. Das Volume ohne Laufwerkszuordnung ist dementsprechend ein “Multitalent”. Durch diese Trennung der Datenbank vom System ist nun theoretisch auch der Bootvorgang direkt von einer VHD möglich, was jedoch derzeit nicht supported ist. Hier gab es aber eine ausführliche DEMO, wie man eine VHD a) als zusätzlichen Datenträger einbinden kann (Multiboot-Environment) oder b) auch als primäres Boot-Device einrichten kann (derzeit nicht supported, siehe oben). Hierzu muß zur Einrichtung DISKPART verwendet werden.

Möchte man ein OS in eine neu erstellte VHD übertragen, so kann dafür etwa “ImageX” der Winndows Deployment Tools genutzt werden, wenn man zuvor das System mittels SYSPREP vorbereitet hat. Die Vorgang der Übertragung in eine VHD ist eigentlich erst seit Windows 7 vorgesehen, unter Vista sollte es jedoch auch funktionieren. Testen macht schlau. ;-)

Das Windows Complete Backup erzeugt ebenfalls VHDs, die jedoch nicht dafür gedacht sind, sie in eine VM einzubinden – eher dient die VHD als Containerformat. Mit dem Complete Backup Fetaure ist sogar ein “Bare Metal Restore” möglich, wenn etwa auf der Kommandozeile mittels “wbadmin” die Option “-allcritical” verwendet wird.

Stichwort “Containerformat”: Die VHDs lassen sich nicht nur als HDD-Container nutzen, sondern können auch zur Datenübertragung genutzt werden. Im Gegensatz zu ISOs oder ZIP-Dateien werden darin natürlich auch die NTFS-ACLs übertragen, so daß man theoretisch diese ACLs auf dem Zielsystem nutzen kann und diese beim “Transport” nicht verloren gehen. Das Einbinden der VHD ist seit Windows 7 so einfach wie irgend möglich (über die Datenträgerverwaltung beispielsweise), so daß das Vorgehen kein Problem mehr darstellen sollte.

Wen das Thema insgesamt interessiert, der schaut einfach direkt bei Mark Minasi vorbei, dort stehen einige Newsletter zu den Themen bereit, etwa: http://www.minasi.com/newsletters/nws0701.htm und http://www.minasi.com/newsletters/nws0702.htm .

Windows BitLocker in the Enterprise

Speaker: Paul Cooke

Diese Bitlocker Session war sehr interessant, technisch als auch von den Überlegungen zum Deployment. Auch wurde mit Themen aufgeräumt wie: Bitlocker ist nicht so sicher wie Produkt XY, weil a) als Boot-Loader ein unverschlüsselter Bereich vorliegt (das ist nämlich zwangsweise bei jedem Produkt so, nur verstecken es andere Anbieter vor neugierigen Blicken) und b) im Schlafmodus oder Hybernate der Bitlocker Schlüssel im Speicher bleibt – Bitlocker ist nicht designed, Schutz in einer solchen Konstellation zu liefern, es stehen andere Szenarien im Vordergrund. Wer das verhindern möchte, deaktiviert im Notfall den Schlafmodus seiner Geräte.

Die Bitlocker Daten werden (siehe letzte Session oben) seit Windows 7 in einer 100MB Partition untergebracht – dies sollte beim Deployment bedacht werden – denn nur bei “from scratch” Installationen wird die Partition automatisch eingerichtet. Nutzt man etwa WDS zur Verteilung von Windows 7, muß man die Partitionierung selbst vornehmen. Macht man es nicht, kann es beim Ausrollen von Bitlocker im Unternehmen diverse Probleme geben oder mindestens die Benutzer zu mehrmaligen Neustarts des Rechners nötigen – nicht gut für die IT-Akzeptanz im Unternehmen.

Seit Windows 7 gibt es nun ähnlich wie bei EFS einen “Data Recovery Agent”, den man optional einrichten kann. So müssen nicht mehr alle Recovery Schlüssel in das AD-Computerobjekt geschrieben werden (und sind auch nicht verloren, wenn man das Computerkonto einmal löscht), sondern man kann mit dem privaten Schlüssel wieder an “verlorene” Daten herankommen.

Bitlocker to go macht es möglich, auch USB-Sticks und ähnliche Wechseldatenträger zu verschlüsseln. Diese können dann unter Windows 7 oder mit einem “builtin” Tool “read only” von XP und Vista gelesen werden. Für letzteres ist eine FAT Formatierung des Datenträgers notwendig. Man kann per Gruppenrichtlinie erzwingen, daß keine Daten auf unverschlüsselte Datenträger übertragen werden und es kann verhindert werden, daß Daten auf Datenträger fremder Organisationen kopiert werden.

Best Practice Empfehlungen für Bitlocker:

• Einsatz standardisierter Hardware (etwa TPM Chip vorhanden u.ä.)
• Pre-Build Hardware Konfiguration (HDD Partitionierung, BIOS Einstellungen und Kennwort, TPM aktiviert, etc.), also im Prinzip eigene OEM Systeme
• Rollout der Systeme, bevor die Benutzer damit in Berührung kommen, so daß ggf. maximal nur ein Reboot bei Bitlocker Einrichtung notwendig wird und nicht 4 oder 5.
• getestete (!) Recovery Strategie (!)
• Die meisten GPO-Einstellungen müssen vor der Aktivierung von Bitlocker aktiv sein, so zum Beispiel Verschlüsselungsalgorithmus u.v.m.

Seit Schema Version 2008 bzw. später (2008 R2) sind alle Attribute / Schema Änderungen mit dabei – somit entfällt ein Schema-Upgrade bzw. eine Änderung für Bitlocker, die noch unter Windows Server 2003 SP1 notwendig war. Zusätzlich unterstützt nun Windows PE (auf W7 Basis) und das Recovery Environment auch nativ Bitlocker.

Die Windows 7 integrierte “BDE.exe” ermöglicht es viele Schritte des Rollouts zu automatisieren, ansonsten gibt es ein Beispielscript namens “Manage-BDE.wsf”. SCCM 2007 ist übrigens ebenfalls “Bitlocker aware”.

IPv6 for the Reluctant: What to Know Before You Turn It Off

Dies war eine der Session, die ich “nur” wegen dem Sprecher Mark Minasi besucht habe. Da die Session streckenweise sehr spezifische IPv6 Themen behandelt hat, ist eine Zusammenfassung recht schwierig. Wen das Thema IPv6 interessiert (und die Quintessenz des Beitrags war: Es sollte jeden “interessieren”), der findet im Netz dazu als auch in diversen Büchern wertvolle Informationen zum Einstieg.

Nach einem kurzen Ausflug in die Geschichte war klar: 1994 hatte sich kaum jemand über den verfügbaren Adressraum von IPv4 Gedanken gemacht. Doch dann brach das Internet über die Massen an Benutzern herein, so daß schon 1995 der Adressraum knapp wurde. Da aus diversen Gründen nicht so schnell auf IPv6 umgestellt werden konnte, wurde die “Krücke” Network Address Translation (NAT) per RFC definiert – eine Technik, die so manchem Netzwerkadmin heute die Tränen in die Augen treibt.

Mark Minasi stellte die Vermutung auf, daß so ein “Knall” wieder bevorsteht und dann in kürzester Zeit auf IPv6 umgestellt werden muß und wird. Den Zeitrahmen dafür vermutet er bis 2011 / 2012, was durch folgende Webseite auch eindrucksvoll hochgerechnet wird: http://www.potaroo.net/tools/ipv4/index.html

Sein Fazit: Sichert Eure Jobs, indem Ihr den Migrationsplan in der Tasche habt bzw. die Planung langfristig angeht…

China wurde außerdem als Beispiel genannt, da hier das Chinese “New Generation Network (NGN)” direkt auf IPv6 laufen wird. Nicht ohne Grund, wenn man sich den (nachvollziehbar) wachsenden Adressbedarf in China anschaut. Auch europäische Autobauer (und sicher auch die Autobauer anderer Länder, wie z.B. Japan) setzen zunehmend auf IPv6 für die internen Netzwerke in den Autos – ein prominentes Beispiel, warum diese Anforderung existiert, ist die kabellose car-to-car  bzw. car-to-x communication, bei dem sich beispielsweise gegenseitig über Staus und Gefahrenstellen informiert wird. Hier ist der Einsatz von IPv6 sinnvoll (wenn nicht zwingend notwendig, sollte das Internet Protocol “IP” verwendet werden).

Seit Windows Vista ist nun der TCP/IP Stack komplett auf IPv6 umgestellt – selbst wenn man das Protokoll “deaktiviert”, wird intern immer noch die Umsetzung stattfinden. Dies ist eine fundamentale Änderung.

Dann ging es direkt zum technischen Teil über: Die Vorteile von IPv6 wurden zusammengefasst, etwa daß keine Broadcasts mehr eingesetzt werden (wohl aber Multicasts), das Routing unproblematischer werden wird (kein NAT mehr notwendig), theoretisch kein DHCP mehr notwendig sein wird (mehr dazu weiter unten) usw.

Nachdem dann noch ein wenig IPv6 Theorie besprochen wurde (ganz grob zusammengefaßt):

• was ist unter “link” zu verstehen; im Prinzip ein Subnetz in IPv4
• wie sehen IPv6 Adressen aus; also 8x hex quads (8x hexadezimale Vierergruppen, die durch Doppelpunkte getrennt sind)
• wie kann man die Schreibweise von IPv6 Adressen verkürzen, indem man aufeinander folgende “Nullen” verkürzt: 21FB:540A:0000:0000:0000:0000:0000:0000 wird zu 21FB:540A::
• “Subnetze” werden nicht mehr in der Schreibweise 255.0.0.0 eingesetzt, sondern über “Prefixe” abgebildet; zum Beispiel 21FB:540A:0000::/48 bedeutet, daß die ersten 48-Bit den “Netzwerkanteil” ausmachen, jedes Zeichen hat 4 Bit (0-15 dezimal, also 0-F hexadezimal), daher gibt es 48/4 = 12 Zeichen, wobei die 4 Nullen im Beispiel natürlich auch gekürzt werden könnten und nur zur besseren Verständlichkeit stehen blieben
• FE80::/64 Adressen sind im Prinzip gleich den IPv4 APIPA Adressen
• was sind Unicast, Multicast und Anycast Adressen usw.

kam man schnell zu dem Punkt zu verstehen, daß das “Wegwerfen” und “Verschwenden” von ungenutzten IP-Adressen unter IPv6 “by design” ist und mit dem aktuellen maximal möglichen Adressraum überhaupt kein Problem darstellt. Dabei werden mehrere IP-Adressen pro Interface betrieben – ganz normal und nicht so “ungewöhnlich” / problembehaftet wie bei IPv4.

Zusätzlich gab es auch einen Ausflug zum Thema Datenschutz: In den ersten Entwürfen der IPv6 Implementierung wurde der Host-Anteil (besser: 32-Bit davon) aus der MAC-Adresse der NIC gebildet und der Rest “aufgefüllt” – wenn jedoch die Adresse im Internet (ohne NAT) geroutet wird, wäre dies ein eindeutiger Bezeichner und ein Tracking von Clients wäre möglich geworden. Keine schöne Vorstellung. Daher wurde dieser RFC-Standard geändert / verworfen und der Host-Anteil (bzw. die Global Unicast Adresse des Interfaces) zufällig gebildet. Bei der Gelegenheit wurde auch eingeworfen, daß die 32-Bit MAC sowieso nicht ausgereicht hätte (für den zu füllenden 64-Bit Anteil der IPv6-Adresse) und daher so oder so auf MAC-64-Bit umgestellt werden soll. Derzeit geschätzt reichen diese eindeutigen 32-Bit Adressen geschätzt nämlich “nur noch” bis ins Jahr 2100…

Wie angesprochen ändert sich die Rolle von DHCP ein wenig, denn rein theoretisch reichen die automatisch bezogenen IPv6-Adressen der Clients link-local als auch site-local bzw. global aus. Doch DHCP hat natürlich trotzdem seine Daseinsberechtigung, denn neben “festen” (also an bestimmte Systeme gebundenen) IP-Adressen können darüber ja auch andere Informationen verteilt werden, so etwa DNS-Suffixe, Router-Informationen etc.

NetBIOS bzw. WINS existiert in der Form unter IPv6 nicht mehr und DNS-Einträge für IPv6 Adressen werden als Quad-A Records “AAAA” registriert. Teredo (6to4) paßte nicht mehr ins Programm, da es ein “abendfüllendes” Thema wäre.

Yes SIR! Understanding the Microsoft Security Intelligence Report (SIR) v7

Als nächstes landete ich im Vortrag von Vinny Gullotto zum Security Intelligence Report (SIR), der sich als interessanter herausstellte, als mich der Titel zuerst vermuten ließ. Der Report ist sehr umfangreich, daher konnten in der Session nur einige Kernpunkte angesprochen werden.

Was mich stark beeindruckte war, wie viele Daten anonymisiert akkumuliert werden, um Trends und Statistiken zu erarbeiten. An vielen Stellen unserer Produkte macht eine solche Auswertung auf Malware / Attacken etc. Sinn, denn so lassen sich recht früh Ausbrüche neuartiger Schädlinge feststellen und bekämpfen. Außerdem erleichtert es (neben dem Engineering) die Heuristik natürlich ungemein, wenn man einen Pool von Daten hat, wie sich ein Schädling verhalten kann. Daten, die zur Auswertung herangezogen werden, sind zum Beispiel

• direkte Meldungen durch Kunden
• Analyse der in Hotmail gefilterten Malware
• Live One Care
• Forefront Client Security
• Windows Defender
• IE Phishing Filter
• MSRT
• Bing (Analyse von Schädlingen, die über Webseiten verbreitet werden)
• Zusammenarbeit mit anderen Anti-Malware Software Herstellern

Wenn man diese Daten von meheren Millionen Systemen weltweit zusammenfaßt wird schnell klar, welches mächtige Werkzeug zur Malware-Bekämpfung man damit an der Hand hat.

Um gleich Verschwörungstheorien entgegenzuwirken: Die Auswertung der Daten erfolgt erstens Anonym, zweitens müssen unsere Kunden der Auswertung zustimmen, d.h. die Datenübertragung findet nicht automatisch statt.

In Enterprise Umgebungen finden sich laut Report eher Würmer, auf Privatrechnern eher Trojaner. Hier zeigt sich also, wie zielgenau die Schadsoftware verbreitet wird, um maximale “Erfolge” zu erzielen. So werden privat natürlich eher Bankdaten etc. abgezogen, während in Unternehmen schlichtweg “Rechenkapazitäten” und Bandbreite für Massenversendungen von SPAM etc. zur Verfügung steht.

Leider ist einmal mehr der Mensch selbst in vielerlei Hinsicht ein entscheidender Faktor für den Erfolg von Malware: So ist das Bewußtsein für das massive Vorhandensein von Malware noch immer sehr gering (stündlich werden 15 neue Viren, Würmer, Trojaner etc. inkl. neuer Varianten entdeckt), außerdem finden leider Updates viel zu selten statt. Hier spielt nicht nur die Microsoft Update Seite eine große Rolle, vielmehr müssen alle Applikationen auf den Systemen aktuell gehalten werden. Und genau das passiert in den seltensten Fällen ausreichend – die Verteilung von ausgenutzten Browser-basierten Schwachstellen auf Microsoft Produkte und Third-Party Software in Windows XP und insbesondere Vista veranschaulicht dies in beeindruckender Art und Weise (man beachte dabei auch den Unterschied zwischen XP und Vista):

Wenn dann auch noch Security Hotfixes über Jahre zur Verfügung stehen und trotzdem noch ausgenutzt werden (weil nicht installiert), muß einen das bedenklich stimmen. Ein gutes Beispiel war “Conficker”, der eine Lücke nutzte, gegen die der entsprechende Hotfix vor Erscheinen des Wurmes schon 3 Monate (!) zur Verfügung stand…

Im Vortrag wurde daher mehr als einmal der Kernsatz der Session ausgesprochen: Update, update, update! Und das gilt explizit eben nicht nur für Microsoft Produkte.

Ein Blick in den Report lohnt sich auf alle Fälle, wenn man neben den angesprochenen Themen auch einmal sehen möchte, wie Malware länderspezifisch aufzuschlüsseln ist o.ä.: http://www.microsoft.com/sir

Cracking Open Kerberos: Understanding How Active Directory Knows Who You Are

Die letzte Session meines zweiten Tages gehörte dann wieder Mark Minasi.

Zu Beginn merkte Mark Minasi an, daß die Session Level 400 hat – und das stimmte auch. Daher auch hier wieder der Hinweis, daß nur Auszüge der geballten technischen Ladung wiedergegeben werden können.

Gleich zu Beginn unterschied er zwischen Authentifizierung und Autorisierung – was auch unserer Erfahrung nach allzu oft in Vergessenheit gerät. Kerberos stellt als zentraler Bestandteil der Active Directory die Authentifizierung bereit, nicht die Autorisierung. Es folgte die Erklärung von User Principal Names (UPN) und Service Principal Names (SPN). Kerberos sorgt (ein wenig verallgemeinert) dafür, daß ein Service Ticket für einen konkreten Service auf einem Server (SPN) an einen Benutzer (UPN) ausgestellt wird. Hierbei spielen der Authentication Service (AS) und Ticket Granting Service (TGS) die entscheidende Rolle – beides realisiert durch das Key Distribution Center (KDC), also einem Domaincontroller, im Kontext des LSASS Prozesses.

Es gibt zwei Sorten von Tickets: Ein Ticket Granting Ticket (TGT) und ein Service Ticket (ST). Um in den Genuß eines Service Tickets zu kommen, muß man ein entsprechendes TGT besitzen, welches zum Erhalt dieses ST “berechtigt”. Hier spielen dann Faktoren wie Computer und Benutzerkennwörter eine Rolle, die zum Verschlüsseln von “Secrets” (der aktuellen Systemzeit) genutzt werden, um den gegenüber auch korrekt zu identifizieren bzw. sicherzustellen, daß es wirklich der richtige Partner ist, der er vorgibt zu sein. An dieser Stelle kommt dann auch die “berühmte” 5 Minuten maximale Zeitdifferenz auf Kerberos Systemen ins Spiel, denn das ist standardmäßig die maximale Zeitdifferenz, die die verschlüsselte Systemzeit auf DC und Client haben darf. Hier gab es ausführliche Erläuterungen zur Funktionsweise.

Wer das ganze besser verstehen möchte, dem sei folgender Artikel ans Herz gelegt: http://technet.microsoft.com/en-us/library/bb742516.aspx

Diese Trennung von TGT und ST stellt sicher, daß das verschlüsselte Kennwort nur sehr selten (standardmäßig 10 Stunden) über die Leitung geht, da das TGT diese Zeit über gültig bleibt und nicht neu ausgestellt werden muß. Damit weist sich dann ein Benutzer beim DC aus, sobald er ein Service Ticket beantragt – und beweist damit, daß er schon korrekt authentifiziert wurde. Außerdem muß das Kennwort nicht an die Server gesendet werden, auf die zugegriffen wird (mittels Service Ticket). Der KDC / DC ist hier also unter anderem die zentrale Instanz einer AD-Umgebung, die Client und Server miteinander “verbindet”. Daher auch der Name “Kerberos”, der in der griechischen Mythologie ein dreiköpfiges Wesen ist.

An dieser Stelle gab es dann auch noch Hinweise zur Verschlüsselung von Kerberos Paketen, insbesondere zu den Änderungen in Windows Server 2008 und später.

In der verbleibenden Zeit wurde dann einges angesprochen, was beim Kerberos Troubleshooting von Bedeutung ist. Alle angesprochenen Punkte muß man an dieser Stelle gesondert hervorheben, denn die Punkte stellen einen Großteil der Themen dar, die wir hier mit unseren Kunden bei Kerberos Problemen verschiedener Art immer wieder behandeln.

Untersucht man Kerberos Probleme, macht ein Netzwerktrace immer Sinn. So kann man darin etwa nach Kerberos Fehlern suchen (NetMon Filter “KRBERROR”) oder auch komplette Kerberos Vorgänge zwischen Client, Zielserver und DC tracen. Hauptsächlich sind die folgenden Punkte dabei als Fehlerursache zu finden:

• DNS
• DNS
• DNS
• Time Service Probleme, also nicht übereinstimmende Zeiten auf Client und DC
• 3 Tier Authentication Probleme – also etwa Client zu IIS zu SQL Server – hier muß nämlich eine Delegierung eingerichtet sein und die SPNs korrekt gesetzt sein
• UDP Pakete kommen nicht an, läßt sich durch Aktivieren von Kerberos über TCP beheben, was seit Vista / 2008 auch Standardeinstellung ist

Der erste Blick bei Kerberos Problemen sollte neben Netzwerktraces immer auch ins Eventlog gehen – hier läßt sich das “Debug Level” auch hochdrehen – obwohl man dann natürlich genau wissen sollte, wonach man sucht… Zu diesem Thema gibt es auch ein Whitepaper von uns.

Es sollte zusätzlich sichergestellt sein, daß tatsächlich Kerberos genutzt wird und nicht NTLM – auch ein nicht zu unterschätzendes Problem bei fehlerhafter Konfiguration oder Umgebungen mit “Legacy Systemen”. Beispiele für mögliche Ursachen dafür sind:

• NET USE auf IP-Adressen anstatt DNS-Servernamen
• Workgroup Systeme, nicht eben nicht Teil der AD sind
• Pre-Windows 2000 Systeme bzw. nicht Kerberos-fähige Third-Party Dienste
• failover von ausgelasteten DCs
• “schlecht programmierte” eigene Applikationen
• die eigene Intranet Seite wurde nicht der “local intranet” Zone des Internet Explorers zugewiesen und per DNS-Namen auf den IIS zugegriffen
• fehlende, doppelte oder fehlerhafte SPNs

Ab Windows Server 2008 R2 / Windows 7 kann man NTLM auch komplett blocken, was man jedoch immer erst im “Audit” Modus prüfen sollte!

Weitere Probleme sind etwa die MaxTokenSize, fehlerhaft konfigurierte constrained delegation oder die schon angesprochenen fehlerhaften SPNs. Hier kann das Script spn_query.vbs wertvolle Hinweise geben.

Die Managed Service Accounts ab Windows 7 / Windows Server 2008 R2 können hier Hilfestellung geben, da die SPNs etwa beim Umbenennen eines Servers automatisch angepaßt werden.

Alles in allem eine der “technischsten” Session des Tages, die mir persönlich sehr gut gefallen hat.

Viele Grüße
Fabian

TechEd Europe 2009: Tag 1

Hallo zusammen, Fabian schreibt. Diesmal mit einem etwas anderen Thema – nämlich einer Zusammenfassung meiner Sessions auf der TechEd Europe 2009 in Berlin. So wird in den nächsten Tagen jeweils ein Blog pro Tag entstehen, der einen groben Überblick über einige Themen gibt.

Da das ganze natürlich nur limitiert möglich ist, folgender Disclaimer:

• Pro “Zeiteinheit” (also etwa von 09:00 Uhr bis 10:15 Uhr) werden auf der TechEd ca. 15 verschiedene Sessions diverser Themengebiete angeboten. Da eine Person gleichzeitig nur an einer Session teilnehmen kann, kann der Ausschnitt auch nur diese besuchte Session widerspiegeln (und damit nur einen kleinen Ausschnitt aus dem Gesamtangebot).
• Die aufgeführten Themen sind weiterhin nur ein kleiner Ausschnitt aus dem, was in den Sessions angesprochen wurde. So kann man hier keine 75 Minuten auf wenige Zeilen zusammenfassen – und das soll auch nicht der Anspruch sein. Vielmehr geht es darum einen kleinen thematischen Überblick zu vermitteln für all diejenigen, die entweder nicht auf der TechEd sein konnten oder aber noch nie da waren.
• Da die Stichpunkte wie angesprochen nur einen kleinen Ausschnitt darstellen, beleuchten sie die jeweiligen Themengebiete natürlich auch nicht vollständig. Daher werden einige Links angefügt, die man bei Interesse durchforsten kann, um mehr Informationen dazu zu erhalten.
• Die angesprochenen Punkte werden “wertungsfrei” wiedergegeben – Sinn soll es sein, den Tenor des Vortragenden beizubehalten und keine fachliche Anpassung vorzunehmen bzw. die Themen zu verändern.
• Solltet Ihr für die verbleibenden 3 Tage Hinweise oder gewünschte Informationen haben – nutzt die Kommentarfunktion. Natürlich ist dieses Angebot sehr beschränkt – ich werde mich kaum in eine SQL-Developer Session setzen (zumal die Zusammenfassung dann sicher auch keinen Sinn machen würde ;-) …) – aber vielleicht gibt es ja das ein oder andere, was Ihr Euch für die “Berichte” wünscht. Wenn es sich einrichten läßt, dann wird es eingebaut.
• Es wird etwas “Verzögerung” geben, der Blog des jeweiligen Tages wird nicht am Tag der Sessions veröffentlicht werden. Schließlich möchte ich auch etwas von den Sessions mitbekommen bzw. ein wenig in der Nacht schlafen und nicht nur bloggen. ;-)

Also, soweit die einleitenden Worte, nun soll es mit Tag 1 (Montag, 09.11.2009) losgehen…

Session 1

Geplant stand bei mir die Session “Virtualisation 360: Microsoft Virtualisation Strategy, Products, and   Solutions for the New Economy” auf dem Programm, Beginn 09:00 Uhr. Leider hatte ich die Rechnung ohne die Berliner S-Bahn gemacht (die Züge sind immer noch brechend voll und Züge fallen regelmäßig aus oder kommen zu spät) und kam daher erst ca. 08:30 Uhr an.

Scheinbar kamen geschätzte 5.000 der insgesamt ca. 7.100 Teilnehmer ebenfalls genau um diese Uhrzeit an, so daß die Vorhalle des ICC einem “Menschenmeer” glich, die sich alle gleichzeitig registrieren wollten:

Zum Glück konnte man als “Staff” einen gesonderten Check-In Schalter nutzen, der das ganze Prozedere in 15 Minuten erledigte. Nur leider war danach die o.g. Session schon komplett bis auf den letzten Platz ausgebucht, so daß ich wieder abzog, zu einem kurzen Frühstück und “Hallo” bei Kollegen. Sicher wäre eine andere Session der 14 verbliebenen auch noch interessant gewesen, aber der Tee und das Croissant war auch in Ordnung. ;-)

Useful Hacker Techniques: Which Part of Hackers' Knowledge Will Help You in Efficient IT Administration?

Nun ging es zur ersten Session, vorgetragen von Paulina Januszkiewicz:

Kern des Vortrags war, daß man die Techniken von “Hackern” kennen sollte – oder besser gesagt selbst “hacken” muß, um potentielle Sicherheitslücken zu identifizieren. Dabei wurde direkt mit dem "Vorurteil “Hacker = böser Mensch” aufgeräumt, denn im Grunde ist ein Hacker jemand, der uns an unsere Pflichten zur Sicherung unserer Systemlandschaften erinnert und nicht unbedingt auch schlechtes im Schilde führen muß (Black Hat vs. White Hat). Durch Penetrationstests wird die eigene Umgebung ggf. sicherer als auch Produkte verbessert.

Jede Information ist bei einem solchen Selbsttest wertvoll – denn unter Umständen hat man Systeme gar nicht auf dem Schirm, die man betreuen sollte (etwa weil man neu in der Firma ist oder aber weil andere Abteilungen mit der Systembetreuung eigenständig sind etc.). Ein simples

C:\> nslookup
> set type=all
> domain.tld

abgesetzt auf die eigene Domäne kann hier schon eine Menge Informationen ausgeben – auch welche, mit denen man nicht gerechnet hätte. So wurde live ein Beispiel eines Blumenlieferanten vorgeführt, der schlichtweg durch falsche DNS-Serverkonfiguration (Stichwort Zonentransfer) die gesamte interne DNS-Landschaft inkl. 192.168.x.x Adressen freigegeben hatte. Folgt dann ein

> ls –d domain.tld

lassen sich all diese Informationen auslesen.

Ein Blick auf die “Database Search” von http://ripe.net/ kann hier ebenfalls wertvolle Informationen über sein eigenes Unternehmen und dessen IP-Adressblöcke und Systeme liefern. Danach kann man prüfen, wie weit man in seine IT-Systeme / Netzwerke mit diesen Informationen eintauchen kann. NMAP und Konsorten können hier mit wenig Aufwand schon einen Überblick vermitteln, welche Dienste erreichbar sind etc.

Recht “gruselig” war die Demonstration, wie viele Drucker nach außen hin (etwa per HTTP oder IPP / Internet Printing Protocol) erreichbar sind. Daß man nun “schlechte Scherze” mit diesen Druckern machen kann (etwa direkt drucken), ist dabei das geringste Problem. Man denke nur daran, daß in den Web-Oberflächen streckenweise auch Informationen zu Dokumentennamen etc. sichtbar sind. Autsch! Also – hier sollte man seine Umgebung prüfen, bevor es ein Angreifer tut.

Ist der “offline Zugriff” auf ein System möglich, wird es haarig – hier können Passwortcracker etc. angesetzt werden, sicherheitsrelevante Dienste mit Boardmitteln (etwa WinPE) deaktiviert werden usw. Das ist nichts neues, jedoch kann es einmal mehr als Aufforderung gesehen werden, den offline Zugriff auf Systeme zu verhindern, etwa mittels Festplattenverschlüsselung.

In diesem Zusammenhang ist indirekt auch wichtig, nicht nur den Datenspeicher zu sichern, sondern auch den Datentransfer. Was nützt die Verschlüsselung von Daten / Dateien auf der Festplatte, wenn die Daten dann per E-Mail oder USB-Stick unverschlüsselt transportiert werden. “Sicherheit” ist eben keine Einzelmaßnahme, sondern eine Sammlung von vielen Maßnahmen und ein langwieriger, niemals stillstehender Prozess.

Ein “Hacker” kann unter anderem versuchen, ein durch einen Hotfix adressiertes Problem “rückwärts” auf eine Komponente herunterzubrechen, um etwa Sicherheitslücken auszunutzen. Dazu nutzt er dabei auch Boardmittel, wie etwa “expand.exe”, um Hotfixes zu entpacken und die Inhalte (etwa Manifest Dateien) auszulesen. Warum ist das für einen Administrator ebenfalls wichtig? Ganz klar - er kann zum Beispiel prüfen, welche Registrierungsschlüssel und Dateien bei der Installation bearbeitet werden, um so zu prüfen, ob die Hotfixes korrekt installiert wurden, ob Manipulationen in seiner Umgebung durchgeführt wurden o.ä.

Eigene Tests kann man problemlos per Script realisieren – Perl oder PowerShell sind hier beispielsweise eine gute Wahl. So läßt sich etwa zyklisch prüfen, ob Dienste außerhalb des %SYSTEMROOT%\Windows Verzeichnisses installiert wurden – denn dort kann eine nicht so restriktive ACL eingesetzt sein. Das passiert in der Praxis gerade bei Eigenentwicklungen leider viel zu oft. Es sollte ein Toolset und eine Scriptsammlung bei jedem Admin entstehen, mit dem automatisiert und regelmäßig verschiedene Tests gegen die eigene Umgebung gefahren werden – nur so läßt sich ein Mindestmaß an “Sicherheit” erreichen.

What's Windows Server 2008 R2 Going to Do for Your Active Directory?

Sprecher war John Craddock:

Die Session war vollständig “ausgebucht” – ca. 700 Teilnehmer waren in dem Vortrag. Hier zeigt sich einmal mehr, welche zentrale Bedeutung die Active Directory in Unternehmen besitzt.

Im groben ging es bei der Session um die neuen AD Features, als da wären:

• das AD PowerShell Module; hierfür werden die AD Web Services benötigt, die auch auf einem Windows Server 2003 installiert werden können
• das AD Administrative Center, das nun aufgabenorientiert arbeitet; so läßt sich etwa die Suche mit unterschiedlichen Filterkriterien einfacher und übersichtlicher speichern und auswerten / verarbeiten; es sind nicht mehr so viele TABs für unterschiedliche Optionen auf AD-Objekten vorhanden, sondern alles recht übersichtlich in einem Interface zusammengefaßt etc.
  Das Administrative Center basiert übrigens auf der PowerShell – ein Grund mehr also, sich mit der PowerShell zu beschäftigen, diese wird in neuen Microsoft Produkten zunehmend als Basis eingesetzt werden.
• der AD Best Practice Analyzer, der wie schon andere BPAs einige bekannte Probleme oder Fallstricke anzeigt; dieser kann über die GUI oder aber über die PowerShell genutzt werden
• Managed Service Accounts, die über die PowerShell verwaltet werden sollten; da die Managed Service Accounts ein “$” am sAMAccountName angehangen haben, gelten Sie als “Computerkonten”, somit greift auch nicht die normale User Password Policy, sondern die der Computerkonten – hier bestimmt der Client, wann eine Änderung passiert, für Managed Service Accounts bestimmt dies das MSA-Management
  MSA können nur auf Windows 7 oder Windows Server 2008 R2 Maschinen eingesetzt werden, ein Account ist derzeit auf eine Maschine gebunden
• der Offline Domain Join, so daß über unbeaufsichtigte-Installationen und offline als auch online VHDs eine komplette Automatisierung des Deployments auch ohne Domänenverfügbarkeit gewährleistet werden kann
• die Authentication Mechanism Assurance, die es ermöglicht, anhand der Authentifizierungsmethode (etwa Passwort oder Smart Card) zu entscheiden, auf welche Ressource Zugriff gewährt wird; hierzu wird eine "”virtuelle” Universal Group in das Benutzertoken eingefügt, die den Logon Typen kennzeichnet
• der AD Recycle Bin

TechEd Europe Keynote - Welcome to the New Efficiency Keynote

Die Keynote umfaßte eine Menge Punkte, so etwa “cost savings”, Windows 7, Cloud Computing. Zusätzlich gab es eine Exchange 2010 Demo, bei der zugleich die Verfügbarkeit von Exchange 2010 RTM verkündet wurde. Intern bei Microsoft nutzen wir schon seit einiger Zeit Exchange 2010 + Outlook 2010 (seit dem Technical Preview, jetzt beta) und die neuen Features finde ich persönlich wirklich klasse. Beispiele dafür:

• “speech to text” bei Sprachnachrichten
• zentrales Rechtemanagement (etwa das Filtern oder RMS-schützen von E-Mails mit Schlüsselwörtern im Text, die extern versendet werden sollen)
• OWA integriert nun den Communicator und hat einiges an “rich client features” dazu bekommen (übrigens wurden Teile der Demos in Firefox durchgeführt, um die Kompatibilität zu alternativen Browsern aufzuzeigen)
• “live mailbox migration” ohne Unterbrechung der Mailbox-Nutzung
• bessere Übersicht / Benutzeroberfläche am Client, diverse Neuerungen
• “delegated management rights”, etwa das Delegieren der Suche nach gelöschten E-Mails der Kollegen durch einen Abteilungsmitarbeiter
• integrierte E-Mail Archivierung, was eine starke Kostenersparnis bedeuten kann

Weiterhin wurden neue Funktionen des System Center 2007 R2 angekündigt (inkl. Demo), die ebenfalls sehr vielversprechend aussahen (Softwareverteilung nutzt etwa “Brach Cache” und “Direct Access”, auf Basis der Auslastung lassen sich Maschinen in Betrieb nehmen oder herunterfahren, Stichwort Power Efficiency) u.v.m.

Ok, das war es fürs erste – bis später!

Viele Grüße
Fabian

Kerberos Encryption Types unter Windows 7 und Windows Server 2008 R2

Hallo zusammen, Fabian hier. Ab Windows 7 bzw. Windows Server 2008 R2 werden Kerberos Anfragen und Antworten standardmäßig nicht mehr mit DES (DES-CBC-MD5 & DES-CBC-CRC) verschlüsselt, da DES nicht mehr den Anforderungen an eine zeitgemäße Verschlüsselungsstufe genügt. Windows 7 bzw. 2008 R2 Systeme erzeugen standardmäßig nur noch AES und RC4 Anfragen bzw. Antworten.

Siehe dazu auch:
Changes in Kerberos Authentication http://technet.microsoft.com/en-us/library/dd560670(WS.10).aspx
und
961302 Vista and Windows Server 2008 clients are unable to access cluster names with AES-encrypted Kerberos tickets http://support.microsoft.com/default.aspx?scid=kb;EN-US;961302

Dies kann zu Problemen führen, wenn eine Applikation bzw. ein Dienst keine AES oder RC4 Verschlüsselung „spricht“, sondern nur Kerberos Pakete mit DES unterstützt. In diesem Fall bleibt in den Standardeinstellungen nur der Fallback auf NTLM oder aber die Authentifizierung scheitert. Grundsätzlich sollte also sichergestellt sein, daß die im Unternehmen eingesetzten Applikationen und Dienste AES-Kerberos-fähig sind, bevor das Deployment von Windows 7 Clients oder Windows Server 2008 R2 Systemen beginnt.

Für Windows Server 2003 DCs kann es ebenfalls sinnvoll sein, auf AES „umzuschalten“, siehe dazu:
Changes in default encryption type for Kerberos pre-authentication on Vista and Windows 7 clients cause security audit events 675 and 680 on Windows Server 2003 DC's
http://blogs.technet.com/instan/archive/2009/10/12/changes-in-default-encryption-type-for-kerberos-pre-authentication-on-vista-and-windows-7-clients-cause-security-audit-events-675-and-680-on-windows-server-2003-dc-s.aspx

Um festzustellen, welche Encryption Types von einem System angefordert werden, kann man entweder die Dokumentation bemühen, das Kerberos Logging hochdrehen oder aber einen Netzwerktrace ziehen. Hier ist ein einem Kerberos Request der „EType“, also der „Encryption Type“ entscheidend. Schlägt die Authentifizierung an einer Applikation / einem Dienst (etwa einem Web-Portal) fehl, äußert sich der fehlschlagende Request beispielsweise in einem Netzwerktrace wie folgt:

Kerberos Request (Ausschnitt):

Frame 1 {TCP:48, IPv4:47} <SRC IP> <DEST IP> KerberosV5 KerberosV5:TGS
Request Realm: CONTOSO.COM Sname: HTTP/<hostname>.<FQDN>

0.000000 {TCP:48, IPv4:47} <source IP> <destination IP> KerberosV5
KerberosV5:TGS Request Realm: <fqdn> Sname: HTTP/<hostname>.<fqdn> 

  - TgsReq: Kerberos TGS Request
   - KdcReq: KRB_TGS_REQ (12)
    - ReqBody: 
     - Etype: 
      + EType: aes256-cts-hmac-sha1-96 (18)
      + EType: aes128-cts-hmac-sha1-96 (17)
      + EType: rc4-hmac (23)
      + EType: rc4-hmac-exp (24)
      + EType: rc4 hmac old exp (0xff79)
      + TagA:
      + EncAuthorizationData:

Der Etype zeigt an, daß kein DES vom Client angeboten / angefragt wird, die Konsequenz daraus ist folgerichtig das Ablehnen des Requests durch das Web-Portal:

Frame 2 {TCP:48, IPv4:47} <DEST IP> <SRC IP> KerberosV5 KerberosV5:KRB_ERROR

- Kerberos: KRB_ERROR  - KDC_ERR_ETYPE_NOSUPP (14)
  - KrbError: KRB_ERROR (30)
  + ErrorCode: KDC_ERR_ETYPE_NOSUPP (14)

Der allererste Schritt bei der Windows 7 und Windows Server 2008 R2 Integration in einer Domänen-Umgebung sollte also sein, die AES Kompatibilität sicherzustellen, um ein entsprechendes Sicherheitsniveau zu erreichen. Ist dies jedoch aus verschiedenen Gründen nicht möglich, läßt sich das Standardverhalten von Windows 7 und Windows Server 2008 R2 Systemen auch verändern, um DES Verschlüsselung zuzulassen.

Hierzu existiert seit Windows 7 RSAT bzw. Windows Server 2008 R2 GPMC / GPEDIT eine neue Einstellung, die den Encryption Type zentral verwalten kann. Unter “Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options” wird die Einstellung “Network security: Configure encryption types allowed for Kerberos” zu Verfügung gestellt, in der man dann auch DES wieder aktivieren kann.

Ist diese Policy auf einem Windows 7 / 2008 R2 System aktiv, wird folgender Registry Schlüssel geschrieben:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
REG_DWORD: „supportedencryptiontypes“.

Wurden alle derzeit verfügbaren Verschlüsselungstypen in der GPO-Einstellung gesetzt (also alle Encryption Types + zukünftige ETypes aktiviert), ergibt sich daraus der Wert „0x7FFFFFFF“ als “supportedencryptiontypes” DWORD-Wert.

Der NETLOGON Dienst fragt dann bei einem DC (secure channel) die Änderung des folgenden Attributs des Client-Computerkontos im AD an: ms-DS-Supported-Encryption-Types http://msdn.microsoft.com/en-us/library/ms677827(VS.85).aspx . Dies passiert bei einem Neustart des Clients bzw. beim Start des NETLOGON-Dienstes oder zyklisch im Laufbetrieb. Als Attributwert des "msDS-SupportedEncryptionTypes" wird der Wert eingetragen, den der Client von der Policy übernommen hat, also in unserem Beispiel etwa „0x1F“ (hex) bzw. „31“ (dezimal), womit alle verfügbaren Encryption Types ausgewählt sind. Diesen Wert liest ein KDC aus, um die Verschlüsselung bei einer Ticket-Anfrage für das jeweilige Konto zu bestimmen.

Wie der Wert Zustande kommt, kann beispielsweise hier nachgelesen werden:

msDS-SupportedEncryptionTypes – Episode 1 - Computer accounts http://blogs.msdn.com/openspecification/archive/2009/09/12/msds-supportedencryptiontypes-episode-1-computer-accounts.aspx

An diesem Punkt ist es also wichtig, daß der vom NETLOGON Dienst angeforderte Schreibzugriff auf das Attribut „msDS-SupportedEncryptionTypes“ erfolgreich ist und der Wert auch korrekt auf den DCs repliziert wird, denn sonst wird der gewünschte Encryption Type zwar vom Client angefordert, der KDC stellt die Anforderung jedoch nicht aus. Er verwendet in diesem Szenario weiterhin die von ihm standardmäßig supporteten ETypes, so etwa bei Windows 7 / Windows Server 2008 R2 DCs AES. Die Authentifizierung würde nun trotz korrekter Group Policy Einstellung scheitern.

Je nach Szenario muß die Policy also für Windows 7 Clients oder aber auch für Windows Server 2008 R2 Member als auch 2008 R2 Domänencontroller aktiviert werden.

Nachdem die Policy am Client angekommen ist, fordert der Client in unserem Beispiel bei Kerberos Requests nun auch wieder DES Verschlüsselung an (Ausschnitt):

Frame 3 {TCP:48, IPv4:47} <SRC IP> <DEST IP> KerberosV5 KerberosV5:TGS
Request Realm: CONTOSO.COM Sname: HTTP/<hostname>.<FQDN>

0.000000 {TCP:48, IPv4:47} <source IP> <destination IP> KerberosV5
KerberosV5:TGS Request Realm: <fqdn> Sname: HTTP/<hostname>.<fqdn>

- TgsReq: Kerberos TGS Request
   - KdcReq: KRB_TGS_REQ (12)
    - ReqBody:
     - Etype: 
      + EType: aes256-cts-hmac-sha1-96 (18)
      + EType: aes128-cts-hmac-sha1-96 (17)
     + EType: des-cbc-md5 (3)
     + EType: des-cbc-crc (1)
     + EType: rc4-hmac (23)
     + EType: rc4-hmac-exp (24)
     + EType: rc4 hmac old exp (0xff79)
     + TagA:
     + EncAuthorizationData:

Wie angesprochen ist die Anpassung der Policy / des Encryption Types eher als „letzte Lösung“ zu betrachten, nicht als „Standardfall“. Es sollte besser geprüft werden, wie die Umgebung fit für AES-Kerberos-Verschlüsselung gemacht werden kann.

Viele Grüße
Fabian

Weil heute Dein Geburtstag ist... Windows 7 / Windows Server 2008 R2

Hi zusammen, Ihr alle wißt, daß heute Windows 7 in den Ladenregalen das Licht der Welt erblicken wird. Warum nur Ladenregale? Nun ja, die Versandhäuser scheinen ausverkauft zu sein. ;-) : http://www.engadget.com/2009/10/21/windows-7-breaks-amazon-uk-pre-order-volume-record-ousts-harry/

Viele von unseren Lesern haben Windows 7 sicherlich schon laufen, wie immer hatten Technet und MSDN Abonnenten die Nase vorn.
Also wollen wir hier keine großen "Marketingworte" verlieren, ich denke die Produkte Windows 7 und Windows Server 2008 R2 sprechen für sich. ;-)

Aber diese kurzen Spots wollten wir Euch dann doch nicht vorenthalten:

Viele Grüße
Fabian

PowerShell Pack

Hallo zusammen, Fabian hier. Mein Büro-Kollege Bernd machte mich gerade darauf aufmerksam, daß es seit kurzem ein “PowerShell Pack” für die PowerShell V2 von uns gibt, welches einige interessante CMDlets und Funktionen bietet, die man im Administrationsalltag sehr gut gebrauchen kann bzw. die einem das administrative Leben an einigen Stellen stark vereinfachen können.

Das Paket kann hier heruntergeladen werden: http://code.msdn.microsoft.com/PowerShellPack

Zusätzlich sind auf dieser PowerShell Pack Seite auch Hinweise zur Nutzung und ein Video zum Einsatz der PowerShell Pack “Windows Presentation Foundation” Funktionen zu finden.

Ein schneller Einstieg in die CMDlets auf einem System mit installierter Windows PowerShell V2 kann zum Beispiel wie folgt aussehen:

1. Herunterladen des *.msi Pakets und Installation desselben: Download
2. Importieren des PowerShell Pack Moduls:
   PS C:\> Import-Module PowerShellPack
3. Ausführen des folgenden PowerShell Kommandos, um einen Überblick über die verfügbaren CMDlet Funktionen zu bekommen:
   PS C:\> (Get-Module PowerShellPack).ExportedFunctions
4. Nutzen der neuen Funktionen. ;-)

Benötigt man Hilfe zu den neuen CMDlets / Funktionen, hilft ein “Get-Help <CMDlet> –full” weiter, also etwa
PS C:\> Get-Help New-Task –full

Viel Spaß damit und Gruß,
Fabian

Last Interactive Logon

Hallo zusammen – hier ist Florian, einer der deutschen MVPs aus den Microsoft Communities mit einem neuen Gastbeitrag (*). Diesmal erneut mit einem AD-Thema, das auch Gruppenrichtlinien ein wenig thematisiert.

Heute geht es um ein Feature, das Unix-Nutzer schon des Längeren kennen, Windows-Admins aber bislang in dieser Form verborgen blieb: die Anzeige der letzten interaktiven Anmeldeinformationen für Anwender. Das Feature kann ab Windows Vista und Windows Server 2008 (und natürlich auch mit den beiden kommenden Systemen Windows 7 und Windows Server 2008 R2) beim Upgrade der Active Directory-Domäne auf den „Windows Server 2008“-Domänenfunktionslevel eingesetzt werden und heißt: Last Interactive Logon (LIL).

Last Interactive Logon ermöglicht zwei Dinge:

1. Administratoren können nun endlich (exakt!) nachvollziehen, wann ein Benutzer zuletzt interaktiv an einem Client angemeldet wurde.
2. Der Benutzer kann bei seiner Anmeldung über seine letzte erfolgreiche interaktive Anmeldung informiert werden und sieht zugleich, ob es seit der letzen Anmeldung Fehlversuche durch falsche Passworteingaben gab.

Die bisherige Implementierung von Active Directory lies nur mit Aufwand das Sammeln von Logon-Daten und deren Auswertung zu und machte somit die Prüfung, wann sich ein Benutzer zuletzt an einem Client angemeldet hat, nicht gerade trivial. Das, obwohl das Verzeichnis geeignete Attribute für die Aufzeichnung der Daten bereitstellt.

Bevor wir uns aber mit den bisherigen Implementierungen und den Neuheiten von LIL beschäftigen, stellen wir erst einmal fest, was ein „interactive logon“ (also eine interaktive Anmeldung) ist. Microsoft bezeichnet im Kern folgende Anmeldungen als „interaktiv“:

• Anmeldungen mit „STRG+ALT+ENTF“
• Remoteanmeldungen über Terminal- oder Remote Desktop Services
• Sessions, die per „Anmelden als“ bzw. “Runas“ geöffnet wurden

Webanwendungen, wie etwa Outlook Web Access, sowie Netzwerkanmeldungen per NTLM erzeugen keine interaktive Anmeldung.  Somit sind auch Zugriffe über Dateifreigaben keine „interaktive“ Anmeldung.

Seit jeher kennt Active Directory das Attribut „lastLogon“, das den Zeitstempel der letzten Anmeldung in einem Zeitstempel abspeichert. Der Nachteil des Attributs ist, dass es nicht repliziert wird – jeder Domänencontroller führt seinen eigenen Wert von „lastLogon“, sodass ein Administrator oder ein automatisiertes Skript alle Domänencontroller nach „ihrem“ lastLogon-Zeitstempel fragen muss, um den tatsächlich letzten interaktiven Logon eines Benutzers zu erfahren. Der größte gefundene Zeitstempel ist offensichtlich der aktuellste und zeigt das letzte Anmeldedatum an.

Mit Windows Server 2003 wurde ein neues Attribut eingeführt: lastLogonTimeStamp. LastLogonTimeStamp wurde im Schema für die Replikation zwischen Domänencontrollern konfiguriert, hat aber einen entscheidenden Nachteil: aus Respekt vor der möglichen Flut von Replikationsdaten, die der Abgleich des Attributs zwischen den DCs bedeuten würde, hat Microsoft entschieden, das Attribut an eine Latenz zu  binden. Der Zeitstempel wird beim Anmelden eines Benutzers oder Computers nur aktualisiert, wenn eine Wartezeit, per Vorgabe 14 Tage (minus einer zufällig gewählten Zeit von maximal 5 Tagen), verstrichen sind und innerhalb dieser Wartezeit nicht aktualisiert wurde. Das bedeutet eine Ungenauigkeit bei der Verwendung des Attributes von schlechtestenfalls etwa 14 Tagen, da der Zeitstempel nicht öfter aktualisiert wird. Die Latenz, die Domänencontroller warten, bevor sie lastLogonTimeStamp aktualisieren, wird durch das Attribut msDS-LogonTimeSyncInterval des Domänen-NC-Objektes (DC=domain,DC=tld) bestimmt und zeigt die Tage an, die bis zur nächsten Aktualisierung verstreichen sollen. Ein Setzen des Wertes auf „0“ hilft in diesem Fall nicht, da lastLogonTimeStamp dann gar nicht mehr aktualisiert wird. Somit ist der Mindestwert für die Latenz 1 Tag, was die Brauchbarkeit des Wertes auf Grund seiner Genauigkeit auf einen Tag legt. Das mag für Reporting-Zwecke ausreichend sein, wer jedoch wissen will, ob sich Lieschen Schmidt im Laufe des heutigen Tages angemeldet hat, wird enttäuscht werden.

Ab Domänen Modus Windows Server 2008 stellt das Last Interactive Logon-Feature nun eine exaktere und einfacher auszulesende Lösung dar, da das Attribut zwischen den Domänencontrollern repliziert und bei interaktiven Anmeldungen aktualisiert wird.

Die im gezeigten Screenshot bereitgestellten Informationen werden in insgesamt vier neuen Attributen gespeichert:

• msDS-FailedInteractiveLogonCount
• msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon
• msDS-LastFailedInteractiveLogonTime
• msDS-LastSuccessfulInteractiveLogonTime

Last Interactive Logon kann als Feature in zwei Stufen aktiviert werden.

Stufe 1: Anweisen der Domänencontroller, dass die Protokollierung der Anmeldedaten stattfinden soll.

Stufe 2: Aktivieren der Anzeige der letzten Logondaten, nachdem sich der Benutzer erfolgreich mit einer der oben genannten Methoden interaktiv angemeldet hat.

Die zweite Stufe der Aktivierung, das Einblenden der Logon-Daten nach beim Anmelden des Benutzers, ist optional und wird nicht für das erfolgreiche Füllen der Active Directory-Attribute benötigt. Die Anzeige dient nur zur Information für anmeldende Benutzer. Geschulte Benutzer könnten aus dieser Anzeige beispielsweise erkennen, dass sich ein anderer Mitarbeiter mehrfach eine Anmeldung mit einem falschen Passwort versucht hat, wenn der Falschanmeldungen-Zähler  unerwartet hoch ist oder der Benutzer selbst in letzter Zeit keine Falschanmeldungen versucht hat.

Eine geschickte Auswertung der Daten über alle Benutzer hinweg lässt sich auch für die Analyse der Sicherheit der Benutzerkonten verwenden. Steigende Falschanmeldungszahlen und ein Vergleich der Anmeldungen zwischen Wochen und Monaten kann auf böswillige Individuen hinweisen, die Passworte erraten möchten. Passwortangriffe, die mit Methoden der interaktiven Anmeldung gefahren werden, könnten so erkannt werden.

Sowohl Stufe 1 und Stufe 2 des Last Interactive Logon-Features werden über eine einzige Gruppenrichtlinie gesteuert. Abhängig davon, welche Zielsysteme die Gruppenrichtlinie erhält, wird entweder die zweite Variante des Features oder beide aktiviert.

Wird die Gruppenrichtlinie Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows Anmeldeinformationen – „Informationen zu vorherigen Anmeldungen bei der Benutzeranmeldung anzeigen“ an eine OU verknüpft, die Domänencontroller enthält, wird die Protokollierung der Anmeldedaten aktiviert. Domänencontroller werden daraufhin zusätzlich damit beginnen, letzte Anmeldeereignisse anzuzeigen. Man aktiviert mit einer Richtlinie auf Domänencontrollern sozusagen zwei Features.

Wird die Richtlinie an eine OU mit Computerkonten verknüpft, werden die Computer dieser OU die Anmeldeinformationen beim nächsten Anmelden des Benutzers anzeigen.

Vorsicht ist geboten bei der Reihenfolge der Richtlinienerstellung: es scheint fast logisch zu sein, dass Anmeldedaten zuerst von Domänencontrollern aufgezeichnet werden müssen, bevor sie an Clients angezeigt werden können. Es sollte jedoch dringend vermieden werden, die Richtlinie gleichzeitig für Domänencontroller und Clients, nur für Clients oder in Domänen mit Domänenfunktionsmodus vor Server 2008 zu aktivieren, da Benutzer in diesen Fällen mit folgender Fehlermeldung konfrontiert werden:

Warum die Fehlermeldung erscheint, ist simpel: Der Client arbeitet die Gruppenrichtlinie ab und wird angewiesen, Anmeldeinformationen des Benutzers von einem Domänencontroller abzurufen. Da der Domänencontroller in den oben geschilderten Fällen keine Informationen über Benutzeranmeldungen in den genannten Attributen sammelt, weil entweder die entsprechende Richtlinie noch nicht angewendet wurde, die DCs gar nicht Ziel der Richtlinie sind oder die DCs schlicht nichts von den Attributen wissen, scheitern Clients beim Abfragen der Anmeldeinformationen. Die Folge ist die im Screenshot gezeigte Fehlermeldung und die Verweigerung des Systems, den Benutzer anzumelden. Ein Klick auf den „OK“-Button erlaubt dem Benutzer ein erneuter Anmeldeversuch – mit dem gleichen Ergebnis.

Das Spiel kann je nach Größe des Unternehmen und der Anzahl der Ziele der Richtlinie zu einem echten Ärgernis werden. Neben der „hardcore“-Lösung, für die Anmeldung den Netzwerkstecker zu ziehen und das System am Kontaktieren des Domänencontrollers zu hindern, gibt es für eine schnelle Behebung des Problems nur eine Lösung: die Deaktivierung der Richtlinie für die Clientsysteme. Zielcomputer versuchen dann nicht mehr, die letzten Anmeldeergebnisse des Domänencontrollers abzufragen und führen die Anmeldung wieder wie gewohnt durch. Andernfalls schafft natürlich das Aktivieren der Richtlinie auf den Domänencontrollern Abhilfe.

Aus eigenem Interesse sollten also folgende Konstellationen vermieden werden:

• Aktivieren der Richtlinie in Domänen, die einen Domänenfunktionslevel kleiner als „Windows Server 2008“ besitzen.
• Aktivieren der Richtlinie für Zielcomputer, nicht aber für Domänencontroller
• Aktivieren der Richtlinie für Zielcomputer und Domänencontroller zum gleichen Zeitpunkt – Clients könnten die Richtlinie vor den Domänencontrollern oder der Replikation der aktivierten Richtlinie aktualisieren.

Bemerkenswert ist an dieser Stelle das Verhalten von Falschanmeldungen, die durch „NET USE“ vom Benutzer oder in Anmeldeskripten abgesetzt werden. Domänencontroller bemerken Falschanmeldungen über „NET USE“ und protokollieren diese entsprechend – erfolgreiche Anmeldungen werden allerdings nur im Zusammenhang mit vorangegangenen Fehlanmeldungen protokolliert. Das geschieht, obwohl NET USE eigentlich keine interaktive Anmeldung ist.

Anmeldungen mit Cached Credentials werden, obwohl sie eigentlich auch zu den interaktiven Anmeldungen gehören, nicht geloggt. Der Grund ist klar: zum Zeitpunkt der Authentifizierung ist keine Verbindung zu einem DC verfügbar.

Ein kleiner weiterer Hinweis aus der Praxis: das Aktivieren der Richtlinie auf Arbeitsstationen kostet in der Regel ein paar Sekunden und kann zu einem gewissen „Nerv“-Faktor führen, da sich Benutzer nicht nur mehr anmelden, sondern die Anmeldeinformationen per „OK“-Klick bestätigen müssen, um den Anmeldeprozess fortzuführen. Ist kein DC verfügbar, etwa weil der Client offline ist oder keine Verbindung zum Netz besitzt, erscheint ein Informationsballon in der Systray, dass gerade kein Anmeldeserver erreicht werden konnte – auch das kann mobile Benutzer nerven. Evenuell sollte man vorher also ausloten, wie hoch die Toleranz der Benutzer bzw. der erwartete Nutzen des angezeigten Meldungen auf den Zielsystem ist – oder das Feature nur auf gezielt ausgesuchten Machinen aktivieren. 

Macht’s gut!
Florian

* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.

Ja wo ist er denn? – Der SPA unter Windows Server 2008 und R2

Hallo, hier mal wieder Rol. Diesmal mit einem "Tool-Thema".

Der Server Performance Advisor, kurz SPA, hat unter Windows Server 2003 ja schon sehr gute Dienste geleistet, wenn es darum gegangen ist, hohe LSASS Lasten zu untersuchen. Zum Teil zeigt er ja sogar direkt an, wenn es bestimmte Clients sind, die meist hohe CPU Last eines DCs durch unschöne LDAP Anfragen verursachen. ´

Nur wie sieht es nun unter Windows Server 2008 aus? Den SPA Download kann man hier nicht mehr verwenden…

Die Antwort ist – er wurde inzwischen ins Betriebssystem integriert, aber gut versteckt. Wir finden ihn wie folgt:
Zunächst über “Administrative Tools” den “Reliability and Performance Monitor” starten. Dann unter “Data Collector Sets”, “System”, “Active Directory Diagnostics” auswählen, das entspricht dann wieder dem, was uns vom SPA unter “Active Directory” bekannt war. Alternativ kann auch der Server Manager bemüht werden - hier findet man den SPA unter "Diagnostics", "Performance". 

Der grüne Play Button sorgt dann wie gewohnt für etwa 5 Minuten Aufzeichnung (default), welche man auch manuell mit dem Stopp Button beenden kann, falls die Last gezielter eingefangen werden kann und soll. Anbei ein Bild dazu:

Nach der Aufzeichnung erfolgt die Auswertung und Erstellung der Reports automatisch. Man kann den Report unter “Reports”, “System”, “Active Directory Diagnostics” finden, sie werden automatisch mit der Kennung YYYYMMDD-xxxx durchnummeriert.

Dazu gleich ein Beispiel, bei dem ein Script auf einem Client permanent AD Objekte ausließt – mal sehen ob nun der Report diesen anzeigt, auch wenn die Last durch diese LDAP Anfragen sehr gering ist. Tatsächlich man findet ihn, wenn man im Report Bereich “Active Directory”, “Search” auswählt, wie folgendes Bild zeigt:

Man sieht hier

• die Client IP Adresse
• den Port
• dass mit Scope “deep” alle Unterstrukturen durchsucht wurden
• dass als DN dazu der Domänen NC verwendet wurde
• wie viele Objekte untersucht
• und zurückgegeben wurden
• die Zeit die dazu benötigt wurde
• und welche CPU Last das gekostet hat.

Wenn man die Report Daten sichern möchte, reicht es die Datei C:\Perflogs\ADDS\YYYYMMDD-xxxx\report.html zu sichern. Für eine weitere Analyse sollte man jedoch das ganze Verzeichnis sichern.

So, damit warten dann auch der SPA unter W2k8 und W2k8 R2 auf euren Einsatz!

Damit gutes Gelingen, Rol

Windows Server 2008 R2 Recycle Bin und “linked attributes”

Hi, hier ist wieder Florian, einer der deutschen MVPs – diesmal mit einem Active Directory-Thema als Gastbeitrag (*) für den Domain Team Blog. Nicht, dass ich mit den Gruppenrichtlinien-Themen zu einseitig werde ;-)

Nachdem das nordamerikanische AD Team um Ned Pyle (http://blogs.technet.com/askds/) einen klasse Artikel zum Thema AD Recycle Bin (http://blogs.technet.com/askds/archive/2009/08/27/the-ad-recycle-bin-understanding-implementing-best-practices-and-troubleshooting.aspx) verfasst hat, möchte ich die Gelegenheit ergreifen, um ein wenig tiefer in die Speicherung von Grabstein- und gelöschten Objekten einsteigen. Speziell soll uns ein Thema beschäftigen: Wie werden Gruppenmitgliedschaften (oder andere verknüpfte Attribute) behandelt, wenn ein Objekt gelöscht wird und wie verhält sich Active Directory mit aktiviertem Recycle Bin im Vergleich zu einem nicht aktivierten Recycle Bin?

Um die Materie genau verstehen zu können, hier ein wenig Theorie: Active Directory kennt neben Attributen mit Zeichenketten oder Binärdaten auch Attribute, die auf andere Objekte im Verzeichnis verweisen – das sind „linked attributes“. Linked attributes werden in einer separaten Tabelle innerhalb der Active Directory-Datenbank gespeichert und vom Verzeichnis speziell behandelt. Wer bereits ausgiebig über „linked attributes“ gelesen und gehört hat, darf einen Absatz überspringen, was jetzt folgt, ist das klassische Beispiel zu Active Directory-Gruppenmitgliedschaften, das die Verknüpfung bestens beschreibt:

Um die Gruppenzugehörigkeit von Sicherheitsprinzipalen in Active Directory speichern zu können, stellt Active Directory eine Verbindung zwischen den Objekten her. Gehört ein Benutzer einer Gruppe an, wird die Gruppenmitgliedschaft des Benutzers im Attribut „memberOf“ gespeichert – die Gruppe führt diese Mitgliedschaft im Attribut „member“. Wird in den Eigenschaften des Benutzers die Gruppemitgliedschaft beendet, verschwindet wie aus Geisterhand auch der Eintrag der Gruppenmitglieder aus den Eigenschaften der Gruppe. Schuld daran ist die Attributverknüpfung, die Active Directory zwischen „member“ und „memberOf“ führt. Diese Verknüpfung besteht aus zwei „links“, einem Forward- und einem Backlink. Gesteuert wird die Verknüpfung nur durch den Forwardlink, da Active Directory das Schreiben auf nur einen der beiden Links gestattet.  Backlinks werden „on the fly“ vom Verzeichnis anhand der Forwardlink-Informationen berechnet. Im Falle der Attribute „member“ und „memberOf“ ist „member“ (das Attribut der Gruppe) der schreibbare Forwardlink und „memberOf“ der kalkulierte Backlink. Wird ein Benutzer einer Gruppe hinzugefügt, wird ein neuer Forwardlink in die Gruppe eingefügt, was in einem Eintrag in die Linktabelle resultiert. Wird ein Benutzer aus einer Gruppe gelöscht, wird der Forward-Link aus der Link-Tabelle gelöscht.

Abbildung 1: Forward- und Backlink zweier Attribute. Nur Forwardlinks können geschrieben werden.

„Member“ und „MemberOf“ sind nicht die einzigen linked attributes im Verzeichnis – weitere bekannte Beispiele sind „Manager“ und „directReports“ oder „managedBy“ und „managedObjects“.

Was passiert nun, wenn ein Benutzer – ohne dass der Recycle Bin aktiviert ist – gelöscht wird? Alle Attribute werden im Zuge der Attributbereinigung für die Tombstoneerstellung gelöscht – selbstverständlich auch verlinkte Attribute. Da das Benutzerkonto Backlinks besitzt, müssen die Verknüpfungen am Forwardlink gelöscht werden – etwa der Gruppe. Anschließend wird das Objekt als gelöscht markiert und in den „Deleted Objects“-Container verschoben. Stellt man den Benutzer mit Hilfe eines Restores wieder her, erhält der Benutzer alle Attribute gemäß des letzten Backups zurück – mit Ausnahme der verknüpften Attribute, die dem Benutzer nur als backlink zur Verfügung stehen. Da die Gruppenmitgliedschaft mit der Gruppe gespeichert wird, kann die Wiederherstellung die Gruppen nicht zurückspielen – klar, wir haben ja nur den Benutzer wiederhergestellt. Die logische Konsequenz wäre also sowohl den Benutzer als auch seine Gruppen zurückzuspielen. Gut, dass seit Windows Server 2003 SP1 beim Restore durch NTDSUtil  eine LDIF-Datei erstellt wird, die beim Import mit LDIFDE nicht wiederhergestellte Backlinks des Benutzers zurückimportiert. Und so, ohne Restore der Gruppen, Mitgliedschaften zurückspielt.

Mit Windows Server 2008 R2 und dem AD-Papierkorb sieht das viel einfacher aus: wird ein Benutzer gelöscht, erhält das Objekt die Löschmarke und wird ebenfalls in den „Deleted Objects“-Container verschoben. Anders als bei nicht aktiviertem Recycle Bin werden alle Attribute des Objekes beibehalten – für die Zeit, in der es ein „Deleted Object“ ist und nicht in die „Recycled Object“-Phase übergeht.

Der Beispielbenutzer „Thomas“ wird verwendet, der Mitglied der Administratoren von Contoso ist und einige Gruppenmitgliedschaften besitzt.

Wird Thomas gelöscht und danach mit LDP im „Deleted Objects“-Container betrachtet, zeigt sich etwa dieses Bild:

Abbildung 2: LDP zeigt das Attribut „memberOf“ nicht an

Das Attribut „memberOf“ taucht in der Liste der Attribute des gelöschten Benutzerkonto von Thomas nicht auf - und das, obwohl der Recycle Bin aktiviert ist und alle weiteren Attribute vorhanden sind und nicht bereinigt wurden. Auch aus den vorherigen Gruppen wurde Thomas entfernt:

Abbildung 3: Thomas ist nicht mehr in der Gruppe IT-Admins

LDP ist normalerweise bekannt dafür, Objekte und Attribute anzuzeigen, die sonst kein anderes Tool anzeigt – es verheimlicht eigentlich keine Objekte. Wie ist das möglich? Eventuell weiß ja die PowerShell etwas dazu. Der Befehl

C:\ PS> Get-AdObject –filter {givenName –eq „Thomas“} –SearchBase „CN=Deleted Objects,DC=contoso,DC=com“ –IncludeDeletedObjects –Properties *

liefert uns alle Objekte aus dem Start-Suchcontainer “Deleted Objects”, deren Vorname “Thomas” lautet. In der Tat findet PowerShell den gelöschten Thomas:

Abbildung 4: PoSH findet Thomas

Zu unserem Erstaunen mit dem memberOf-Attribut und den korrekten Gruppen! Will Microsoft uns nun endgültig zwingen, die PowerShell zu nutzen und liefert mit anderen Tools absichtlich unvollständige Ergebnisse? Bevor Verschwörungstheorien die Runde machen und sich böswillige Absichten herumsprechen, wollen wir das Geheimnis lüften:

Um verlinkte Attribute – nicht nur das Linkpaar "member" und "memberOf" – bei einem Restore wiederherstellen zu können, dem Benutzer aber trotzdem aktuelle AD-Daten anzeigen zu können und gelöschte Objekte aus den grafischen Oberflächen zu entfernen, bedient sich Active Directory eines Trick: Verknüpfungen zu gelöschten Objekten werden deaktiviert. Durch die Markierung des Forwardlinks des Attributes als „deaktiviert“ werden Verknüpfungen zwischen Objekten nicht mehr in den üblichen GUIs angezeigt – per Standard auch nicht in LDP. Die PowerShell ist so eingestellt, dass sie deaktivierte Verknüpfungen automatisch verfolgt, berechnet und automatisch mit anzeigt.

Ganz hilflos ist man mit LDP aber auch nicht: wer sich die deaktivierten Links mit LDP anzeigen lassen will, muss zuvor ein seit 2008 R2 mitgeliefertes LDAP-Control per „Optionen“ – „Steuerelemente“ aktivieren. Controls sind Serveranweisungen, die LDAP-Clients an den LDAP-Server, in unserem Fall Active Directory, schicken können, um beispielsweise den Ergebnissatz der Abfrage zu manipulieren oder Sucheinstellungen zu konfigurieren.

Das Control für die verlinkten Attribute heißt treffend „Return deactivated links“.

Ist das Steuerelement zu den aktiven Control hinzugefügt worden, klappt es auch mit LDP:

Das „memberOf“-Attribut wird nun auch korrekt für Thomas angezeigt und das Ergebnis deckt sich mit der Ausgabe unseres "Get-ADObject"-Befehls der PowerShell.

Bevor wir es vergessen, ein Hinweis zu einer kleinen Stolperfalle zum Schluss: schließt und öffnet man LDP, merkt es sich die zuletzt aktivierten Controls. Da „Return deactivated links“ ein neues Control in Server 2008 R2 ist, verstehen Domänencontroller vor R2 dieses Steuerelement nicht, wenn man sich mit ihnen verbindet und durch das Verzeichnis browsen will. Die Fehlermeldung sieht dann so aus:

„Error processing control“ ist das Stichwort. Um LDP wieder wie gewohnt mit prä-2008R2-DCs nutzen zu können, muss das Control im oben genannten Menü deaktiviert werden.

Ich hoffe ich konnte mit diesem Blog-Beitrag nützliche Informationen zur Verfügung stellen und dem ein oder anderen eine böse Überraschung im Umgang mit gelöschten Objekten und dem Papierkorb ersparen. Besten Dank an dieser Stelle an Wolfang Sauer, der mir half, das „Verhalten“ in meinem Kopf richtig zu verstehen. Bis zum nächsten Mal!

Cheerio,
Florian

* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.

Kein NTLM bei interaktiver Anmeldung an Vista und 2008 – betroffen u.a.: Externe Vertrauensstellungen

Mit Windows Server 2008 – und damit auch für Windows Vista SP1 – wurde eine Design-Änderung eingeführt, die das Verhalten bei einer interaktiven Anmeldung betrifft:

Es findet kein Rückfall mehr auf NTLM statt, wenn Kerberos bei einer interaktiven Anmeldung aus irgendeinem Grund fehlschlägt.

Davon betroffen sind u.a. Anmeldungen über eine externe Vertrauensstellung, bei denen bisher standardmäßig davon ausgegangen wird, daß hier NTLM verwendet wird.

Unsere Erfahrung in der letzten Zeit hat gezeigt, daß in den meisten Fällen auch Kerberos bei einer Anmeldung über einen externen Trust funktioniert.

Eine Voraussetzung ist, daß der Trust DNS-fähig ist und damit mindestens unter Windows 2000 erstellt wurde – d.h. getestet hab ich es nur ab Windows 2003. Trusts, die noch unter Windows NT 4.0 erstellt wurden, kennen nur NetBIOS. Mit diesem Trust-Typ funktioniert eine Anmeldung mit Kerberos also nicht.

Generell empfehlen wir immer, Trusts auf den Typ Forest-Trust zu ändern, weil sie deutlich flexibler sind und mehr Konfigurationsmöglichkeiten bieten.
Wo das aus irgendwelchen Gründen nicht möglich ist, kann es helfen, den externen Trust einfach mal neu zu erstellen. Falls der „Trusttype“ vorher 1 war und das Betriebssystem, wo er jetzt neu erstellt wird, mindestens Windows 2000 ist, würde er auf Trusttype 2 aktualisiert werden und damit DNS-fähig werden.

Eine wichtige Änderung ist, daß durch die Verwendung von Kerberos sich das Netzwerkverkehrsprofil ändert. Bei NTLM wird die Anmeldeanforderung ja ausgehend von der Maschine, an die sich der Benutzer anmeldet, von der Ressource per NetLogon RPC zum Benutzer-DC (Domänenkontroller) weitergeleitet.
Mit Kerberos ändert sich das. Die Client Maschine (bei interaktiver Anmeldung ist die gleich dem Ressource Server) treibt die Kommunikation. Die Maschine muß nun, anders als vorher, selbst eine Verbindung mit dem Domain Controller der Benutzerdomäne erstellen. Wenn sie das TGT erhalten hat, holt sie damit ein Ticket für die Ressourcen-Domäne und vom Ressourcen-DC bekommt der Benutzer dann ein Ticket für die Arbeitsstation.

Wie findet man heraus, welcher Trust-Typ vorliegt ?
Active Directory speichert den Typ des Trusts und der verwendeten Namensauslösung im Attribut „TrustType“ des Trusted Domain Objekts im System Container. Die Werte für alle vertrauten Domänen einer Domäne kann man mit folgender Kommandozeile herausfinden - beim Beispiel der interaktiven Anmeldung also in der Domäne der Arbeitsstation:

ldifde /d cn=system,dc=<Deine Domäne> /p onelevel /r (objectcategory=trustedDomain) /l trusttype,trustpartner /f trust-types.txt

Mit diesem Kommando werden die Werte von Trusttype und von TrustPartner ausgegeben.

Denn neben dem Wert für TrustType ist der NETBIOS Name der Domain in TrustPartner ein Hinweis, daß es mit Kerberos Probleme geben wird. Bei (mit Kerberos) funktionierenden Trusts steht hier der DNS Name der Domäne, so wie dann auch das Objekt selbst benannt ist.

Achtung: In der Liste sind auch die Domänen des Forests selbst verzeichnet, zu denen die Domäne Trusts hat.

Zusatznotiz:
Damit Kerberos über eine externe Vertrauensstellung funktionieren kann, können natürlich noch andere Dinge eine Rolle spielen, wie z.B. die Ports, die Kerberos benötigt, falls zwischen den Domänen eine Firewall ist, siehe auch z.B.:

832017 Service overview and network port requirements for the Windows Server system
http://support.microsoft.com/default.aspx?scid=kb;EN-US;832017

Gruß

Barbara

NTFRS Morphed Folder ohne Original durch Löschen und Neuerstellen von Verzeichnissen

Hallo, hier mal wieder euer Rol. Diesmal mit einem NTFRS Thema.

FRS ist zwar schon totgesagt, aber bis zum endgültigen Ersetzen durch DFSR wird ja doch noch einige Zeit ins Land gehen. Daher bleibt auch auf weiteres der richtige Umgang mit dem Datei Replikations Dienst ein Thema - gerade dann, wenn SYSVOL damit repliziert wird und jegliche Störung ganz empfindliche Konsequenzen für die Domänen Clients hat.

Der ein oder andere mag ja schon einmal ein NTFRS Morphed Folder gesehen haben. Es handelt sich dabei um Order mit Namen wie “Policies_NTFRS_72a2c00f”. Meistens gibt es parallel zu diesem Folder dann jedoch einen mit dem original Namen, also “Policies”. Das hat dann noch keine so gravierenden Auswirkungen auf Clients. Dazu gibt es auch einen Artikel mit dem Vorgehen zur Bereinigung:
328492 Folder name is changed to "FolderName_NTFRS_<xxxxxxxx>"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;328492

Doch was mag passiert sein, wenn es nun kein Original mehr gibt? Für Clients ist das jedenfalls fatal.

In diesem Fall kann folgendes geschehen sein. Der Ordner wird auf dem Upstream (NTFRS Member auf dem die Änderung passiert) gelöscht und wieder neu angelegt. Auf dem Downstream (NTFRS Member welcher die Änderung erhalten soll) kann die Löschung jedoch nicht umgesetzt werden, da durch einen permanenten Zugriff auf eine Datei innerhalb der Verzeichnisstruktur ein Lock besteht. Da die Neuerstellung des gleichnamigen Verzeichnisses nun aber auch repliziert werden muß, bleibt NTFRS nichts anderes übrig, als den neuen Ordnerzu “morphen” – spricht mit dem oben beschriebenen generischen Namen zu versehen. Die Namensänderung wird nun auch wieder an den ursprünglichen Upstream repliziert. NTFRS versucht weiter die Löschung umzusetzen, was irgendwann (sobald das Lock verschwunden ist) auch möglich ist. Was also übrig bleibt ist dann der Morphed Folder, jedoch ohne original Verzeichnis – mit den entsprechenden Auswirkungen auf die Clients.

Um das näher zu untersuchen, kann man sich das sogenannte NTFRS Outlog ansehen. Die zugehörigen Debug Logs sind meistens schon überschreiben. Das NTFRS Outlog erhält man über:

C:\> NTFRSUTL OUTLOG >Outlog.txt

Zum Outlog von Upstream Member RWVSM2 nun ein Beispiel, bei dem das Verzeichnis Test1 gelöscht, sowie neu erstellt wird und durch den NTFRS Downstream Partner RWVSM1 “gemorphed” wird, da es dort ein File Lock in der Verzeichnisstruktur gibt, welches die Löschung verhindert:

1) altes Directory Test1 wird gelöscht, auf Upstream Member RWVSM2 (OriginatorGuid 60fd3eda-88e0-4da1-a4ceb38e90fdd01c)

Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber               : 00028e1e
Flags                        : 00000028 Flags [Locn LclCo ]                       <- lokale Änderung (Local Changeorder)
IFlags                       : 00000001 Flags [IFlagVVRetireExec ]
State                        : 00000014  CO STATE:  IBCO_OUTBOUND_REQUEST
ContentCmd                   : 00000000 Flags [<Flags Clear>]
Lcmd                         : 00000003  D/F 1   Delete                              <- Löschung
FileAttributes               : 00000010 Flags [DIRECTORY ]
FileVersionNumber            : 00000002
PartnerAckSeqNumber          : 00000000
FileSize                     : 00000000 00000000
FileOffset                   : 00000000 00000000
FrsVsn                       : 01c9bda7 456e07bd
FileUsn                      : 00000000 2e4460f0
JrnlUsn                      : 00000000 2e4460f0
JrnlFirstUsn                 : 00000000 2e4460f0
OriginalReplica              : 1  [???]
NewReplica                   : 1  [???]
ChangeOrderGuid              : 4b4884b4-254e-4544-b782eb6540010381
OriginatorGuid               : 60fd3eda-88e0-4da1-a4ceb38e90fdd01c    <- GUID des NTFRS Members RWVSM2, der die Änderung einführt
FileGuid                     : b2f62e58-f7fd-4b80-abb24a5cc03539d6
OldParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid                   : 45beeef3-0863-4097-8d45ec951e3522d4
Spare1Ull                    :
MD5CheckSum                  : MD5: 00000000 00000000 00000000 00000000
RetryCount                   : 0
FirstTryTime                 : Fri Jun  5, 2009 16:55:32
EventTime                    : Fri Jun  5, 2009 16:55:31
FileNameLength               :       10
FileName                     : Test1                                                        <- Name das Verzeichnisses
Cxtion Name                  : <Jrnl Cxtion> <- <Jrnl Cxtion>\<Jrnl Cxtion>
Cxtion State                 : Joined  

2) neues Verzeichnis Test1 wird auf RWVSM2 angelegt/umbenannt, neue FileGuid 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef

Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber               : 00028e1f
Flags                        : 01000028 Flags [Locn LclCo CmpresStage ]
IFlags                       : 00000001 Flags [IFlagVVRetireExec ]
State                        : 00000014  CO STATE:  IBCO_OUTBOUND_REQUEST
ContentCmd                   : 00000000 Flags [<Flags Clear>]
Lcmd                         : 00000001  D/F 1   Create                                       <- Erstellung
FileAttributes               : 00000010 Flags [DIRECTORY ]
FileVersionNumber            : 00000000
PartnerAckSeqNumber          : 00000000
FileSize                     : 00000000 00000000
FileOffset                   : 00000000 00000000
FrsVsn                       : 01c9bda7 456e07be
FileUsn                      : 00000000 2e446300
JrnlUsn                      : 00000000 2e446138
JrnlFirstUsn                 : 00000000 2e446138
OriginalReplica              : 1  [???]
NewReplica                   : 1  [???]
ChangeOrderGuid              : cda323dd-7a7b-47c0-a882cdc587fb138b
OriginatorGuid               : 60fd3eda-88e0-4da1-a4ceb38e90fdd01c
FileGuid                     : 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef       <- neue File GUID
OldParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid                   : 45beeef3-0863-4097-8d45ec951e3522d4
Spare1Ull                    :
MD5CheckSum                  : MD5: 142e4db1 eee3922a 94c8e76c 9e126531
RetryCount                   : 0
FirstTryTime                 : Fri Jun  5, 2009 16:55:38
EventTime                    : Fri Jun  5, 2009 16:55:34
FileNameLength               :       20
FileName                     : New Folder
Cxtion Name                  : <Jrnl Cxtion> <- <Jrnl Cxtion>\<Jrnl Cxtion>
Cxtion State                 : Joined  

Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber               : 00028e20
Flags                        : 01000024 Flags [Content LclCo CmpresStage ]
IFlags                       : 00000001 Flags [IFlagVVRetireExec ]
State                        : 00000014  CO STATE:  IBCO_OUTBOUND_REQUEST
ContentCmd                   : 00002000 Flags [RenNew ]                       <- Umbenennung in den endgültigen Namen
Lcmd                         : 0000000f  D/F 1   NoCmd
FileAttributes               : 00000010 Flags [DIRECTORY ]
FileVersionNumber            : 00000001
PartnerAckSeqNumber          : 00000000
FileSize                     : 00000000 00000000
FileOffset                   : 00000000 00000000
FrsVsn                       : 01c9bda7 456e07bf
FileUsn                      : 00000000 2e446270
JrnlUsn                      : 00000000 2e446270
JrnlFirstUsn                 : 00000000 2e446270
OriginalReplica              : 1  [???]
NewReplica                   : 1  [???]
ChangeOrderGuid              : 9ad45a1f-6419-46bb-a21fc255b5985f98
OriginatorGuid               : 60fd3eda-88e0-4da1-a4ceb38e90fdd01c
FileGuid                     : 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef
OldParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid                   : 45beeef3-0863-4097-8d45ec951e3522d4
Spare1Ull                    :
MD5CheckSum                  : MD5: 142e4db1 eee3922a 94c8e76c 9e126531
RetryCount                   : 0
FirstTryTime                 : Fri Jun  5, 2009 16:55:40
EventTime                    : Fri Jun  5, 2009 16:55:37
FileNameLength               :       10
FileName                     : Test1
Cxtion Name                  : <Jrnl Cxtion> <- <Jrnl Cxtion>\<Jrnl Cxtion>
Cxtion State                 : Joined  

3) während der NTFRS Replikation konnte jedoch auf dem Downstream RWVSM1 durch ein File Lock das alte Verzeichnis nicht gelöscht werden, es kommt zum Morphed Folder als Änderung durch RWVSM1 (remote OriginatorGuid 0fff42a5-d0d5-4fb6-aacd854ea225f0c4)

Table Type: Outbound Log Table for DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (1)
SequenceNumber               : 00028e21
Flags                        : 03100204 Flags [Content OofOrd SkipOrigChk CmpresStage SkipVVUpdt ]  <- keine lokale Änderung, also remote
IFlags                       : 00000001 Flags [IFlagVVRetireExec ]
State                        : 00000014  CO STATE:  IBCO_OUTBOUND_REQUEST
ContentCmd                   : 00002000 Flags [RenNew ]                       <- Umbenennung
Lcmd                         : 0000000f  D/F 1   NoCmd
FileAttributes               : 00000010 Flags [DIRECTORY ]
FileVersionNumber            : 00000002
PartnerAckSeqNumber          : 00001d6c
FileSize                     : 00000000 00000000
FileOffset                   : 00000000 00000000
FrsVsn                       : 01c9c739 e01ec252
FileUsn                      : 00000000 2e447380
JrnlUsn                      : 00000000 00000000
JrnlFirstUsn                 : 00000000 00000000
OriginalReplica              : 1  [???]
NewReplica                   : 1  [???]
ChangeOrderGuid              : e294e5b4-2494-4b72-b2060aea700510b7
OriginatorGuid               : 0fff42a5-d0d5-4fb6-aacd854ea225f0c4       <- Änderung durch remote Partner RWVSM1
FileGuid                     : 0cd66c8c-af2c-4376-89e5b77ab1e5b8ef       <- File GUID des neu erstellten Verzeichnisses
OldParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
NewParentGuid                : 72a2c009-0710-4f35-b813fb49b43043b5
CxtionGuid                   : d6946061-6730-4734-a80b1c62fa2677bd
Spare1Ull                    : Tue Dec  9, 2008 14:59:37
MD5CheckSum                  : MD5: 142e4db1 eee3922a 94c8e76c 9e126531
RetryCount                   : 0
FirstTryTime                 : Fri Jun  5, 2009 16:55:44
EventTime                    : Fri Jun  5, 2009 16:55:39
FileNameLength               :       40
FileName                     : Test1_NTFRS_c88de319                            <- Name des Morphed Folders
Cxtion Name                  : D6267BD6-398D-4FCB-9743-6131CAFBF257 <- RWVSM1\RWR2DOM\RWVSM1$       <- Verbindung der Replikation
Cxtion State                 : Joined  

Das Verhalten entspricht der NTFRS Conflict Resolution und ist, so komisch es auch klingen mag, By Design. Es mag zwar nur im Zusammenhang mit gesperrten Dateien auftreten ist jedoch nicht unwahrscheinlich. Daher ist es von Microsoft nicht empfohlen, z.B. beim Restoren von Policies, replizierte Ordner zu löschen und wieder neu anzulegen.

Man kann zwar versuchen, den NTFRS Einfluß gesperrter Dateien zu reduzieren, wie es beschrieben ist in
816493  How to configure the File Replication Service to allow fewer sharing violations that block replication
http://support.microsoft.com/default.aspx?scid=kb;EN-US;816493
aber das ist keine Garantie, daß keine solchen Verhalten auftreten. Zur Bereinigung kann man dann wieder auf den Eingangs erwähnten Artikel 328492 zurückgreifen und den Morphed Folder in den Originalnamen umbenennen.

Damit zeigt sich letztendlich wieder, wie vorsichtig man im Umgang mit NTFRS sein muß, um Probleme zu vermeiden und bestimmte Prozeduren ausgiebig testen sollte bevor man sie in der Produktion einsetzt.

Wer sich noch weiter in NTFRS vertiefen mag, findet sehr gute Informationen dazu im Whitepaper
How FRS works
http://technet.microsoft.com/en-us/library/cc962202.aspx

In diesem Sinne, weiter gutes Gelingen!
Euer Rol

Hinweise zur Einführung bzw. Aktivierung von Kennwortrichtlinien

Hi zusammen. In einigen Domänenumgebungen unserer Kunden sind Kennwortrichtlinien, also beispielsweise die zentrale Vorgabe von Kennwortlänge, Komplexität, minimalem und maximalem Kennwortalter und Kontosperrungsschwellen, bei der Installation / Inbetriebnahme der Domäne deaktiviert worden oder für andere Zwecke, etwa längere Migrationsphasen" o.ä., außer Betrieb genommen.

Möchte man nun nach einiger Zeit (vielleicht sogar nach einigen Jahren) Kennwortrichtlinien wieder in Betrieb nehmen, sind einige Fallstricke zu beachten. So zieht zum Beispiel die Aktivierung des maximalen Kennwortalters z.B. auf 100 Tage den Effekt nach sich, daß die Kennwörter von den Benutzern unter Umständen direkt ablaufen, da sie mehr als diese 100 Tage nicht mehr geändert wurden. Die Aufforderung zur Kennwortänderung passiert bei interaktiven Anmeldungen automatisch, jedoch melden sich einige Benutzer gar nicht interaktiv am System an, sondern nutzen hauptsächlich “extern” Dienste wie Outlook Web-Access, Outlook mittels RPC über HTTP/S, Push-E-Mail, VPN Einwahl usw.

Genau für diese Benutzer kommt es dann unmittelbar nach der Aktivierung der Policies zu Problemen, da Ihr Kennwort abgelaufen ist und sie es nicht von extern setzen können. Zusätzlich sind auch Service Accounts immer wieder ein “heißes Thema” in diesem Kontext.

Im Kern ist es sinnvoll, die Wiedereinführung oder die Ersteinführung von Kennwortrichtlinien in verschiedene Phasen einzuteilen. Diese Phasen könnten wie folgt aussehen:

• Phase 1: Dokumentation des derzeitigen Status, d.h. es erfolgt eine Überprüfung, wie alt die Benutzer-Kennwörter in der Umgebung sind. Das Ergebnis wirkt sich auf das weitere Vorgehen aus.
  
• Phase 2: Die betroffenen Benutzer und Administratoren müssen über die geplanten Änderungen informiert werden, am besten auf verschiedenen Wegen (E-Mails, Betriebsbekanntmachungen etc.). Dies ist einer der kritischsten und wichtigsten Punkte des Vorhabens – denn rein technisch lassen sich die mit der Re-Aktivierung von Kennwortrichtlinien verbundenen Fallstricke nicht lösen. Eine erfolgreiche Einführung der Kennwortrichtlinien kann nur in sehr enger Zusammenarbeit mit den Beschäftigten erfolgen. Den Mitarbeitern muss nicht nur erklärt werden, dass die Richtlinien eingeführt werden, sondern auch WARUM. Wir schlagen vor, die Aktion Kennwörter mit anderen Aktionen zur Computersicherheit zu ergänzen, zum Beispiel Wechseldatenträger, Arbeiten an öffentlichen Plätzen, Umgang mit mobilen Geräten, usw.
  
• Phase 3: Identifizieren von Dienstkonten, so daß diese – je nach interner Planung – vor den Kennwortänderungen geschützt sind. So kann beispielsweise das Flag „password never expires“ auf diesen Konten gesetzt werden, so dass Dienstkonten nicht von den Kennwort-Änderungsrichtlinien / Änderungsintervallen betroffen sind. Hier können ggf. auch weitere Konten mit einbezogen werden.
  
• Phase 4: Implementierung von „schwachen“ Kennwortrichtlinien. Hier wird etwa für das maximale Kennwortalter der unter Windows Server 2003 unterstützte Maximalwert von „999“ Tagen eingesetzt; es werden noch keine Account Lockouts konfiguriert etc. In dieser Phase sollten die Benutzer an regelmäßige Kennwortänderungen gewöhnt werden. Sie sollten Emails erhalten, wenn ihe Kennwort vom Alter her den späteren Zielwert überschreitet. Die Benachrichtigungen sollten dauerhaft beibehalten werden, kommen dann aber einige Wochen vor dem Ablauf des Kennworts.
  
• Phase 5: Nach erneutem Monitoring des Status der Kennwortänderungen können dann Schritt für Schritt stärkere Werte eingesetzt werden. Hierbei sollte in kleinen Schritten vorgegangen werden, nicht die Zielpolicies gleich im ersten Wechsel eingesetzt werden.

Generell muß gesagt werden, daß das Vorhaben (gerade während der Einführung der Kennwortrichtlinien) als kritisch in Bezug auf die Funktionsfähigkeit der Umgebung angesehen werden muß. D.h. die Planung hat einen hohen Stellenwert auf eine erfolgreiche (Wieder-)Einführung der Kennwortrichtlinien, um Ausfälle in der Produktionsumgebung zu vermeiden.

Es gibt unter Windows Server 2008 (Domain Functional Level 2008) eine neue Möglichkeit, mehrere Kennwortrichtlinien pro Domäne zu konfigurieren. Dies sind die sogenannten “Fine-Grained Password Policies” bzw. “Password Setting Objects”. Da eine stufenweise / gruppenweise Einführung der Kennwortrichtlinien das wahrscheinlich sinnvollste Vorgehen ist, sollte daher geprüft werden, ob mögliche Probleme bei der Einführung der Kennwortrichtlinien unter Windows Server 2003 ein Upgrade der Domänencontroller Umgebung auf Windows Server 2008 (R2) rechtfertigen. Dies kann betriebswirtschaftlich interessant sein. Die PSOs erlauben eine einfachere Verwaltung der Benutzergruppen, die mit den Richtlinien versehen werden.

Beispiele zur möglichen Umsetzung könnten in groben Zügen also wie folgt aussehen:

Es folgen nun einige Hinweise zu den oben genannten möglichen Phasen. Es sollte beachtet werden, daß die Punkte nur einen groben Leitfaden darstellen. Je nach Umgebung können einige Punkte dazu kommen, die hier nicht begesprochen werden.

In Bezug auf die möglichen Einstellungen für Kennwortrichtlinien findet man beispielsweise im “Windows Server 2003 Security Guide” bzw. “Windows Server 2003 Sicherheitshandbuch” die Erklärungen der einzelnen Einstellungen inklusive einiger Hinweise zu den Implikationen der Einstellungen.

Phase 1:
Unter Windows Server 2003 kann nur eine Kennwortrichtlinie pro Domäne eingesetzt werden. Diese gilt dann für alle Benutzerkonten und wird auf den Domänencontrollern angewendet.

Wurden etwa seit mehreren Jahren in einer Domänenumgebung die Kennwortrichtlinien außer Kraft gesetzt, stellt das maximale Kennwortalter ein Problem dar, da der unter Windows Server 2003 unterstützte Maximalwert „999“ Tage beträgt, siehe dazu: Configuring Password Policies „Maximum Password Age“ http://technet.microsoft.com/en-us/library/dd277399.aspx

Da der Zeitraum der letzten Kennwortänderung höher als „999“ Tage sein kann, sollte in der Domänenumgebung zuallererst eine Überprüfung der Benutzerkonten in Bezug auf diesen letzten Änderungszeitpunkt erfolgen. Der Zeitraum der letzten Kennwortänderung läßt sich (neben eigenen Scripts) herausfinden, indem man die DS*-Tools auf einem DC nutzt. So kann etwa ein

C:\> dsquery user -stalepwd 999

ausgeben, welche Benutzerkonten vor mehr als 999 Tagen Ihr Kennwort das letzte Mal geändert haben. Siehe dazu auch http://technet.microsoft.com/en-us/library/cc725702(WS.10).aspx zu „dsquery user“.

So kann man verschiedene Benutzergruppen zur Umstellung bilden, wenn man das maximale Kennwortalter ausgelesen und dokumentiert hat.

Zeigt sich, daß fast alle Benutzer vor mehr als „999“ Tagen das Kennwort zuletzt geändert haben, kann keine Gruppeneinteilung erfolgen. Andernfalls hat man jedoch ein gutes Instrument, um die Kennwortrichtlinien stufenweise einzuführen, sieh auch Phase 4.

Die Alternative dazu ist, das maximale Kennwortalter auf den Wert “0” zu stellen, denn dann erfolgt eine Einstufung nach dem Prinzip “Kennwort läuft nie ab”. Damit ist die harte Grenze von “999” Tagen kein Problem mehr.

Phase 2:
Da sich die Umstellung nicht ausschließlich technisch lösen läßt, ist das Involvieren der Benutzer der betroffenen Domäne im Gesamtvorgehen wichtig, wenn nicht sogar der wichtigste Punkt. Ohne die Mitarbeit der Benutzer kann eine erfolgreiche Umstellung nicht erfolgen. Hier sollte die notwendige Sichtbarkeit auch von Seiten des Managements forciert werden, um von vornherein Probleme zu vermeiden.

Wir gehen an dieser Stelle einmal davon aus, daß bezüglich der Kennwortrichtlinien selbst, als auch zu Themen wie „Kennwortweitergabe“, „Kennwort notieren“ etc. interne Richtlinien / Betriebsvereinbarungen existieren. Andernfalls sollte dies geprüft und nachgeholt werden.

Die Benutzer sollten mehrfach und auf verschiedenen Wegen über die vorstehenden Änderungen informiert werden. Als Information sollte neben der Nennung der neuen Kennwortrichtlinien selbst (also welche Schwellwerte existieren, wie genau komplexe Kennwörter aussehen, was die Einführung direkt für Aktionen von Seiten der Benutzer nach sich ziehen wird etc.) sollte auch festgelegt sein, in welchem Zeitraum eine selbständige Änderung des Kennworts erfolgen muß – inklusive einer Anleitung zur Änderung. So kann beispielsweise ein Zeitraum von 1 Monat als erster Zeitrahmen angegeben werden.

Nach einem Monat erfolgt eine erneute Überprüfung des Kennwortalters der Benutzer – diejenigen Benutzer, die bis dahin Ihr Kennwort nicht geändert haben, können nochmals aufgefordert werden, Ihr Kennwort zu ändern. Ggf. kann auch hier direkt das Management involviert werden. Vergesst nicht, den Mitarbeiter auch zu erklären, daß gute Kennwörter ein wichtiger Beitrag zur Computersicherheit sind.

Nachdem wir aus Phase 1 wissen, welche Accounts mit einem maximalen Kennwortalter von mehr als 999 Tagen vorhanden sind, kann man diese Benutzer ebenfalls direkt kontaktieren.

Teilt man das Vorgehen etwa auch in kleinere Einheiten auf, kann man so innerhalb von 1-2 Monaten gute Resultate für pro-aktive, also nicht technisch erzwungene Kennwortänderungen erreichen.

Mobile Benutzer, die sich selten in das Netzwerk verbinden und in der Regel keine interaktive Anmeldung im Netz durchführen, werden durch Bordmittel keine Warnungen zu ablaufenden Kennwörtern angezeigt. Sie haben auch keinen sichtbaren Weg oder Tool, um ihr Kennwort zu ändern. Sie können in der Regel nur selbst über den Sicherheitsdialog das Kennwort ändern, während sie per VPN verbunden sind. Für diese Benutzer kann zum Beispiel eine der folgenden Möglichkeiten eingesetzt werden:

1. Outlook Web-Access bietet die Möglichkeit für Kennwortänderungen ab Version 2003. In OWA 2003 muß die Funktion nachgerüstet / eingerichtet werden, ab Exchange 2007 ist sie integriert.
   Siehe zur Einrichtung: Implementing the Change Password feature with Outlook Web Access http://support.microsoft.com/kb/297121/en-us
   
2. Alternativ dazu können Zusatzprodukte wie etwa der Microsoft ISA Server oder 3rd Party Software Möglichkeiten zur Kennwortänderung von Benutzerkonten zur Verfügung stellen. Siehe dazu beispielsweise: Configuring and Troubleshooting the Password Change Feature in ISA Server 2006 http://technet.microsoft.com/en-us/library/cc514301.aspx
   
3. Clients für VPN-Verbindungen können nach der Verbindung Scripts ausführen. Damit kann das Kennwortalter geprüft werden und eine entsprechende Warnung ausgegeben werden, mit Hinweisen wie das Kennwort geändert werden kann.

Es sollte zusätzlich ein Prozess eingeführt werden, der die Benutzer, die sich nie interaktiv an der Domäne authentifizieren (und dementsprechend auch keine Warnung erhalten, daß das Kennwort ablaufen wird), auch in Zukunft automatisiert informiert, daß Ihr Kennwort ablaufen wird. Nur so können diese Benutzer rechtzeitig selbständig eine Kennwortänderung vornehmen. Es gibt mit Windows Server 2003 / 2008 / 2008 R2 keine Bordmittel dies zu gewährleisten. Es gibt jedoch einige Drittanbieter, die entsprechende Software anbieten, die vor Kennwortablauf E-Mails an die Benutzer versendet. Ggf. kann solch ein Script auch selbst entwickelt werden bzw. findet man mittels http://www.bing.com sicher einige interessante Webseiten und Forenbeiträge dazu. ;-)

Wichtig ist hier entsprechend einzuplanen, daß dieser Prozess auch in Zukunft nach der Einführung der Kennwortrichtlinien fortlaufend gelebt werden muß.

Läuft ein Kennwort in Zukunft nach Einführung des Maximalalters eines Kennworts ab, kann es der Benutzer direkt bei einem interaktiven Logon erneuern. Diese Möglichkeit besteht nicht für externe Benutzer – hier muß der Helpdesk dann ggf. die Kennwörter wieder zurücksetzen, um den betroffenen Benutzern eine Kennwortänderung z.B. über Outlook Web-Access oder den ISA Server zu ermöglichen. Zusätzlich gibt es auch Funktionen in Microsoft als auch Third Party Produkten, um ein Kennwort direkt durch den Benutzer zurückzusetzen.

Ebenfalls wichtig ist es hierbei zu bedenken, daß zu diesem Zeitpunkt in Phase 2 noch keinerlei Vorgaben in Bezug auf Kennwortlänge oder Kennworthistorie existieren. D.h. da an dieser Stelle noch keine entsprechenden Richtlinien definiert wurden, können die Benutzer die Kennwörter frei wählen. Möchte man das unterbinden, muß die Phase 2 mit Phase 4 zusammengefügt werden, d.h. erst nach Phase 3 ausgeführt werden.

Phase 3:

In Phase 3 sollte in Zusammenarbeit mit den Service-Administratoren geprüft werden, welche Accounts in der Domäne Dienstkonten sind. Diese müssen unter Umständen vor Kennwortänderungen geschützt werden – zumindest vor denen der allgemeinen Kennwortrichtlinie. Generell empfiehlt sich natürlich ein Prozess, der auch Dienstkonten zyklisch mit neuen Kennwörtern versieht. Das ist jedoch ein anderes Thema und wird hier nicht weiter angesprochen.

Grundsätzlich gibt es keine automatisierte Möglichkeit zu prüfen, ob es sich bei einem Konto um einen normalen Account oder einen Dienstaccount handelt. Dies muß also ggf. über eine interne Dokumentation oder über Scripts erfolgen, die Dienstkonten auf den Zielsystemen prüfen (etwa die Benutzer von Diensten, geplanten Tasks, Management Systemen etc.). Erst mit Windows Server 2008 R2 gibt es vom AD verwaltete Servicekonten, für die das möglich ist.

Es ist empfehlenswert, die Dienstkonten gerade während der Einführung der Kennwortrichtlinien mit dem Flag „password never expires“ zu versehen – dieses Flag „überschreibt“ für die Konten die Kennwortrichtlinie des maximalen Kennwortalters, siehe dazu auch: Managing Existing User and Group Accounts http://technet.microsoft.com/en-us/library/bb726988.aspx

Password Never Expires Ensures the account password never expires, which overrides the normal password expiration period.

Caution: Selecting this option creates a security risk on the network. While you may want to use Password Never Expires with administrator accounts, you shouldn't use this option with normal user accounts in most cases.

Diese Aktion läßt sich automatisieren – wenn die Accounts vorher von den Administratoren korrekt identifiziert wurden. Möchten man den Prozess z.B. für eine komplette OU scripten, kann man etwa folgende Möglichkeiten in Betracht ziehen: 

1. How Can I Configure an Active Directory Account So the Password Never Expires?  http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1031.mspx
   
2. dsmod user: http://technet.microsoft.com/en-us/library/cc732954(WS.10).aspx

C:\> dsmod user <DN> -pwdneverexpires yes

Die Übergabe von Accounts kann als Pipe „|“ von dsquery o.ä. erfolgen. Somit ist auch hier eine vollständige Automatisierung möglich.

Die administrativen Konten sollten hier Vorreiter und Pilotbenutzer sein. Deren Kennwörter sollten also regelmäßig geändert werden.

Update 10.09.2009: Ein Punkt ist uns beim Erstellen des Blog Eintrags dann doch durch die Lappen gegangen: Es ist möglich, das Attribut "pwdLastSet" auf den Wert "-1" zu setzen. Dieses Attribut ist die Berechnungsgrundlage für das Kennwortalter eines Benutzers.
Wird bei den relevanten Benutzern nach der oben genannten Dokumentation des Kennwortalters das Attribut "pwdLastSet" auf den Wert "-1" gesetzt, wird dies vom System automatisch in den aktuellen Zeitstempel umgewandelt. Somit greift das maximale Kennwortalter für die Einführung der Richtlinien nicht mehr ganz so hart, denn man kann nun die "Extrem-Accounts" mit Kennwortdaten jenseits der "999" Tage durchaus mit aktuellem Zeitstempel versehen.

Ein Scriptbeispiel gibt es hier: http://www.microsoft.com/technet/scriptcenter/guide/sas_usr_akke.mspx?mfr=true

Jedoch sollte dies erst nach entsprechender Dokumentation des tatsächlichen Kennwortalters erfolgen, so daß man die Benutzer direkt kontaktieren kann. Denn genau diese Benutzer sollten natürlich schnellstmöglich das Kennwort ändern und nicht eine Zeit lang davon "verschont" bleiben.

Phase 4:

In der nun folgenden Phase stellt man nun die Kennwortrichtlinien ein. Hierbei sollten zu Beginn schwache Werte eingesetzt werden.

• So sollte etwa das maximale Kennwortalter auf den Höchstwert „999“ in Tagen gesetzt werden.
• Die Account Lockout Policy sollte noch nicht eingesetzt werden, um keine Account Lockouts aufgrund technischer Probleme in der Migrationsphase zur Kennwortrichtlinie hin zu provozieren (es könnte z.B. der „Account Lockout Treshold“ auf „0“ gesetzt werden).

Kennworthistorie, minimales Kennwortalter, Zeitraum des Warnhinweises zur anstehenden Kennwortänderung und die Kennwortkomplexität können in dieser Phase wie gewünscht gesetzt werden. Sollte es über die Evaluierung in Phase 1 möglich gewesen sein, verschiedene Benutzergruppen in Bezug auf das Kennwortalter zu analysieren, dann kann hier in Gruppen gearbeitet werden. D.h. es wäre möglich, zuerst alle Benutzer mit mehr als „999“ Tagen maximalen Kennwortalters umzustellen – das ist das Mindestalter und die Gruppe, die darüber liegt, kann daher nicht mehr „verkleinert“ werden. Es sei denn, die Benutzer haben ihr Kennwort in Phase 2 schon geändert.

Sind diese Benutzer nun nach einem angemessenen Zeitraum umgestellt und die möglichen Probleme wurden behoben und dokumentiert, kann das maximale Kennwortalter verringert werden. Hier empfiehlt sich eine Auswertung wie in Phase 1, um einen sinnvollen Intervall zu wählen. Der oben genannte „dsquery user –stalepwd“ Befehl kann hier sehr gute Dienste leisten. Vom Ergebnis abhängig (und damit von den betroffenen Benutzern einer Änderung des Kennwortalters) muß dann entschieden werden, welches Kennwortalter eingesetzt werden soll. Sinnvoll ist es hier in kleinen Schritten vorzugehen, etwa 100 Tage oder 200 Tage weniger als „999“ pro Schritt.

Wichtig: Das Warnintervall vor dem Ablauf der Konten solltet Ihr somit recht hoch einstellen (z.B. 114 oder 214 Tage), so dass beim Ändern des maximalen Kennwortalters nicht die Telefone des Helpdesks glühen. Ihr solltet zusätzlich das Datum der Änderung einer Verkürzung per E-Mail oder weiteren Wegen ankündigen, so daß sich Benutzer mit Warnungen von 109 Tagen alten Kennwörtern nicht wundern, aber rechtzeitig aktiv werden.

Phase 5:

In der letzten Phase werden nun die Kennwortrichtlinien bis hin zum SOLL-Wert angezogen. Dies sollte – wie schon in Phase 4 vermerkt – in jedem Fall schrittweise erfolgen und eine Überwachung der Änderungen durchgesetzt werden.

In dieser Phase solltet Ihr auch mit Beschwerden über die „Verrückten in der IT“ rechnen und frustrierten Benutzern am Helpdesk. Davon dürften vor allem die externen und mobilen Benutzer betroffen sein. In den IT-Prozessen solltet Ihr Vorkehrungen treffen, diese Benutzer sicher mit neuen Kennwörtern zu versorgen, z.B. per Rückruf auf das Firmenhandy und Benachrichtigung des Chefs (siehe dazu auch weiter unten).

Es kann dann, nach erfolgreicher Einführung der Grund-Kennwortrichtline, falls gewünscht auch die Account Lockout Policy eingesetzt werden.

Obwohl es nicht Kernpunkt des Blog-Artikels ist, hier ein kurzer Hinweis dazu:

Die Account Lockout Policies werden oftmals viel zu gering gesetzt. So ist ein Wert von 3-5 ungültigen Anmeldeversuchen vor einer möglichen Sperrung meist kontaproduktiv. Es erfolgen bei solch geringen Schwellwerten oft ungewollte Sperrungen, was den administrativen Aufwand (und damit die Kosten) unnötig in die Höhe treibt und zusätzlich eine automatisierte Auswertung der Lockouts im Prinzip unmöglich macht. Sicherheit kann nicht allein durch Kennwortrichtlinien eingesetzt werden, es ist ein Prozess aus einer vielzahl von Maßnahmen und vor allen Dingen der Überwachung dieser Maßnahmen.

Außerdem können Locout Policies die Umgebung auch komplett lahmlegen, da alle Konten gesperrt werden können, wenn ein Angreifer einen DoS-Angriff fährt. Ausnahme ist standardmäßig der erste Domänen-Administrator jeder Domäne, siehe dazu auch: Schutz vor Account Lockouts auch für andere Konten als “Administrator”? http://blogs.technet.com/deds/archive/2008/07/28/schutz-vor-account-lockouts-auch-fuer-andere-konten-als-administrator.aspx .

Es sollte also genau geprüft werden, ob Lockouts tatsächlich eingesetzt werden sollen und falls ja, wie die Prozesse zur Entsperrung eines Accounts aussehen. Hier sollte ebenfalls ein definierter Vorgang geplant sein, etwa durch das Vorzeigen des Ausweises des Betroffenen oder die Entsperrung des Accounts durch einen Vorgesetzten des Betroffenen Benutzer oder ähnliche Vorgehen.

Wir empfehlen bei aktivierten Account Lockouts einen absoluten Minimalwert von 10 ungültigen Anmeldeversuchen in Hochsicherheitsumgebungen – wobei mit eingeschränkter Funktionalität gerechnet werden muß. In normalen Umgebungen empfehlen wir Werte zwischen 20 und 50 ungültigen Anmeldeversuchen, je nachdem, ob ein Überwachung stattfindet oder nicht (bzw. in welcher Form). Siehe dazu auch den “Windows Server 2003 Security Guide:

Table 3.2 Account Lockout Policy Settings

Sollten doch „High Security“ Werte eingesetzt werden, empfiehlt sich auch hier eine schrittweise Anpassung der Einstellungen und nicht die direkte Übernahme der starken Werte.

Mit diesen Grundüberlegungen ist man gut für eine Einführung von Kennwortrichtlinien gerüstet – nichtsdestotrotz sollte man das Vorgehen ausführlich in seiner Testumgebung geprüft haben, bevor man damit produktiv geht. Die Sperrung oder die Anmeldeverweigerung von Benutzern kann ernste Probleme nach sich ziehen, die oft sehr viel Geld kosten.

Viele Grüße
Herbert und Fabian

Start eines neuen Blogs unseres Kollegen Ralf Schnell - "Windows Server Blog"

Hallo zusammen, anbei die kurze Information, daß unser Kollege Ralf Schnell einen neuen deutschsprachigen Blog gestartet hat, der sich rund um das Thema "Windows Server" dreht: Windows Server Blog

Es werden dort auch Kollegen aus verschiedenen Microsoft Bereichen bloggen, so daß sicher der ein oder andere Artikel für Euch interessant sein kann. Ein Blick lohnt sich in jedem Fall. :-)

Zitat Ralf Schnell:

"Dieser Blog bietet Beiträge von Microsoft-Mitarbeitern aus verschiedenen Bereichen: Premier Support, Produkt-Management, Evangelisten. Sie werden Informationen zu allen aktuellen Windows Server-Versionen, zu allen Server-Rollen und -Features und zu sehr unterschiedlichen Aspekten finden, von neuesten Informationen zu unseren Produkten bis hin zu Tipps und Tricks für Administratoren. Jeder Autor schreibt eigenverantwortlich – das bedeutet viele individuell unterschiedliche Schreibstile, mal kürzere und auch mal längere Artikel. Alle Autoren lesen regelmäßig Ihre Kommentare – Sie erreichen also gleichzeitig eine ganze Reihe von Produkt-Experten."

Also, bei Interesse einfach den Feedreader mit dem neuen Blog füttern und interessante Artikel lesen.

Einen ersten Artikel von uns gibt es auch schon dort zu lesen: Aktualisierung von Computer-Gruppenmitgliedschaften bei Domänen Mitgliedern

Viel Spaß,
Fabian