Die Zukunft von WindowsVerzeichnisdienste in Windows Server „Longhorn“

Byron Hynes

Dieser Artikel basiert auf einer Vorabversion von Windows Server mit dem Codenamen „Longhorn“. Änderungen an allen Informationen in diesem Artikel sind vorbehalten.

Mit der nächsten Windows Server-Version mit dem Codenamen „Longhorn“ werden einige Active Directory-Verbesserungen bereitgestellt. Einige dieser Änderungen sind wichtig und bieten interessante neue Möglichkeiten zur besseren Verwaltbarkeit und Effizienz. Eine der offensichtlichsten Änderungen in Active Directory ist die Benennung von Funktionen. Alle Funktionen, die sich auf die Identitätsverwaltung beziehen, sind nun unter dem Active Directory®-Banner zusammengefasst. Was früher in Microsoft® Windows Server® 2003 als Active Directory bezeichnet wurde, ist nun Active Directory Domain Services (ADDS) und bietet eine Reihe von weiteren Diensten wie Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS, früher Active Directory/Application Mode oder ADAM), Active Directory Certificate Services (ADCS) und Active Directory Rights Management Services (ADRMS).

Jeder einzelne Dienst repräsentiert eine Serverrolle, was ein neues Konzept in Windows Server „Longhorn“ darstellt. Sie können Computer für eine oder mehrere Serverrollen dedizieren und Serverrollen mit dem in Abbildung 1 dargestellten Server-Manager verwalten. Hier können Sie Rollen hinzufügen, Hilfe suchen und andere erforderliche Verwaltungsaufgaben durchführen.

Figure 1** Server-Manager **(Klicken Sie zum Vergrößern auf das Bild)

Bei diesem neuen Ansatz werden tägliche Funktionen in logische Gruppen zusammengefasst, die über Server-Manager zugänglich sind.

Funktionsebenen

Windows Server „Longhorn“ führt eine neue Funktionsebene für Gesamtstrukturen und Domänen ein. Die Funktionsebene für die Windows Server „Longhorn“-Gesamtstruktur (die bei Freigabe der Version einen neuen Namen erhält) fügt selbst keine zusätzlichen Funktionen hinzu, stellt jedoch sicher, dass sich alle Domänen in einer Gesamtstruktur auf der Windows Server „Longhorn“-Domänenfunktionsebene befinden, die zwei neue Erweiterungen ermöglicht. Bei der ersten handelt es sich um die Verwendung des neuesten DFS (Distributed File System)-Replikationsmoduls für die SYSVOL-Freigabe, die robuster, präziser und effizienter ist. Bei der zweiten handelt es sich um die erweiterte Unterstützung für die 256-Bit-AES (Advanced Encryption Standard)-Verschlüsselung für das Authentifizierungsprotokoll Kerberos. Verwenden der neuesten Funktionsebene bietet höchste Leistung, Sie können jedoch weiterhin auf niedrigeren Funktionsebenen arbeiten, wenn Sie auf Windows Server „Longhorn“ migrieren.

Eine Reihe von Schemaerweiterungen zur Unterstützung mehrerer Funktionen wurde ebenso eingeführt. Sie sind alle mit derzeit gebräuchlichen Schemas kompatibel. Domänencontroller, auf denen Windows Server „Longhorn“ ausgeführt wird, können problemlos neben solchen, auf denen Windows Server 2003 ausgeführt wird, betrieben werden.

Unterstützung für Server Core

Bei den Active Directory-Domänendiensten handelt es sich um eine Serverrolle, die in einer Server Core-Installation von Windows Server „Longhorn“ eingesetzt werden kann. Bei der Funktion Server Core, die in diesem Artikel nur am Rande behandelt wird, handelt es sich um die Mindestinstallationsoption, wobei lediglich die Hauptserverfunktionalität erhalten bleibt. Bei Server Core wird die Windows-Shell nicht installiert, und es wird keine grafische Benutzeroberfläche verwendet, sodass einiges an Aufwand eingespart wird.

Read-Only-Domänencontroller

In einigen Umgebungen handelt es sich bei der wichtigsten Funktion für ADDS in Windows Server „Longhorn“ um den Read-Only-Domänencontroller (RODC), mit dem Sie einen Domänencontroller bereitstellen können, der als Host für ein schreibgeschütztes Replikat der Domänendatenbank dient. Dies eignet sich besonders für Standorte, an denen die physische Sicherheit des Domänencontrollers nicht gewährleistet werden kann oder an dem andere Anwendungen auf dem Domänencontroller ausgeführt und von einem Serveradministrator verwaltet werden müssen (der idealerweise nicht der Domänen-Admins-Gruppe angehört). Beide Situationen kommen häufig bei einer Bereitstellung in Zweigstellen vor.

Der Read-Only-Domänencontroller wird einfach durch Aktivieren eines Kontrollkästchens im Installations-Assistenten installiert (siehe Abbildung 2).

Figure 2** Read-Only-Domänencontroller wird installiert **(Klicken Sie zum Vergrößern auf das Bild)

Vor der Freigabe von Windows Server „Longhorn“ musste der Verkehr über eine WAN-Verbindung geleitet werden, falls Benutzer sich bei einem Domänencontroller an einem anderen Standort authentifizieren mussten. WAN-Verbindungen sind häufig langsamer und teurer als LAN-Verbindungen und manchmal anfälliger für Ausfälle. Bei einer der möglichen Lösungen handelte es sich um die Bereitstellung eines Domänencontrollers am zentralen Standort oder an der Zweigestelle. Dies führte jedoch zu anderen Problemen, wie Replikationsverkehr und die Notwendigkeit, die physische Sicherheit des Domänencontrollers an der Zweigstelle zu gewährleisten, was in kleinen und dezentralen Zweigstellen häufig nicht der Fall ist. Zum Teil führen schlechte Netzwerkbandbreiten, die Zweigstellen in ihren Verbindungen zu einem Hub verwenden, zu längeren Anmeldezeiten bei diesem Site.

Mit der Ausnahme von Kontokennwörtern (es sei denn der Controller wurde ausdrücklich anders konfiguriert) verfügt ein RODC über alle Objekte und Attribute der Active Directory-Domänendienste, über die ein beschreibbarer Domänencontroller verfügt. Lokale Änderungen können jedoch nicht an dem Replikat, das auf dem RODC gespeichert ist, vorgenommen werden. Änderungen werden stattdessen auf einem beschreibbaren Domänencontroller vorgenommen und zurück auf den RODC repliziert. Dadurch wird verhindert, dass Änderungen, die an einem Zweigstellenstandort vorgenommen werden, die Gesamtstruktur durch Replikation unter Umständen stören oder beschädigen können, wodurch eine Angriffsmöglichkeit eliminiert wird.

Lokale Anwendungen, die Lesezugriff für die Domänenverzeichnisinformationen anfordern, können direkt über den RODC zugreifen, während LDAP (Lightweight Directory Access Protocol)-Anwendungen, die Schreibzugriff anfordern, eine LDAP-Weiterleitungsantwort erhalten. Über die Weiterleitungsantwort werden sie an einen beschreibbaren Domänencontroller und nicht einen Hub geleitet.

Da keine Änderungen direkt auf den RODC geschrieben werden, werden am RODC keine Änderungen erstellt. Daher müssen beschreibbare Domänencontroller, die Replikationspartner sind, keine Änderungen vom RODC abrufen. Dadurch wird die Arbeitslast von Bridgeheadservern im Hub und der Aufwand zur Überwachung von Replikationen reduziert. Die unidirektionale RODC-Replikation gilt sowohl für die ADDS- als auch die DFS-Replikation. Der RODC führt eine herkömmliche eingehende Replikation für ADDS- und DFS-Replikationsänderungen durch.

In der Domänendatenbank verfügt jedes Sicherheitsprinzipal über einen Satz an 10 Kennwörtern, die als Anmeldeinformationen bezeichnet werden. Ein RODC speichert keine Benutzer- oder Computeranmeldeinformationen, außer dem eigenen Computerkonto und einem gesonderten „krbtgt“-Konto (das Konto, das für die Kerberos-Anmeldung verwendet wird) für jeden RODC. Der RODC wird als Schlüsselverteilungscenter (Key Distribution Center, KDC) für den Standort (in der Regel eine Zweigstelle) bekannt gegeben. Wenn der RODC eine TGT-Anfrage signiert oder verschlüsselt, verwendet er ein anderes krbtgt-Konto als das Schlüsselverteilungscenter auf dem beschreibbaren Domänencontroller.

Wenn ein Konto zum ersten Mal versucht, sich bei einem RODC zu authentifizieren, sendet der RODC die Anfrage an einen beschreibbaren Domänencontroller im Hub. Wenn die Anmeldung erfolgreich ist, fordert der RODC eine Kopie der entsprechenden Anmeldeinformationen an. Der beschreibbare Domänencontroller erkennt, dass die Anfrage von einem RODC kommt und berücksichtigt die Richtlinie zur Kennwortreplikation, die für den jeweiligen RODC gilt.

Die Richtlinie zur Kenntwortreplikation legt fest, ob die Anmeldeinformationen repliziert und auf dem RODC gespeichert werden dürfen. Wenn dies der Fall ist, sendet ein beschreibbarer Domänencontroller die Anmeldeinformationen an den RODC, und der RODC speichert diese im Cache (siehe Randleiste zur Arbeitsweise eines Read-Only-Domänencontrollers).

Nachdem die Anmeldeinformationen auf dem RODC im Cache gespeichert wurden, kann die Anfrage beim nächsten Anmeldeversuch des Benutzers direkt vom RODC bearbeitet werden, bis sich die Anmeldeinformationen ändern. Wenn eine TGT-Anforderung mit dem RODC-eigenen krbtgt-Konto signiert ist, erkennt der RODC, dass er über eine Kopie der Anmeldeinformationen im Cache verfügt. Wenn ein anderer Domänencontroller die TGT-Anforderung signiert hat, leitet der RODC die Anfrage an einen beschreibbaren Domänencontroller weiter.

Durch die Einschränkung der Cache-Speicherung von Anmeldeinformationen für Benutzer, die sich bereits zuvor beim RODC authentifiziert haben, ist die potenzielle Offenlegung der Anmeldeinformationen durch eine Gefährdung des RODC ebenfalls eingeschränkt.

Standardmäßig werden keine Benutzerkennwörter im Cache eines RODC gespeichert. Dies ist jedoch nicht die effizienteste Lösung. Im Vergleich zur Gesamtzahl der Benutzer einer Domäne müssen in der Regel nur wenige Domänenbenutzer Anmeldeinformationen im Cache eines RODC speichern. Sie können die Richtlinie zur Kennwortreplikation verwenden, um festzulegen, welche Benutzergruppen für die Zwischenspeicherung überhaupt in Betracht kommen. Das Risiko der potenziellen Offenlegung kann verringert werden, indem Sie zum Beispiel die RODC-Zwischenspeicherung auf Benutzer beschränken, die sich häufig in der Zweigstelle aufhalten, oder die Zwischenspeicherung wichtiger Anmeldeinformationen, z. B. von Administratoren, verhindern.

Daher müssen im Falle eines Diebstahls oder sonstiger Beschädigung des RODC lediglich die Anmeldeinformationen zurückgesetzt werden, die sich im Cache befinden. Im Weiteren wird ausführlich behandelt, um welche Konten es sich hierbei handelt (siehe Abbildung 3).

Figure 3** Zwischengespeichterte Kontoinformationen **(Klicken Sie zum Vergrößern auf das Bild)

Administratorrollentrennung

In zahlreichen Zweigstellen übernehmen Domänencontroller weitere Serverrollen oder Aufgaben, z. B. die Funktion als Datei- oder Druckserver. In anderen Fällen wird eine Line-Of-Business-Anwendung notgedrungen auf einem Domänencontroller installiert. Hierdurch entsteht ein Problem: Um diese Anwendungen und Server zu verwalten, muss ein Mitarbeiter der Zweigstelle über Administratorzugriffsrechte verfügen. Und jeder Benutzer, der einen Windows Server 2003-Domänencontroller verwalten kann, kann auch die gesamte Domäne verwalten.

In Windows Server „Longhorn“ kann einem Administrator lediglich die Zugriffsberechtigung zum Verwalten eines bestimmten RODC erteilt werden, ohne ihm/ihr den Zugriff für die Verwaltung anderer Domänencontroller zu erteilen und ohne dass er/sie unnötigerweise Mitglied der Sicherheitsgruppe Domänen-Admins wird.

Verbesserungen der Benutzeroberfläche und Tools

Zur Unterstützung der Funktionen eines RODC und zur einfacheren Überwachung der Kennwortreplikation wurde auf der Eigenschaftenseite eines Domänencontrollers in Active Directory-Benutzer und -Computer eine neue Registerkarte mit der Richtlinie zur Kennwortreplikation hinzugefügt (siehe Abbildung 4).

Figure 4** Registerkarte mit der Richtlinie zur Kennwortreplikation **(Klicken Sie zum Vergrößern auf das Bild)

Durch Klicken auf die Schaltfläche „Erweitert“ auf der Registerkarte können Sie anzeigen, welche Kennwörter an den RODC gesendet wurden und welche Konten sich beim RODC authentifiziert haben (siehe Abbildung 5). Da die Liste Konten enthält, die authentifiziert wurden, können Sie – auch wenn die Konten nicht zu der Gruppe gehören, deren Kennwörter repliziert werden dürfen – diese Informationen verwenden, um festzulegen, welche Gruppen in die Richtlinie für die Kennwortreplikation aufgenommen werden sollen.

Figure 5** Erweiterte Richtlinie zur Kennwortreplikation **(Klicken Sie zum Vergrößern auf das Bild)

Es wurden einige Änderungen am Dienstprogramm „dcpromo“ vorgenommen, das unter dem Namen Assistent zum Installieren von Active Directory-Domänendiensten bekannter ist. Der Assistent kann als eine vollständige grafische Anwendung gestartet werden, indem der Befehl zum Hinzufügen von Rollen auf der Seite „Initial Configuration Tasks“ (ICT) ausgewählt wird, die umgehend nach der Installation des Betriebssystems ausgeführt wird. Wählen Sie im Server-Manager den Befehl zum Hinzufügen von Rollen und anschließend „ADDS“ aus, oder rufen Sie „dcpromo“ über eine Befehlszeile oder über den Befehl „Ausführen“ aus.

Sobald Sie den Assistenten im Grafikmodus verwenden, können Sie eine bessere Organisation der Elemente und Auswahlen feststellen, da zusammengehörige Elemente in Gruppen zusammengefasst werden. Es stehen auch mehr Optionen zur Verfügung. Sie können auf den erweiterten Modus von der Benutzeroberfläche zugreifen, ohne dass die /adv-Option zum Durchführen von Aufgaben wie Erstellen einer neuen Domänenbaumstruktur, Installieren von einem Datenträger (zur Reduzierung der anfänglichen Replikation über ein WAN) oder Auswählen des Quellendomänencontrollers für die anfängliche Replikation verwendet werden muss.

Es wurden einige Verbesserungen vorgenommen, mit denen dem Benutzer die Arbeit erleichtert und ärgerliche Fehler verhindert werden können. Wenn Sie den Assistenten z. B. zum Erstellen eines neuen Domänencontrollers in einer vorhandenen Domäne oder Gesamtstruktur verwenden, können Sie nach vorhandenen Domänen suchen, statt den NetBIOS-Namen eingeben zu müssen.

Es wurden neue Seiten hinzugefügt, die über zusätzliche Optionen verfügen, mit denen der Domänencontroller als globaler Katalogserver, DNS-Server oder als RODC konfiguriert werden kann. Im Assistenten können Sie auch die Standortauswahl konfigurieren, Funktionsebenen einrichten, Richtlinien zur Kennwortreplikation für RODCs erstellen und DNS-Delegation konfigurieren.

Als Befehlszeilentool kann dcpromo selbstständig ausgeführt werden. Im Gegensatz zu dem gleichen Tool in Windows Server 2003 ist bei einer unbeaufsichtigten Installation eine Antwort des Benutzers auf Eingabeaufforderungen der Benutzeroberfläche, wie beim Neustart des Computers, nicht erforderlich. Dadurch wird die Verwendung von ADDS auf Server Core-Installationen von Windows Server „Longhorn“ einfacher.

ADDS-Überwachung

Microsoft fügt der Überwachung von Verzeichnisdiensten in Windows Server „Longhorn“ wesentlich mehr Funktionalität hinzu. In Windows Server 2003 kann die Überwachung für den Verzeichniszugang entweder ein- oder ausgeschaltet werden, doch selbst wenn die vollständige Erfolgsüberwachung aktiviert ist, enthält die Überwachungsliste keine Informationen zu Änderungen. Jetzt enthält sie solche Informationen.

In Windows Server „Longhorn“ verfügt die Überwachungsrichtlinie für ADDS über die folgenden vier Unterkategorien:

• Verzeichnisdienstzugriff
• Verzeichnisdienständerungen
• Verzeichnisdiesntreplikation
• Detaillierte Verzeichnisdienstreplikation

Für die meisten professionellen IT-Mitarbeiter gibt es zwei wichtige Faktoren zu diesen Änderungen: Die Überwachung für den Verzeichnisdienstzugriff bietet im Grunde genommen die gleichen Informationen wie unter Windows Server 2003, die Ereignis-ID ändert sich jedoch von 566 zu 4662. Notieren Sie sich diese Änderung, wenn Sie Tools zum Analysieren des Sicherheitsereignisprotokolls verwenden. Die neue Kategorie Verzeichnisdienständerungen erfasst sowohl den vorherigen als auch den aktuellen Wert des geänderten Attributs.

Zum Implementieren der Überwachung in ADDS werden die globale Überwachungsrichtlinie (Global Audit Policy, GAP), Systemzugriffssteuerungslisten (System Access Control Lists, SACL) und das ADDS-Schema verwendet. Die Komponenten arbeiten zusammen, um einen flexiblen und umfassenden Überwachungsrahmen zu bieten.

Mit der GAP wird gesteuert, ob eine Überwachung für ADDS durchgeführt wird. Wenn die Überwachung aktiviert ist, steuert die GAP, welche der vier Unterkategorien für den Zugriff (die weiter oben aufgeführt wurden) überwacht werden. Die globale Richtlinie für die Überwachung wird in der Regel im Objekt für die Standardgruppenrichtlinie für Domänencontroller angewendet und gilt daher für das gesamte Verzeichnis auf dem Domänencontroller.

Obwohl mit den Tools für die Gruppenrichtlinien die GAP ein- oder ausgeschaltet werden kann, muss das Befehlszeilentool Auditpol.exe verwendet werden, um die Unterkategorien anzuzeigen oder zu konfigurieren. Diese sind nicht in der grafischen Benutzeroberfläche verfügbar.

Bei einer SACL handelt es sich um einen Teil eines Sicherheitsdeskriptors für ein Objekt. Durch die Angabe von Einträgen in einer SACL werden dem System zwei Dinge mitgeteilt: welche Aktionen und Benutzer (oder Sicherheitsprinzipale) Ihnen wichtig sind. Das heißt, Sie legen fest, welche Benutzer und welche Aktionen, die diese Benutzer versuchen durchzuführen, im Ereignisprotokoll aufgenommen werden sollen. Wenn Sie dann Änderungen an Benutzerobjekten aufnehmen möchten, die von Domänenadministratoren, nicht jedoch vom Benutzer selbst vorgenommen werden, können Sie dies über die Systemzugriffssteuerungslisten steuern. Eine SACL ist für ein Objekt gültig (und kann für neue Objekte definiert und von Containerobjekten vererbt werden).

Sie können das ADDS-Schema auch so konfigurieren, dass die Überwachung von Änderungen auf bestimmte Attribute beschränkt wird. Da Systemzugriffssteuerungslisten standardmäßig für das Objekt angewendet werden, werden Zugriffe oder Änderungen für Attribute aufgenommen. Dies kann zu sehr hoher Protokollierungsaktivität führen, und manche Attribute sind für Sie unter Umständen uninteressant. Daher können Sie auf Attributebene ein Flag setzen, mit dem verhindert wird, dass Änderungen protokolliert werden.

Bei SearchFlags handelt es sich um ein Attribut, das in der Klasse definiert ist, die Attribute definiert, d. h. ein Attribut eines Attributs. Hierbei handelt es sich auch um eine Bitmaske, bei der jedes Bit eines Ein-Byte-Werts eine unterschiedliche Ein/Aus-Einstellung repräsentiert. Es ist unter Umständen einfacher, sich dies als Eigenschaft eines Attributs vorzustellen. In Windows Server 2003 werden sieben dieser Werte verwendet, um unterschiedliche Einstellungen zu steuern, einschließlich des Indizierens und der GC-Replikation des Attributs. In Windows Server „Longhorn“ wird das achte Bit (mit einem Wert von 128) verwendet, um zu steuern, ob Änderungen protokolliert werden. Wenn das Bit gesetzt ist, protokolliert ADDS keine Änderungsereignisse, wenn Änderungen an einem Attribut vorgenommen werden. Dies gilt für alle Objekte, die das Attribut enthalten. In Beta 2 können Sie die grafische Benutzeroberfläche nicht verwenden, um das achte Bit zu setzen.

In Windows Server „Longhorn“ ist die globale Überwachungsrichtlinie standardmäßig eingeschaltet und Verzeichnisdienständerungen so eingestellt, dass erfolgreiche Änderungen protokolliert werden.

Neu startbares ADDS

In Windows Server „Longhorn“ handelt es sich bei ADDS um einen Dienst, der neu gestartet werden kann. Das heißt, dass die ADDS-Dienste angehalten und wieder gestartet werden können, ohne dass der Domänencontroller neu gestartet werden muss. Dadurch können Administratoren Funktionen, die während der Ausführung des Diensts nicht verfügbar sind (z. B. eine Offline-Defragmentierung der Datenbank) leichter ausführen, und ohne dass der Wiederherstellungsmodus für die Verzeichnisdienste aufgerufen werden muss.

Es gibt drei verschiedene Zustände für einen Domänencontroller unter Windows Server „Longhorn“: ADDS gestartet, ADDS beendet und Wiederherstellungsmodus für Verzeichnisdienste. Im Folgenden werden die einzelnen Zustände beschrieben.

ADDS gestartet Der Domänencontroller arbeitet ordnungsgemäß.

ADDS beendet Der Server verfügt sowohl über Merkmale eines Domänencontrollers im Wiederherstellungsmodus für Verzeichnisdienste als auch eines Mitgliedservers, der über eine Domäne verbunden ist.

Wie auch beim Wiederherstellungsmodus für Verzeichnisdienste ist die ADDS-Datenbank (Ntds.dit) offline. Das Kennwort für den Wiederherstellungsmodus für Verzeichnisdienste kann verwendet werden, um sich lokal anzumelden, wenn ein anderer Domänencontroller nicht für die Anmeldung verfügbar ist.

Wie beim Mitgliedsserver ist auch dieser Server über die Domäne verbunden. Benutzer können sich interaktiv oder über das Netzwerk anmelden, indem ein anderer Domänencontroller für die Anmeldung bei der Domäne verwendet wird. Ein Domänencontroller sollte jedoch nicht für einen längeren Zeitraum über diesen Zustand verfügen, da er dann keine Anmeldeanfragen bedienen und keine Replikation mit anderen Domänencontrollern durchführen kann.

Wiederherstellungsmodus für Verzeichnisdienste Dieser Modus (oder Zustand) wurde im Vergleich zu Windows Server 2003 nicht geändert.

Im Flussdiagramm in Abbildung 6 wird dargestellt, wie ein Domänencontroller, auf dem Windows Server „Longhorn“ ausgeführt wird, zwischen diesen drei möglichen Zuständen hin- und herwechseln kann.

Figure 6** Ein Domänencontroller in Windows Server 'Longhorn' kann zwischen drei Zuständen hin- und herwechseln **

Sie hätten gern weitere Informationen?

Leider ist es nicht möglich, alle neuen ADDS-Funktionen in Windows Server „Longhorn“ in einem Artikel ausführlich zu behandeln. Die neuen Active Directory-Funktionen werden jedoch eine Reihe von Problemen lösen, mit denen Sie sich früher umständlich auseinandersetzen oder einfach abgeben mussten. Da die Freigabe der endgültigen Version immer näher rückt und weitere Informationen gewünscht werden, möchten wir Ihnen versichern, dass wir eine zusätzliche Dokumentation veröffentlichen werden. Im Moment erhalten Sie alle aktuellen Informationen während der Betaphase auf der Website Windows Server „Longhorn“.

Byron Hynes arbeitet im Windows Server User Assistance-Team bei Microsoft. Zuvor arbeitete er als Berater und Trainer und verfügt über weitläufige Erfahrung unter anderem in der Leitung eines regionalen Internetbackbones, in der Fehlerbehebung für Client-Server- und webaktivierten Anwendungen sowie im Entwurf von Datenbankschemas, Netzwerkinfrastrukturen und Sicherheitsmodellen. Er ist zu erreichen unter bhynes@microsoft.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.