Seit Anfang 2010 ist das Service Pack für ILM 2007 FP1 verfügbar (siehe KB977791, Service Pack 1 (build 3.3.1139.2) is available for Identity Lifecycle Manager 2007 Feature Pack 1, http://support.microsoft.com/default.aspx?scid=kb;EN-US;977791). Es gab etwas Verzögerung beim Release dieses Service Packs die auf einer Änderung des AD MAs beruhte. Ein wesentlicher Punkt des Servicepacks ist die Unterstützung von Exchange 2010, die nun in den Active Directory Management Agenten eingeflossen ist. Diese Unterstützung machte eine Änderung der AD MA Definition notwendig, wodurch aktuelle AD MAs inkompatibel mit älteren ILM Versionen sind. Derzeit werden alle AD MAs und GALSync MAs die in der MicrosoftIdentityIntegrationServer Datenbank defninert sind, automatisch bei der Installation des ILM 2007 FP1 SP1 Updates auf den neuen Stand gebracht. Damit ist ja alles wieder okay und ein problemloser Betrieb weiterhin garantiert.
Doch was ist mit alten Versionen? Alte AD MAs sind wie erwähnt inkompatibel mit der neuen ILM 2007 FP1 SP1 AD MA Definition (mehr Abkürzungen konnte ich kaum hintereinander unterbringen, für die "Identity Lifecycle Manager 2007 Feature Pack 1 Service Pack 1 Active Directory Management Agent Definition" :-)
Wer also nun einen älteren, exportierten AD MA wieder importieren möchte, der wird hier auf ein Problem mit folgender Fehlermeldung stoßen:
"The management agent could not be started as the management agent was configured improperly"
Um aus dieser unschönen Situation wieder heraus zu kommen, muss man wohl oder übel den alten, exportierten MA in einer ILM Version VOR SP1 importieren. Das ist natürlich sehr unschön, aus diesem Grund empfehlen wir unbedingt alle AD bzw GALSync MAs nach der Installation des SP1 zu exportieren um eine neue, zuverlässige Sicherung zu haben.
Sobald wir eine alternative Lösung anbieten können, werden wir diese auch wieder hier veröffentlichen.
Schöne Grüße
Hans-Jürgen
Hallo zusammen, Fabian hier mit einem kurzen Beitrag zum Thema “FRS Replica Sets”. Ab Windows Server 2008 R2 ist es nicht mehr möglich, FRS Replica Sets zu erstellen – das einzig “erlaubte” Replica Set ist das SYSVOL. Für neue Replica Sets / Replication Groups kann nun nur noch DFSR eingesetzt werden.
Fragt man sich nun bei etwaigen Migrationsüberlegungen, welche FRS Replica Sets überhaupt in der AD-Umgebung existieren, gibt es eine ganze Menge Möglichkeiten, diese Sets zu exportieren. Anbei drei “quick and dirty” Export-Möglichkeiten:
- C:\> ntfrsutl sets | findstr /I “computername name partnerdnsname”
ComputerName : DMW2K801
Name : DOMAIN SYSTEM VOLUME (SYSVOL SHARE) (5f669df6-84fc-4169-be3b
a4f7626c49b5)
PartDnsName : dbw2k3r201.child1.forest1.test
PartSrvName : CHILD1\DBW2K3R201$
PartPrincName: CHILD1\DBW2K3R201$
PartDnsName : dbw2k3r201.child1.forest1.test
PartSrvName : CHILD1\DBW2K3R201$
PartPrincName: CHILD1\DBW2K3R201$
PartDnsName : <Jrnl Cxtion>
PartSrvName : <Jrnl Cxtion>
PartPrincName: <Jrnl Cxtion
Dabei ist jedoch zu beachten, daß das Kommando nur die Sets des aktuellen Systems ausgibt. Möchte man mehr Informationen haben (so etwa den Schedule), läßt man den “findstr” Filter einfach weg.
- C:\> dsquery * domainroot –filter “(objectClass=nTFRSMember)” –scope subtree –attr cn fRSMemberReferenceBL
cn fRSMemberReferenceBL
DMW2K801 CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DMW2K801,OU=Domain Controllers,DC=child1,DC=forest1,DC=test
DBW2K3R201 CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DBW2K3R201,OU=Domain Controllers,DC=child1,DC=forest1,DC=test
- C:\> ldifde -d "DC=child1,DC=forest1,DC=test" -r "(|(objectClass=nTFRSReplicaSet)(objectClass=nTFRSMember)(objectClass=nTFRSSubscriber))" -f C:\TEMP\frs.txt -l "cn, frsmemberreferenceBL, frsmemberreference, frsrootpath, objectclass"
dn: CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DMW2K801,OU=Domain Controllers,DC=child1,DC=forest1,DC=test
changetype: add
objectClass: top
objectClass: nTFRSSubscriber
cn: Domain System Volume (SYSVOL share)
fRSRootPath: C:\Windows\SYSVOL\domain
fRSMemberReference:
CN=DMW2K801,CN=Domain System Volume (SYSVOL share),CN=File Replication Service
,CN=System,DC=child1,DC=forest1,DC=test
dn: CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DBW2K3R201,OU=Domain Controllers,DC=child1,DC=forest1,DC=test
changetype: add
objectClass: top
objectClass: nTFRSSubscriber
cn: Domain System Volume (SYSVOL share)
fRSRootPath: C:\WINDOWS\SYSVOL\domain
fRSMemberReference:
CN=DBW2K3R201,CN=Domain System Volume (SYSVOL share),CN=File Replication Servi
ce,CN=System,DC=child1,DC=forest1,DC=test
dn: CN=DMW2K801,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=child1,DC=forest1,DC=test
changetype: add
objectClass: top
objectClass: nTFRSMember
cn: DMW2K801
fRSMemberReferenceBL:
CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DMW2K801,OU=D
omain Controllers,DC=child1,DC=forest1,DC=test
dn: CN=DBW2K3R201,CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=child1,DC=forest1,DC=test
changetype: add
objectClass: top
objectClass: nTFRSMember
cn: DBW2K3R201
fRSMemberReferenceBL:
CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptions,CN=DBW2K3R201,OU
=Domain Controllers,DC=child1,DC=forest1,DC=test
dn: CN=Domain System Volume (SYSVOL share),CN=File Replication Service,CN=System,DC=child1,DC=forest1,DC=test
changetype: add
objectClass: top
objectClass: nTFRSReplicaSet
cn: Domain System Volume (SYSVOL share)
Wie man sieht, geben die Exporte recht unterschiedliche Ergebnisse zurück. Jedoch lassen sich zum Beispiel die LDAP-Filter natürlich problemlos anpassen, zusammenfügen oder erweitern. So bekommt man recht schnell einen Überblick über die bestehenden FRS Replica Sets.
Wer es sich ganz einfach machen möchte, der kann auch FRSDiag nutzen: Hierbei kann eine Liste aller FRS-Systeme übergeben werden (dazu muß man diese Liste jedoch schon haben, etwa über die oben genannten Exporte) und gegen diese Systeme den “Create Connstat” Test fahren lassen. In der dazugehörigen “Connstat.txt” finden sich nach dem Durchlauf dann die Informationen zu FRS-Servern und Ihren jeweiligen Replikationspartnern inkl. der Angabe des Replikationspfades etc.
Die Liste ist wie angesprochen nicht komplett - es gibt diverse andere Methoden, das Ziel zu erreichen. Wenn jemand von Euch noch andere "schnelle Möglichkeiten" kennt, dann immer her damit. Die Kommentarfunktion ist bestens dafür geeignet. ;-)
Viele Grüße
Fabian
Hallo zusammen, Uwe hier aus dem deutschen Microsoft Security Team mit einem Gastbeitrag auf dem „Aktives Verzeichnis“ Blog, der Hinweise geben soll, wie unsere Security Bulletins am besten zu lesen sind.
Diese Bulletins erscheinen jeden 2. Dientag des Monats zum „Patchday“. Da es sich hierbei um ein Blog meiner Active Directory Kollegen handelt, habe ich auch ein passendes Beispiel herausgesucht, in dem Fall MS09-066; eine Sicherheitsanfälligkeit innerhalb von Activie Directory, die ein Denial-of-Service ermöglichen kann. Dieses Bulletin wurde als "Hoch" eingestuft.
Sollte ein Update außerhalb des monatlichen Rhythmus erscheinen, so reden wir von einem “OOB”, also „out of band“ Update. Diese Updates sind immer kritisch eingestuft und sollten so schnell wie möglich installiert werden. Das derzeit letzte bekannte Beispiel war MS08-067 und nun MS10-002.
Damit kommen wir gleich zum ersten Punkt, der Einstufung der Bulletins und welche Kriterien dieser Einteilung zu Grunde liegen. Dies kann man hier nachlesen: http://www.microsoft.com/germany/technet/datenbank/articles/527029.mspx
Zeitgleich sollte man auch die Informationen zum sogenannten „Exploitability Index“ im Auge behalten.
Wenn man nun MS09-066 als Beispiel nimmt, so sieht man folgendes: http://www.microsoft.com/germany/technet/sicherheit/bulletins/ms09-066.mspx
Hieraus geht hervor, daß die Sicherheitsanfälligkeit als “Hoch” eingestuft wurde und es wird eine sehr kurze Beschreibung gegeben.
Als nächstes schaut man sich bestenfalls immer den Abschnitt mit der betroffenen Software an:
Man sieht hier die folgenden Dinge:
- Welches supportete Betriebssystem betroffen ist und welche Komponente davon.
In diesem Fall ist hier von „Active Directory“ und „ADAM“ die Rede. Das Update überprüft während der Installation, ob diese Dienste auf dem Rechner laufen. Wenn nicht, lässt sich das Update nicht installieren.
Als Beispiel: Sie haben einen Memberserver (kein DC, kein ADAM) und wollen dieses Update installieren. Dies schlägt fehl, da die anfälligen Komponenten nicht auf dem Rechner aktiv sind. Sie haben also weniger Rechner zu warten und mit Updates zu betanken.
Sollte irgendwann in der Zukunft dieser Server zu einem Domain Controller hochgestuft werden, sollten Sie einen vollen Update Scan über diesen Rechner laufen lassen.
Warum rollen wir die Updates nicht gleich für alle Systeme aus? Weil schlichtweg eine geringere Downtime eingeplant werden muß, wenn nicht alle Systeme „vorbeugend“ mit den Aktualisierungen versorgt werden. Es werden nur die Systeme versorgt, die die Anfälligkeit tatsächlich aufweisen. Zusätzlich spart das natürlich auch Speicherplatz und Deployment-Tests.
- Was für eine Art der Sicherheitsanfälligkeit das ist.
- Welche Einstufung das Bulletin hat, gemäß obiger Liste.
- Welches Update durch dieses Update ersetzt wird.
Der nächste große Punkt ist die Liste der nicht betroffenen Betriebssysteme. Sollten Sie nur solche Systeme einsetzen ist der Rest pure Neugier, aber Sie haben keinen Handlungsbedarf mehr.
Als nächstes sollte der folgende Punkt näher betrachtet werden:
Hier sind die Detailinformationen zu jeder der in diesem Update betrachteten Sicherheitsanfälligkeiten untergebracht. Man sollte beachten dass hier auch eine längere Liste stehen kann, je nachdem wie viele Anfälligkeiten mit einem Update geschlossen wurden.
Zunächst sollte man die “Häufig gestellte[n] Fragen (FAQ)” lesen, um nähere Informationen zu bekommen, wie ein Angriff theoretisch ausgeführt werden müsste damit er erfolgreich sein könnte. Zusätzlich sind hier generelle Information enthalten die beim Verstehen des Sachverhaltes helfen sollen.
Bei diesem Beispiel:
Worin genau besteht diese Sicherheitsanfälligkeit?
Es handelt sich bei dieser Sicherheitsanfälligkeit um einen Denial-of-Service-Angriff. Ein Angreifer, der diese Sicherheitsanfälligkeit erfolgreich ausnutzt, kann bewirken, dass das betroffene System nicht mehr reagiert und neu gestartet werden muss. Beachten Sie, dass eine Sicherheitsanfälligkeit vom Typ Denial-of-Service einem Angreifer keine Codeausführung oder Erhöhung von Benutzerberechtigungen ermöglicht, sondern dazu führt, dass das betroffene System keine Anforderungen mehr annimmt.
Was ist die Ursache dieser Sicherheitsanfälligkeit?
Der LDAP-Dienst verarbeitet bestimmte LDAP- oder LDAPS-Anforderungen in einer Art und Weise, die zur Auslastung des Stackspeichers führen kann.
Was ist Active Directory?
Der Hauptzweck von Active Directory besteht darin, zentrale Authentifizierungs- und Autorisierungsdienste für Windows-basierte Computer bereitzustellen.
Was ist Active Directory Lightweight Directory Service?
Active Directory Lightweight Directory Services (AD LDS) ist ein unabhängiger Modus von Active Directory, der dedizierte Verzeichnisdienste für Anwendungen bereitstellt. AD LDS ist unter Windows Server 2008 und höher verfügbar und ersetzt Active Directory Application Mode (ADAM), welcher unter Windows XP und Windows Server 2003 verfügbar war.
Was ist LDAP?
Lightweight Directory Access-Protokoll (LDAP) ist ein Standard eines offenen Netzwerkprotokolls, das Zugriff auf verteilte Verzeichnisse bereitstellen soll.
Was ist LDAP über SSL? (LDAPS)?
Standardmäßig wird LDAP-Datenverkehr ungesichert übertragen. Es ist jedoch möglich, LDAP-Datenverkehr mittels SSL-Technologie (Secure Sockets Layer)/TLS-Technologie (Transport Layer Security) vertraulich zu machen und gegen Änderungen zu schützen. Administratoren können LDAP über SSL (LDAPS) aktivieren, indem sie ein ordnungsgemäß formatiertes digitales Zertifikat von einer Microsoft-Zertifizierungsstelle oder einer Nicht-Microsoft-Zertifizierungsstelle entsprechend den Richtlinien im Microsoft Knowledge Base-Artikel 321051 installieren.
Ist LDAP über SSL standardmäßig verfügbar?
Nein. Bevor ein LDAP-Server sich an einer SSL-Sitzung beteiligen kann, muss der Administrator ein digitales Zertifikat erhalten und auf dem Server installiert haben. Wenn dies nicht gegeben ist, ist LDAP über SSL nicht verfügbar.
Wie kann ich feststellen, ob mein Server den LDAP-Dienst ausführt, wenn ich Active Directory verwende?
Um festzustellen, ob ein Server bereit ist, LDAP- oder LDAPS-Abfragen zu empfangen, führen Sie den folgenden Befehl über eine administrative Eingabeaufforderung aus, und stellen Sie fest, ob das System den LDAP-Port (389) oder den LDAPS-Port (636) bzw. einen der Ports des globalen Katalogdienstes (3268 oder 3269) abhört:
netstat –a
LDAP ist aktiviert, wenn die Ergebnisse eine der folgenden Angaben enthalten:
Proto Local Address Foreign Address State
TCP 0.0.0.0:389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:636 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3268 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3269 0.0.0.0:0 LISTENING
[…]
Wichtig ist das noch zu wissen, ob diese Anfälligkeit bevor sie geschlossen wurde der Öffentlichkeit bekannt war.
War diese Sicherheitsanfälligkeit zum Zeitpunkt der Veröffentlichung dieses Security Bulletins bereits öffentlich bekannt?
Nein. Microsoft erhielt Informationen über diese Sicherheitsanfälligkeit durch verantwortungsvolle Offenlegung.
Lagen Microsoft zum Zeitpunkt der Veröffentlichung dieses Security Bulletins Informationen vor, dass diese Sicherheitsanfälligkeit bereits ausgenutzt wurde?
Nein. Microsoft lagen zum Zeitpunkt der Erstveröffentlichung dieses Security Bulletins keine Informationen vor, dass diese Sicherheitsanfälligkeit öffentlich für Angriffe auf Benutzer ausgenutzt wurde.
Wenn Sicherheitsfirmen uns eine potentielle Anfälligkeit nennen, ohne das diese öffentlich bekannt wird, und uns Zeit einräumen, diese zu schließen, dann nennt man das „responsible disclosure“.
Als nächstes schaut man die 2 weiteren Punkte an, „Schadensbegrenzende Faktoren“ und „Problemumgehungen“. Dies ist gedacht für den Fall der Fälle, daß man das Update nicht sofort ausrollen kann, aber sich dennoch vor einer potentiellen Ausnutzung schützen will.
Diese Vorschläge zur Problemumgehung, sollte man immer mit Vorsicht genießen, da bei falscher Umsetzung auch negative Auswirkungen auftreten können. Wir empfehlen immer die Installation des Updates.
Die nächste Sektion ist vor allem für Umgebungen interessant, die keine Microsoft Lösung zum Update Management einsetzen, wie zum Beispiel SCCM oder WSUS:
Im ersten Teil unter „Tools und Anleitungen zur Erkennung der Bereitstellung“ kann man erkennen welche unserer Tools in der Lage sind das Update als installiert oder fehlend zu erkennen.
Im zweiten Teil sieht man welche Möglichkeiten der manuellen Installation man hat und zur Überprüfung der erfolgreichen Installation für jedes einzelne betroffene Betriebssystem, hier aufgezeigt für Windows Server 2003.
- Der erste markierte Bereich zeigt die Möglichkeiten auf, wie man dieses Update ohne Benutzerinteraktion installiert. Dies kann zum Beispiel bei einer geskripteten Verteilung von Nutzen sein.
- Der zweite markierte Bereich zeigt, welche Möglichkeiten man hat, um dieses konkrete Update ohne Neustart zu installieren, etwa da die Server momentan online bleiben müssen.
- Hierbei sollte man den dritten markierten Bereich beachten, ob ein Neustart erforderlich ist. Ist dieser Neustart erorderlich, ist der Schutz vor der Anfälligkeit (auch bei Ausnutzung der Installationsmethodik unter Punkt 2) erst nach dem Neustart gegeben. Solange das System nicht neu gestartet wurde, ist die Anfälligkeit weiterhin gegeben.
- Der 4. Punkt zeigt auf, wo man Informationen über die Dateiversionen bekommt, so etwa für den Fall, daß eine „Third-Party“ Lösung zum Update Management genutzt wird. Hier benötigt man diese Informationen um zu verifizieren, daß das Update auf einem Rechner installiert ist.
- Der 5. Punkt zeigt zusätzliche Informationen zur manuellen Überprüfung einer erfolgreichen Installation auf.
Damit sollten Sie in der Lage sein die Informationen eines Bulletins zu interpretieren.
Eine gute Quelle für weitere technische Informationen sind folgende englische Blogs:
Ich persönlich empfehle die englischen Bulletins zu lesen, da diese am aktuellsten sind.
Viel Vergnügen bei der Lektüre zukünftiger Sicherheitsupdates.
Cheers,
Uwe
Hallo zusammen, Fabian hier. Ab und an erreichen uns Fragen zum Export von privaten Schlüsseln, etwa von Benutzerzertifikaten – hier wundern sich die CA-Administratoren bzw. CA-Manager, daß der private Schlüssel eines Zertifikats am Client exportiert werden kann, obwohl dies im Template nicht erlaubt wurde:
Beispiel: UserSignatureNoKeyExportTemplate auf einer CA
Der Export auf einem Client ist trotz gegenteiliger Template-Einstellung möglich
Im Normalfall handelt es sich bei den Konstellationen, in denen diese Fragestellung auftritt, nicht um per Autoenrollment erzeugte Zertifikate, sondern um ein Enrollment mittels Windows Server 2003 Web-Enrollment, “certreq.exe” Anforderungen oder aber sehr häufig seit Windows Vista um ein MMC Enrollment.
Spätestens sehr “sichtbar” ab Windows Vista / Windows Server 2008 gibt es nämlich im Vergleich zu WIndows XP / 2003 weit mehr Möglichkeiten, einen Zertifikat-Request mittels MMC zu beeinflussen. Die MMC Dialoge bieten seit Vista / 2008 die Option, fast alle Einstellungen eines Zertifikatrequests mittels GUI zu verändern. So also auch das Erlauben des “private key export”:
Wird die Option “Make private key exportable” nun wie im Beispiel oben über die MMC oder aber "certreq.exe" bzw. über das Windows Server 2003 Web-Enrollment gesetzt, überschreibt diese Request-Einstellung die Template-Einstellung – schließlich wird der Zertifikatrequest auf dem Client erstellt und somit auch der private Schlüssel auf dem Client erzeugt als auch vorgehalten und nicht etwa auf der CA. Die Option des privaten Schlüsselexports wird also auf dem Client gespeichert und nicht von der CA festgelegt.
Die CA stellt “lediglich” anhand des Zertifikat-Requests den öffentlichen Schlüssel (also auch das Zertifikat) aus und versieht es mit den notwendigen Informationen. Diese Informationen stammen teils aus dem Request, teils sind es Informationen, die nur die CA angeben kann / darf.
Der Request eines Benutzers für ein Zertifikat und das dazugehörige private Schlüsselmaterial steht somit also nur auf dem Client zur Verfügung, auf dem der Request erzeugt wurde (außer es werden Roaming Profiles bzw. Credential Roaming eingesetzt). Man findet Benutzer-Requests, die noch nicht durch die CA-Manager bzw. CA-Administratoren freigegeben wurden, auf einem Client an folgender Stelle: %SYSTEMROOT%\Users\<BENUTZERNAME>AppData\Roaming\Microsoft\SystemCertificates\Request\Certificates
Einen solchen Request und seine Optionen kann man sich recht einfach über die MMC oder aber per “certutil.exe” anzeigen lassen (folgend ein Ausschnitt der certutil-Ausgabe):
C:\Users\Administrator>certutil -v -store -user REQUEST
REQUEST
================ Certificate 0 ================
X509 Certificate:
Version: 3
Serial Number: 4295939833ac3d944d6e06e719adebdc
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Issuer:
EMPTY
NotBefore: 26.01.2010 12:27
NotAfter: 26.01.2011 12:47
Subject:
EMPTY
[…]
Certificate Extensions: 7
1.3.6.1.4.1.311.21.7: Flags = 0, Length = 2d
Certificate Template Information
Template=UserSignatureNoKeyExportTemplate(1.3.6.1.4.1.311.21.8.1352962.8
910182.8211339.1268024.15973616.87.7443111.594514)
Major Version Number=100
Minor Version Number=3
2.5.29.37: Flags = 0, Length = 16
Enhanced Key Usage
Client Authentication (1.3.6.1.5.5.7.3.2)
Secure Email (1.3.6.1.5.5.7.3.4)
2.5.29.15: Flags = 1(Critical), Length = 4
Key Usage
Digital Signature (80)
[…]
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): 57 f9 8a 70 27 14 f7 2d 67 e0 a8 e2 28 74 4d 90 db 42 08
1b
Key Id Hash(sha1): bc 0f 58 9b 8d cc 9f d9 3f cf 1d 29 00 30 2c ea 9d 6c f8 83
Cert Hash(md5): d9 fc 45 e0 2b 5e 30 78 d3 1f 56 c0 a7 d5 c6 c8
Cert Hash(sha1): c2 0a bb 27 41 74 dd f9 f1 f7 a0 44 46 2a 29 2a 03 f0 66 89
[…]
CERT_KEY_PROV_INFO_PROP_ID(2):
Key Container = 8a37c5692f3f73f2a2f903e9fb1a16e7_0ef9a270-4d27-4249-b4fc-e4b
516462828
Simple container name: le-UserSignatureNoKeyExportTemplate-e170b062-d436-4660-
b0ff-4f140ff849ab
Provider = Microsoft Enhanced Cryptographic Provider v1.0
ProviderType = 1
Flags = 0
KeySpec = 2 -- AT_SIGNATURE
CERT_SHA1_HASH_PROP_ID(3):
c2 0a bb 27 41 74 dd f9 f1 f7 a0 44 46 2a 29 2a 03 f0 66 89
Simple container name: le-UserSignatureNoKeyExportTemplate-e170b062-d436-4660-
b0ff-4f140ff849ab
PP_KEYSTORAGE = 1
CRYPT_SEC_DESCR -- 1
KP_PERMISSIONS = 3f (63)
CRYPT_ENCRYPT -- 1
CRYPT_DECRYPT -- 2
CRYPT_EXPORT -- 4
CRYPT_READ -- 8
CRYPT_WRITE -- 10 (16)
CRYPT_MAC -- 20 (32)
[…]
Private Key:
PRIVATEKEYBLOB
Version: 2
aiKeyAlg: 0x2400
CALG_RSA_SIGN
Algorithm Class: 0x2000(1) ALG_CLASS_SIGNATURE
Algorithm Type: 0x400(2) ALG_TYPE_RSA
Algorithm Sub-id: 0x0(0) ALG_SID_RSA_ANY
0000 52 53 41 32 RSA2
0000 ...
048c
Signature test passed
CertUtil: -store command completed successfully.
Den entscheidenden Hinweis auf den möglichen Export des privaten Schlüssels liefert und das oben im Request angegebene Flag “CRYPT_EXPORT -- 4”. Siehe dazu CryptGetKeyParam http://msdn.microsoft.com/en-us/library/ee497956.aspx
CRYPT_EXPORT Allows exporting of the key
Somit ist nach der Erstellung des Zertifikats durch die CA und das Zuordnen des Zertifikats zum privaten Schlüssel auf dem Client auch der Export des privaten Schlüssels möglich. Das Verhalten ist dementsprechend so gewünscht bzw. “by design”.
Führt man den Vorgang mittels Autoenrollment durch, anstatt eine manuelle Beantragung vorzunehmen, werden aufgrund der fehlenden eigenen Angaben zum privaten Schlüsselexport die Template Einstellungen genutzt – in unserem Beispiel oben also der Export des privaten Schlüssels unterbunden.
Viele Grüße
Fabian
Das SP1 für ILM 2007 wurde fertig gestellt und wird in Kürze öffentlich verfügbar sein, Es gibt einige Problemlösungen im Service Pack, doch der wichtigste Effekt des SP1 ist sicherlich die Lösung des "Upgrade Problems" bei ILM. Mit den ILM HotFixes hat sich leider eine Problematik eingeschlichen, das man nicht mehr beliebig von unterschiedlichen Build Versionen auf die nächste Version upgraden konnte. ILM 2007 FP1 hat die Versionsnummer 3.3.0118, das Service Pack 1 bringt ILM 2007 auf den Versionsstand 3.3.1139.2. Zwischenzeitlich traten bei verschiedenen Hotfixes Probleme auf, das neuere Hotfixes nicht installiert werden konnten. Man musste hier erst auf die Version 3.3.1087.2 zurück gehen und erst danach konnte man wieder upgraden. Dazu wurden im Problemfall teilweise auch Komplett Builds von ILM ausgeliefert, die nach dem Setup gleich als Version 3.3.1087.2 installiert waren. Darauf konnte man dann wieder nornmal upgraden. Auch wir empfanden dies natürlich als einen unsäglichen Zustand.
Gelöst wurde dies nun endlich mit dem ersehnten SP1, hiermit geht der Upgrade wieder normal und ich konnte in meinen Tests auch keine Problemkonstellation ausfindig machen, die ein vernünftiges Upgrade nicht zuließ. Das SP1 setzt mindestens Build 3.3.0118 vorraus, also ILM 2007 FP1.
Anders als z.B. in der Windows Produkt Gruppe empfehlen wir bei ILM in der Regel immer das aktuellste Update einzusetzen, somit wird mit dem SP1 dies ganz klar die von uns empfohlene Version die eingesetzt werden sollte. Wer noch ältere Versionen im Einsatz hat, bitte genau überlegen was davon abhält einen Umstieg auf ILM 2007 SP1 durchzuführen.
Wie alle Microsoft Hotfixes ist auch das ILM SP1 kumulativ, also alles was schon früher in Hotfixes bzw. Rollup Packages eingeflossen ist, ist auch hier im SP1 enthalten. Und noch ein kleines bisschen mehr. Hier ein kurzer Überblick über weitere Problmee die im SP1 gelöst wurden:
- Eine Exception bei "Unblock a user's smartcard"
- Ein Fehler "CLM has encountered an error while trying to change Smart Card PIN.CLM Self Service Control is not installed" beim Reset der Smartcard PIN auf einem Vista 64-bit Computer
- Ein Fehler "The security ID structure is invalid" wenn ein Approver oder Initiator von einem Workflow gelöscht wurde
- AD Management Agenten unterstützen nun remote Exchange 2010 Powershell
Das sind die wesentlichen Neuerungen durch das SP1, in Kürze als KB977791 verfügbar.
Tschau
Hans-Jürgen
Bernd hier mit einer sehr kurzen Meldung. Ich bin gerade über folgendes gestolpert, als ich auf einem Windows 7 System für Group Policy Troubleshooting das Debug Logging aktivieren wollte:
Ich habe wie gewohnt, den Registry Wert GPSvcDebugLevel gesetzt (siehe auch den Knowledgebase Artikel 944043 ganz unten), gpupdate /force ausgeführt und habe dann ins c:\windows\debug Verzeichnis gewechselt. Hier fiel mir auf, dass
- der Ordner usermode nicht exisitert
- und damit auch das dort eigentlich erwartete gpsvc.log nicht vorhanden war
Die Lösung:
Der Code produziert weiterhin das gpsvc.log – allerdings erst dann, wenn man den Ordner usermode manuell auch noch mit anlegt.
Ich hoffe, das erspart einigen die Schrecksekunde und Schweißausbrüche.
Bernd :-)
Hi! Hier ist wieder Florian, wie versprochen mit dem zweiten Teil des Gastbeitrags (*) für den deds-Blog. Nachdem wir uns im ersten Teil um das Präpopulieren der Passwörter und die Password Replication Policy gekümmert haben, soll es in diesem zweiten Teil um Änderungen an den Passwörtern gehen und wie RODCs mit abgelaufenen Geheimnissen und Benutzern umgehen, die ihr Passwort ändern möchten.
Ein Passwort zurücksetzen
Ein RODC erfährt – wie alle anderen Domänencontroller – nur von Änderungen, wenn er sich über die Replikation von einem Server 2008-DC im Hauptstandort auf den neuesten Stand bringt. Passwörter werden jedoch speziell kommuniziert: Anstatt das Passwort nach einer Änderung vollständig zu replizieren, holt sich der RODC nur die Information, dass das Passwort geändert wurde. Der bisherige, gecachete Passwordhash des Benutzers wird auf dem RODC als „absent“, also „nicht vorliegend“, kennzeichnet. Faktisch wird die Information, in welchem Speicherblock das Passwort des Benutzers abgelegt ist, überschrieben. Somit ist das bisherige, nun veraltete Passwort nicht mehr erreichbar. Das neue Passwort wird, obwohl die Password Replication Policy es vielleicht erlaubt, vorerst nicht auf dem RODC geändert. Der RODC besitzt zu diesem Zeitpunkt kein gültiges Passwort des Benutzers in seinem Cache.
Beim Versuch der Authentifizierung mit dem neuen Passwort muss der RODC Kontakt mit dem Domänencontroller im Hauptstandort aufnehmen und ihn die Authentifzierung durchführen lassen. Erst wenn eingegebener Benutzername und Passwort korrekt eingegeben wurden und die Authentifizierung vollzogen wurde, repliziert der RODC das Passwort des Benutzers und cacht es – vorausgesetzt die PRP erlaubt dies.
Dieses Verhalten ist identisch mit einer normalen Benutzerauthentifizierung, die wir im ersten Teil kennengelernt haben. Dort wird das Benutzerpasswort (oder Computerpasswort) auch noch nicht auf dem RODC zwischengespeichert. Der RODC muss Kontakt zum Hauptstandort-DC aufnehmen und von ihm die Authentifizierung durchführen lassen.
Erst zu diesem Zeitpunkt versucht der RODC, das Passwort vom Hauptstandort-Domänencontroller zu replizieren und zwischenzuspeichern. Wie bereits bekannt, wird hierfür ebenfalls die Single Object Replication angewandt.
Das Passwort läuft ab
Benutzerkennwörter laufen nach dem in der Passwortrichtlinie bestimmten maximalen Kennwortalter ab. Dann müssen Benutzer ihre Passwörter ändern.
Versucht ein Benutzer sich an einem RODC anzumelden, obwohl sein Passwort abgelaufen ist, leitet der RODC die Anmeldeanfrage an seinen Hauptstandort-DC weiter, der die Authentifizierung analysieren soll. Obwohl der RODC die Evaluation und den Prompt nach Passwortänderung selbst durchführen könnte, rückversichert er sich:
Mit der Antwort „STATUS_PASSWORD_EXPIRED“ wird folgend die Meldung angezeigt, dass das Passwort abgelaufen ist und es geändert werden muss. Die Passwortänderung besteht aus dem aktuellen Passwort und der Eingabe des neuen Passworts in doppelter Form, um Tippfehler auszuschließen. Der Client benötigt für die Passwortänderung ein Kerberos-Ticket für den kadmin/passwd-Dienst, das der Hauptstandort-DC, über den RODC geleitet, vermittelt. Mit dem Ticket für den KPASSWD-Dienst steht der Passwordänderung nichts mehr im Weg – die Pakete finden ihr Ziel abermals über den RODC am Hauptstandort.
Konnte das Passwort erfolgreich geändert werden, wird am Client nun die „Das Passwort wurde erfolgreich geändert“-Meldung zu sehen. Gleichzeitig versucht der RODC, das neu erstellte Passwort vom Domänencontroller zu replizieren – schließlich hat es sich geändert und der Cache ist nicht mehr aktuell. Auch hier kommt die Single Object Replication für das Einspielen der Änderung zum Einsatz. Findet die SOR erfolgreich statt, kann sich der Benutzer wie gehabt anmelden. Scheitert die Passwortreplikation auf den RODC, weil gerade in diesem Moment die Verbindung zwischen den Standorten zusammenbricht, wird die Passwortreplikation nicht abgeschlossen. Die Folge: das Passwort muss bei der nächsten Authentifizierung wieder über den schreibbaren Domänencontroller im Hauptstandort verifiziert werden, um eine erneute SOR zu versuchen.
Der Benutzer ändert sein Passwort
Ändern Benutzer auf freiwilliger Basis ihre Passwörter (löst dieses Statement nicht bei allen von uns ein kleines Kichern aus?), können die beiden Szenarien unterschieden werden:
a. Passwortänderung im Hauptstandort
Das Passwort wird an einem schreibbaren Domänencontroller geändert und dann per normaler Replikation vom RODC repliziert. Der RODC setzt daraufhin das lokal zwischengespeicherte Passwort auf „nicht vorliegend“ und muss, sollte sich der Benutzer das nächste Mal anmelden, die Anmeldeanfrage an den RWDC leiten. Bei Erfolg versucht der RODC dann das Passwort per SOR vom Domänencontroller zu replizieren und es in seinen Cache aufzunehmen.
b. Passwortänderung in der Zweigestelle am RODC
Für die Passwortänderung von Benutzern an Zweigstellen muss eine Unterscheidung getroffen werden: verschiedene Versionen von Windows verhalten sich hier unterschiedlich. Windows XP-Clientcomputer versuchen stets, Passwortänderungsanfragen direkt an einen schreibbaren Domänencontroller zu senden. Eine erfolgreiche Passwortänderung an Hauptstandort-DC wird dann per geplanter Replikation zum RODC getragen.
Neuere Clients, wie etwa Windows Vista oder Windows 7 wenden sich vertrauensvoll an den RODC im eigenen Standort, der auch diese Anfrage an den schreibbaren DC chained. Über die Kette gelangt der Client an das Passwort – woraufhin auch in diesem Fall der RODC per SOR das neue Passwort anfordert.
Ist die WAN-Verbindung nicht verfügbar, scheitert das Vorhaben in beiden Fällen direkt.
Zusammenfassung
In Kurzform nochmals die Erkenntnisse dieses zweiteiligen Artikels:
- Ein RODC cacht Passwörter, wenn es die PRP zulässt
- Werden Passwort erneuert oder geändert und ein RODC erfährt davon per Replikation, wird er, falls das betreffende Passwort zuvor gecacht war, die gecachte Kopie auf den Status „nicht vorliegend“ setzen.
- Um mit RODCs Erfolg zu haben, sollte man bei der für die Zwischenspeicherung erlaubten Konten unbedingt auch an Computer, nicht nur an Benutzer denken. Zwischengespeicherte Benutzerpasswörter allein reichen für eine Authentifizierung (ohne WAN-Verbindung) nicht aus.
- Passwortänderungen (egal ob durch ein Zurücksetzen oder vom Benutzer initiiert), die vom RODC zu einem schreibbaren DC gechained werden, versucht der RODC bei Erfolg per Single Object Replication zu replizieren und in seinem Cache abzulegen.
- Geänderte Passwörter landen nur erneut im Cache des RODCs, wenn sich der Benutzer mit dem neuen Passwort anmeldet.
- Für Passwort-Änderungen ist stets eine Verbindung zwischen RODC und RWDC notwendig – zum Zeitpunkt des Anmeldens des Benutzers oder bei der eigentlichen Passwortänderung (jeweils aus dem RODC-Standort heraus).
- Auf dem RODC zuvor populierte Passwörter werden nicht automatisch erneut in den Cache des RODCs geschrieben – dies muss manuell oder über die hier beschriebenen Methoden geschehen (Replikation der Änderung, SOR).
Abschließend bleibt nur noch ein Hyperlink zu einem TechNet-Artikel, den jeder, der sich mit RODCs beschäftigt, unbedingt durchlesen sollte: „Appendix A: RODC Technical Reference Topics“, http://technet.microsoft.com/en-us/library/cc754218(WS.10).aspx
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.
Hi! Heute schreibt Florian, ein MVP-Award-Träger aus dem süddeutschen Raum nahe der Grenze zur Schweiz. Diesmal soll es in einem zweiteiligen Gastbeitrag (*) für den Blog des deutschen AD-Teams um Passwörter und deren Speicherung und Verarbeitung auf Read-Only Domänencontrollern gehen.
Read-Only-Domänencontroller, wir werden sie im folgenden mit RODC abkürzen, wurden mit Windows Server 2008 eingeführt. Entgegen der Meinung einiger Mitglieder diverser Internetforen sind RODCs nicht die Reinkarnation von Backup-Domänencontrollern (BDC) aus den „guten, alten“ NT-Zeiten. Vielmehr sind RODCs die Antwort auf Szenarien mit problematischen Standorten – physikalischer sowie topologischer Natur. Einen Überblick über RODCs gibt der folgende TechNet-Artikel: http://technet.microsoft.com/en-us/library/cc732801(WS.10).aspx sowie das RODC-Deployment Guide: http://technet.microsoft.com/en-us/library/cc771744(WS.10).aspx.
In diesem und einem folgenden Beitrag wollen wir uns speziell mit Passwörtern auf RODCs beschäftigen. Per Voreinstellung werden nämlich keine Passwörter auf RODCs gespeichert – das entspricht auch der Haltung, dass RODCs per se auf Grund ihrer Einsatzszenarien erstmal als „unsicher“ eingestuft werden. Anmeldungen werden stets an einen Windows Server 2008-Domänencontroller weitergeleitet, der daraufhin die Authentifizierung vornimmt und die entsprechenden Kerberos-Tickets für die Authentifizierung und den Zugriff auf weitere Dienste ausstellt. Der RODC spielt hierbei maximal „Proxy“ zwischen dem DC in der Hauptstelle und dem Client. Die Authentifizierungsanfragen werden somit „gechained“.
Um Passwörter auf einem RODC zwischenzuspeichern, gibt es zwei Möglichkeiten: das Präpolulieren der Passwörter, sodass der RODC die Passwörter einiger Benutzer und Computer bereits gespeichert hat und Authentifizierungen selbstständig übernehmen kann, sowie das Erlauben des Zwischenspeicherns von Passwörtern nach erfolgreicher Anmeldung unter Verwendung der Password Replication Policy (PRP).
Soll ein RODC Passwörter von Benutzer oder Computern zwischenspeichern, damit sie bei späteren Anmeldungen lokal verifiziert werden können und somit den WAN-Link schonen, muss die Password Replication Policy angepasst werden. Die PRP besteht prinzipiell aus zwei Gruppen, die das Cache-Verhalten von RODCs mitbestimmen: die „Allowed RODC Password Replication Group“ und die „Denied RODC Password Replication Group“. Die Mitgliedschaft in einer dieser beiden Gruppen signalisiert dem Domänencontroller im Hauptstandort, ob ein Benutzerpasswort auf Anfrage per Single Object Replication an einen RODC gesendet werden darf. Passwörter von Mitgliedern der „Denied RODC Password Replication Group“, dies sind meist administrative Konten und Gruppen wie Domänen-Admins, Enterprise-Admins oder Schema-Admins, werden nie zum RODC repliziert. Passwörter von „Allowed RODC Password Replication-Group“-Mitgliedern werden auf Anfrage zum zum RODC repliziert – per Vorgabe ist diese Gruppe allerdings leer.
Die Anfrage wird erzeugt, wenn Benutzer oder Computer unter anderem mit der Hilfe des schreibbaren Domänencontrollers im Hauptstandort authentifiziert wurden.
Um die Authentifizierung an einem RODC zu verstehen, benötigen wir einige Grundlagen zu Kerberos – und einen Netzwerksniffer wie Wireshark oder Netmon. Die beiden Tools können frei aus dem Internet heruntergeladen werden, für die Kerberos-Grundlagen sorgt http://technet.microsoft.com/en-us/library/bb742516.aspx.
Benutzer und Computer richten ihre Anmeldeanfrage und den damit verbundenen Request nach einem Kerberos-Ticket-Granting-Ticket (TGT) an den RODC, der sich im selben Standort befindet und ihnen vom DCLocator-Prozess zugewiesen wurde.
Möchte ein Benutzer sich authentifizieren und für einige in der Site verfügbare Dienste ein Dienst-Ticket erhalten, wendet er sich zuerst an den RODC. Der RODC, hemdsärmelig, wie er eben gerade ist, kann die erhaltene Anfrage (das AS-REQ-Paket) des Client nicht selbstständig auswerten, da das Passwort vom Benutzer bisher nicht gecacht wird. Die Anfrage wird kurzerhand an einen schreibbaren Server 2008-DC im Hauptstandort weitergeleitet (gechained):
Wird die Anfrage korrekt beantwortet und der RODC erhält die Antwort des schreibbaren DCs, sendet er die Antwort an den Client zurück. Gleichzeitig versucht er, das Passwort des gerade authentifizierten Benutzers zwischenzuspeichern. Er sendet eine Single-Object-Replication (SOR)-Anfrage an den 2008-DC, der daraufhin die PRP prüft, ob das Geheimnis des Accounts auf dem RODC zwischengespeichert werden darf. Ist die Zwischenspeicherung erlaubt, wird das Geheimnis repliziert – außerhalb der normalen Replikation:
Hinweis: die USN des Benutzerobjektes für den RODC wird bei der Single Object Replication nicht geändert, sodass das geänderte Benutzerpasswort bei der nächsten, geplanten Replikation nochmals übertragen wird und dann „offiziell“ repliziert wird.
Im nächsten Schritt wird der Client ein Dienstticket anfordern, um beispielsweise einen Webserver in seinem Standort erreichen zu können. Per TGS-REQ versucht er erneut, beim RODC ein entsprechendes Ticket zu erhalten. Der RODC muss wieder passen, obwohl er das Benutzerpasswort zwischengespeichert hat. Der Grund ist, dass das TGT, das zuvor vom Hauptstandort-DC ausgestellt wurde, mit seinem Passwort verschlüsselt wurde. Das Verschlüsselungspasswort ist das des krbtgt-Accounts, das sich zwischen schreibbaren- und RODCs unterscheidet. Um also an ein gültiges Dienstticket zu kommen, muss der RODC die Anfrage also erneut „chainen“.
Bei der (erfolgreichen) Antwort des Standort-DCs wendet der RODC einen pfiffigen Trick an: Anstatt dem Benutzer das Dienstticket einfach auszustellen, gaukelt er ihm vor, dass sein TGT zurückgezogen wurde (KRB5KDC_ERR_TGT_REVOKED). Der Client muss daraufhin sein TGT und anschließend sein Dienstticket erneut anfordern. Dies ist die Chance des RODC! Nun kann er den Client, da er das Geheimnis kennt, selbstständig authentifizieren und ihm anschließend ein Dienstticket für den Webserver ausstellen – ohne den schreibbaren DC jenseits der WAN-Strecke zu bemühen. Den Client freut’s!
Die zweite Möglichkeit, das Präpopulieren von Passwörtern, ist über mehrere Wege möglich. Ziemlich versteckt befindet sich ein entsprechender Dialog in „Active Directory Benutzer und Computer“. In den Eigenschaften des Computerobjektes des RODCs befindet sich ein Reiter „Password Replication Policy“, über den per Klick auf „Advanced“ der Dialog „Advanced Password Replication Policy for <RODC-Name>“ aufgerufen wird. In diesem Dialog lassen sich per Dropdown-Menü Accounts anzeigen, deren Passwörter auf dem RODC zwischengespeichert werden – oder Accounts, die sich schonmal an diesem RODC angemeldet haben. Unser Augenmerk gilt aber nun dem Button „Prepopulate Passwords...“. Es können nur Passwörter von Accounts vorgespeichert werden, die auch per PRP für das Cachen auf einem RODC zugelassen sind – Mitglieder der „Deny RODC Password Replication Group“ können nicht vorgespeichert werden.
Wurde der entsprechende Benutzer ausgewählt, warnt das System mit folgendem Dialog:
Für eine erfolgreiche Anmeldung reicht das Populieren von BenutzerPasswörtern nicht aus. Computer müssen sich beim Start ebenfalls an Active Directory authentifizieren, um einen sicheren Kanal zum Domänencontroller aufbauen zu können. Kommt dieser sichere Kanal nicht zu stande, können keine Benutzer authentifiziert werden. Es ist also notwendig, dass auch die Computerkonten der Maschinen, an denen Benutzer offline arbeiten sollen, ebenfalls vorgespeichert werden.
Wer Wartungs- und Provisioningskripte anpassen will, kann das mit Hilfe von repadmin tun – repadmin lässt mit dem Schalter /rodcpwdrepl Passwort von der Kommandozeile aus auf RODCs speichern. Der Befehl
repadmin /rodcpwdrepl rodcr2 2008r2 „CN=Tina Maier,OU=Stuttgart,DC=contoso,DC=com“
populiert Tinas Passwort automatisch auf den RODC.
Der Unterschied der beiden Methoden sollte klar geworden sein: Während das Präpopulieren der Passwörter das Passwort direkt auf den RODC repliziert, sodass das Geheimnis dort gespeichert wird, sorgt die PRP nur dafür, dass, sollte sich der Benutzer irgendwann tatsächlich am RODC anmelden wollen, das Passwort zwischengespeichert wird, wenn der Authentifizierungsprozess vom schreibbaren Domänencontroller in der Hauptstelle durchgeführt wurde. Im ersten Fall ist das Passwort sofort auf dem RODC in gecachter Form verfügbar, im zweiten Fall wird es nach der ersten Authentifzierung zwischengespeichert.
Nun, da die Geheimnisse von Benutzern und Computern auf dem RODC liegen, müssen wir uns die Frage stellen, wie sich der RODC bei Passwortänderungen oder dem Zurücksetzen von Passwörtern verhält. Um dem Verhalten auf die Spur zu gehen, werden wir auch im zweiten Teil den Netzwerkverkehr auf dem RODC protokollieren. Der zweite Teil erscheint nächste Woche auf diesem Blog.
Bis dann!
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.
Hallo, Bernd hier. Diese Woche war bei mir die Woche der Profile. Keine Ahnung warum, aber ab und an häufen sich Themen ohne ersichtlichen Grund. Diesmal: Warum werde ich in Vista und Windows 7 manchmal mit einem temporären Profil angemeldet während XP einfach mein servergespeichertes Profil nutzt? Etwas zum Hintergrund:
Allgemein bekannt sein dürfte, dass das Profil eines Benutzers eine Sammlung von Dateien, Einstellungen und Registrierungsdateien – zusammengefasst in einem Profilordner - ist. Sagen wir mal, diesem hier:
C:\Users\BENUTZER\ [in Windows Vista bzw. Windows 7]
C:\Documents and Settings\BENUTZER\ [in Windows XP]
Weniger bekannt ist, dass jeder Rechner, auf dem ein Benutzer sich anmeldet, auch eine Information über die gerade auf seiner Festplatte befindlichen Profilkopien speichert. Ein Registrierungsschlüssel mit der SID des Benutzers
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-4259982270-434397305-3615631142-1121\
enthält neben einigen weiteren Informationen eben auch den Pfad zum lokalen Profilordner. Dieser Schlüssel wird gelöscht, sobald über das UI oder via Gruppenrichtlinie die lokale Kopie eines Profils gelöscht wird.
Bei der Anmeldung eines Benutzers wird nun in diesem Registryschlüssel nach der SID des Nutzers gesucht – und, wenn vorhanden, seine lokale Profilkopie über den dort gespeicherten Pfad gesucht. Diese wird dann mit der servergespeicherten Kopie abgeglichen – Ergebnis: der Nutzer hat die aktuellsten Daten in seiner Session, seinem Profil zur Verfügung.
Beide Teile der (lokalen) Profilkopie gehören untrennbar zusammen – fehlt eine, haben wir eine inkonsistente Situation, die seit Windows Vista anders aufgelöst wird, als noch in Windows XP.
Wenn unter Windows XP der Ordner gelöscht, der Registryschlüssel aber auf dem System belassen wurde, ging XP davon aus, dass nur noch der Ordner lokal angelegt und der Inhalt der servergspeicherten Version kopiert werden musste. Damit waren dann auch beide Teile der lokalen Kopie wieder vorhanden. Dies funktionierte auch in den meisten der Fälle – wer allerdings schon einmal Profilordner im Format
C:\Users\BENUTZER.0001
C:\Users\BENUTZER.0002
C:\Users\BENUTZER.0003
auf seinen Systemen vorgefunden hat, weiß, dass diese Strategie zur automatischen Problemlösung nicht immer aufgegangen ist. Hier war der orignale Ordner nicht gelöscht worden, sondern auf ihn konnte zum Anmeldezeitpunkt nicht zugegriffen werden. Zugriffsverletzungen, geänderte Berechtigungen, etc. – teilweise nur temporärer Natur – führen unter XP dazu, dass wir einen neuen lokalen Ordner erstellen – der Eintrag in der Profilelist zeigt dann eben auf den neuen
Ordner. Gerade in Terminalserver Umgebungen führt dies unter Umständen schnell zu einem Platzproblem.
In Windows Vista und Windows 7 wurde dieses Verhalten geändert. Nun wird im Falle einer inkonsistenten Situation nicht eine weitere lokale Kopie des Profils angelegt, sondern die verbleibende Komponente gesichert (hier ein Auszug aus dem Profil-Debug Log)
[profsvc]Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-4259982270-434397305-3615631142-1121 renamed to S-1-5-21-4259982270-434397305-3615631142-1121.bak.
und bis zur Klärung durch einen Administrator der Benutzer mit einem Temporären Profil angemeldet.
Gleichzeitig werden zwei Events im Eventlog geschrieben:
Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: 09.12.2009 13:15:06
Event ID: 1515
Task Category: None
Level: Error
Keywords:
User: CHILD1\BENUTZER
Computer: DMW701.child1.forest1.test
Description:
Windows has backed up this user profile. Windows will automatically try to use the backup profile the next time this user logs on.
Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: 09.12.2009 13:15:06
Event ID: 1511
Task Category: None
Level: Error
Keywords:
User: CHILD1\BENUTZER
Computer: DMW701.child1.forest1.test
Description:
Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.
Bei jeder weiteren Anmeldung wird Windows Vista bzw. Windows 7 den Schlüssel mit der Endung .bak wieder umbenennen und prüfen, ob der lokale Ordner mit der NTUSER.DAT inzwischen wieder zur Verfügung steht bzw. zugreifbar ist.
[profsvc]Checking Local Profile ...
[profsvc]Backup key Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-4259982270-434397305-3615631142-1121.bak restored.
[profsvc]Expanded local profile image path = <C:\Users\BENUTZER>
Wenn dies der Fall ist, wird dieses Profil genutzt und der Ordner mit der servergspeicherten Kopie abgeglichen. Sollte er allerdings weiterhin nicht verfügbar sein, greift wieder der oben beschriebene Mechanismus – umbenennen in .bak und anmelden mit einem temporären Profil. Dies wird sich wiederholen, bis ein Administrator die Situation geklärt und bereinigt hat:
- Sollte kein lokaler Ordner vorhanden sein, muss der Schlüssel (.bak) aus der Profilelist entfernt werden
- Sollte der lokale Ordner vollständig vorhanden sein, muss geprüft werden, ob z.B. die Rechte auf den Ordner korrekt sind, der Besitzer korrekt ist bzw. kein anderer Prozess Dateien im Profil exklusiv im Zugriff hält.
Dies sorgt zwar im ersten Moment für mehr Arbeit für den Administrator, stellt aber sicher, dass individuell auf die verschiedenen Ursachen reagiert wird (werden kann) anstatt eine “Lösung” über all diese unterschiedlichen Probleme zu stülpen: einfach eine neue Kopie des Benutzerprofils anzulegen.
Ich hoffe, das bringt etwas Licht in diese beiden KB Artikel, an denen sich die meisten Fragen in dieser Woche aufgehängt hatten:
http://support.microsoft.com/kb/947242
http://support.microsoft.com/kb/947215
Bernd “der jetzt in den Urlaub verschwindet” Puchtinger
Wie schon mal vor rund einem Jahr von mir beschrieben (http://blogs.technet.com/deds/archive/2008/10/21/group-policy-preferences-einsatz-bei-folder-options.aspx) gibt es ein paar Schwierigkeiten mit dieser an sich eigentlich tollen Option „Apply Once“. Viele werden schon wissen, daß es dazu mittlerweile einen Hotfix gibt (http://support.microsoft.com/kb/970974/de), der das Problem löst.
Jedoch - auch dieser Hotfix bereitet vielen Anwendern Probleme. Leider ist daran wohl in erster Linie der KB Artikel verantwortlich, der die Lösung nicht ausführlich genug beschreibt. Eine Änderung für den KB Artikel ist bereits auf dem Wege, doch trotzdem möchte ich die Gelegenheit nutzen die Problematik näher zu erklären.
Im Abschnitt „Prerequisites“ wird als Systemvorraussetzung Windows Vista SP1 bzw. SP2 genannt. Was hier fehlt ist der Hinweis auf die Remote Server Adminstration Tools (RSAT, http://support.microsoft.com/default.aspx?scid=kb;EN-US;941314 ), die ebenfalls erforderlich sind. Ungewöhnlich, damit wären die RSAT Tools auf allen Clients erforderlich? Ein großer Aufwand diese zusätzlich auszurollen. Doch hier ist man einem Trugschluß aufgesessen. Dieser Hotfix ist ein rein „Administrativer Hotfix“ der nicht auf den Client PCs sondern auf dem Computer installiert werden muss, wo die Group Policy Objekte erstellt werden, also entweder auf einem Windows 2008 Server oder auch auf einer Admin Workstation auf der die notwendigen RSAT Tools installiert sind.
Damit ist auch schon die Wirkungsweise des Hotfixes klar. Wie Patrick Gotsch sehr gut erklärt hat (siehe http://blogs.technet.com/deds/archive/2009/07/24/ein-mal-und-nie-wieder-gp-preferences-apply-once-option.aspx ), werden die Group Policy Preferences in einer XML Datei angelegt und diese auf dem Client von den Client Side Extensions ausgewertet. Dieser Hotfix korrigiert nun die XML Datei bei der Erstellung, daher muss der Hotfix auch nur dort installiert werden wo Group Policy Objekte verwaltet werden und auch die XML Datei muss auch neu angelegt werden, also durch eine neue GPO oder durch neue Preferences in einer bestehenden GPO.
Ich hoffe, damit sind alle Hindernisse beseitigt um das wirklich gute Feature „Apply once“ nutzen zu können.
Tschau, Hans-Jürgen
Hi,
Sogenannte „nested folders“ zu deutsch verschachtelte Ordner, können nicht in unterschiedlichen Replikationstopologien repliziert werden. Das ist nicht supported, kann darüber hinaus aber auf normalem Wege (z.B. DFS Management Konsole) auch gar nicht eingerichtet werden.
Beim Einrichten erhält man folgenden Fehler:
Hier ein Beispiel, damit man es sich besser vorstellen kann:
Was wäre ein „verschachtelter Replizierter Ordner“ ?
Angenommen wir haben drei Server S1, S2 und S3.
Replikationsgruppe RG1 besteht aus den Servern S1 und S2.
Replikationsgruppe RG2 besteht aus den Servern S2 und S3.
Server S2 ist also Mitglied in zwei verschiedenen Replikationsgruppen.
Auf S1 und S2 gibt es ein Verzeichnis V1 mit einem Unterverzeichnis Sub.
V1 inkl. alle seine Unterverzeichnisse wird in der RG1 im Replizierten Ordner RF1 repliziert.
Wenn nun in der RG2 ein Replizierter Ordner RF2 angelegt wird, der das Verzeichnis „Sub“ replizieren soll, hätten wir eine Verschachtelung.
Denn Sub wird ja auch schon in RG1 als Unterordner von V1 repliziert.
Ein kleiner Beitrag zu einer Frage, die ab und zu auftaucht.
Gruß
Barbara
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:
- 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!
- 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.
- 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.
- 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
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
![CLI312_Kleef[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEuropeTag4_E894/CLI312_Kleef%5B1%5D_3.jpg "CLI312_Kleef[1]")
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 David A. Solomon ist Arbeitgeber von Daniel Pearson.
Viele Grüße
Fabian
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.
![CLI322_Cooke[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag3_12F47/CLI322_Cooke%5B1%5D_3.jpg "CLI322_Cooke[1]")
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.
![PB110001[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag3_12F47/PB110001%5B1%5D_3.jpg "PB110001[1]")
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. ;-)
![PB110002[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag3_12F47/PB110002%5B1%5D_3.jpg "PB110002[1]")
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.
![SVR307_Woolsey[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag3_12F47/SVR307_Woolsey%5B1%5D_3.jpg "SVR307_Woolsey[1]")
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
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.
![PB100013[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/PB100013%5B1%5D_3.jpg "PB100013[1]")
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
![PB100017[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/PB100017%5B1%5D_3.jpg "PB100017[1]")
![PB100019[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/PB100019%5B1%5D_3.jpg "PB100019[1]")
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.
![PB100021[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/PB100021%5B1%5D_5.jpg "PB100021[1]")
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.
![PB100022[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/PB100022%5B1%5D_3.jpg "PB100022[1]")
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):
![ITS206_Gullotto[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/ITS206_Gullotto%5B1%5D_3.jpg "ITS206_Gullotto[1]")
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.
![PB100029[1]](http://blogs.technet.com/blogfiles/deds/WindowsLiveWriter/TechEdEurope2009Tag2_B1F7/PB100029%5B1%5D_3.jpg "PB100029[1]")
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
