Active Directory

Erläuterungen zur Proxyauthentifizierung in AD LDS

Ken St. Cyr

Auf einen Blick:

• Definieren der Proxyauthentifizierung
• Der Nutzen der Proxyauthentifizierung
• Einblick in das Proxyobjekt
• Das Geschehen während der Authentifizierung

Inhalt

Was ist die Proxyauthentifizierung?
Vorteile der Proxyauthentifizierung
Einblick in das Proxyobjekt
Durchführung der Authentifizierung
Einrichten einer Testumgebung für die Proxyauthentifizierung
Schlussbemerkung

Wie bei jedem LDAP-fähigen Verzeichnisdienst erfordert Microsoft Active Directory Lightweight Directory Services (AD LDS, früher ADAM genannt) vor dem Ausführen von LDAP-Vorgängen für das Verzeichnis eine Benutzerbindung. Diese Bindung kann durch verschiedene Methoden erfolgen, einschließlich einer einfachen LDAP-Bindung, einer SASL-Bindung (Simple Authentication and Security Layer) oder auch einer Bindungsumleitung. Die Bindung könnte auch anonym sein. In diesem Fall hat der Benutzer ein Nullkennwort. In diesem Artikel wird vor allem eine Methode erläutert und analysiert: die Bindungsumleitung, auch Proxyauthentifizierung genannt.

Was ist die Proxyauthentifizierung?

Die Proxyauthentifizierung ermöglicht einem Benutzer, eine einfache Bindung an eine AD LDS-Instanz durchzuführen und dabei weiterhin eine Zuordnung zu einem Active Directory-Konto beizubehalten. Die Transaktion umfasst zwei Konten. Das erste ist ein besonderes Objekt in AD LDS, das als userProxy-Objekt bezeichnet wird. Das zweite ist das Benutzerkonto in Active Directory.

Das AD LDS-userProxy-Objekt ist eine Repräsentation des Active Directory-Kontos. Das Proxyobjekt ist durch die Sicherheits-ID (SID) dieses Kontos an das Active Directory-Konto gebunden. Im eigentlichen Proxyobjekt wird kein Kennwort gespeichert.

Wenn ein Benutzer eine einfache Bindung an eine LDS-Instanz mit einem Proxyobjekt durchführt, wird die Bindung durch das Weiterleiten der SID und des Kennworts an einen Domänencontroller zu Active Directory umgeleitet. Der AD LDS-Server führt die Authentifizierung durch, und der gesamte Prozess ist für den Endbenutzer unsichtbar. Dies ist in Abbildung 1 dargestellt, in der Lucy mit ihrem AD LDS-Benutzerkonto eine Verbindung zu einer AD LDS-Instanz namens „CN=AppDir,DC=contoso,DC=com“ herstellt.

Abbildung 1 Herstellen einer Verbindung mit AD LDS (zum Vergrößern auf das Bild klicken)

Für die Authentifizierung verwendet Lucy eine einfache Bindung, und sie stellt ihren Distinguished Name (DN) und ihr Kennwort bereit, wie bei einer normalen LDAP-Bindung. Obwohl Lucy scheinbar eine Verbindung mit ihrem typischen LDS-Benutzerkonto herstellt, verwendet sie genau genommen ein Proxyobjekt. Die Authentifizierung via Active Directory geschieht im Hintergrund, und Lucy hat keinen Anhaltspunkt dafür, dass sie für die Bindung im Grunde ihr Active Directory-Konto verwendet.

Vorteile der Proxyauthentifizierung

Die Stärke der Proxyauthentifizierung liegt darin, dass Anwendungsentwicklern der Zugriff auf ein Benutzerobjekt gewährt wird, ohne ihnen Zugriff auf das Active Directory-Konto zu gewähren. Bedenken Sie, was geschieht, wenn eine neue verzeichnisfähige Anwendung erstellt wird und die Anwendung einige Daten in Active Directory speichern muss. Die Anwendung kann entweder ein vorhandenes Attribut verwenden oder ein neues erstellen.

Das Risiko bei der Verwendung eines vorhandenen, noch nicht verwendeten Attributs besteht darin, dass das Attribut wahrscheinlich für einen anderen Zweck vorgesehen ist. Selbst wenn es jetzt nicht verwendet wird, könnte es in Zukunft verwendet werden. Wenn es für einen anderen Zweck verwendet wird, müssten die Active Directory-Administratoren nachverfolgen, wie es verwendet wird. Und was ist, wenn der Anwendungsentwickler mehr als ein Attribut benötigt?

Bei der Proxyauthentifizierung ist im AD LDS-Verzeichnis eine Darstellung des Active Directory-Benutzerobjekts vorhanden. Ein anwendungsspezifisches Verzeichnis ermöglicht dem Anwendungsentwickler, das Schema im Kontext von AD LDS nach Bedarf zu ändern. Attribute können vom Entwickler beliebig geändert, hinzugefügt oder mit einem neuen Zweck versehen werden, und der Active Directory-Administrator kann bedenkenlos mehrere Schemaänderungen vornehmen, ohne den Verlauf der Attributverwendung nachverfolgen zu müssen. Wenn eine andere Anwendung online das gleiche Attribut verwenden will, ist das kein Problem, weil sie eine separate AD LDS-Instanz sein kann und keine Attributkonflikte haben wird.

Die Proxyauthentifizierung kann außerdem in Situationen nützlich sein, die das X.500-Format erfordern. Active Directory verwendet nicht die typische X.500-Nomenklatur für DNS. Zum Beispiel hat ein Benutzerobjekt in Active Directory den Distinguished Name „CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com“. In AD LDS könnte der DN des Benutzers jedoch „CN=Lucy D. Smith,CN=Users,O=Contoso,C=US“ lauten, was mit X.500 kompatibel ist.

Dies ist hilfreich, wenn Sie einen Drittanbieter-LDAP-Client verwenden oder versuchen, eine Integration in ein Drittanbieterverzeichnis zu erreichen, das das X.500-Format erfordert. Auf diese Weise kann LDS ein Zwischenverzeichnis zwischen einem Drittanbieterverzeichnis und Active Directory sein. Beim Verwenden der Proxyauthentifizierung kann das Dienstkonto, das das Drittanbieterverzeichnis für die Bindung an die LDS-Instanz verwenden muss, in Active Directory beibehalten werden, statt in LDS selbst.

Einblick in das Proxyobjekt

Bislang haben Sie einen kurzen Überblick darüber erhalten, wie das LDS-Proxyobjekt an das Active Directory-Benutzerkonto gebunden wird. Dies wird im Folgenden ausführlicher erläutert, und es wird untersucht, was tatsächlich im Hintergrund geschieht. Den Anfang macht hierbei die Objektklasse.

In Windows Server 2008 enthält das %SYSTEMROOT%\ADAM-Verzeichnis zwei LDF-Dateien, die ein Proxyobjekt darstellen:

• MS-UserProxy.LDF
• MS-UserProxyFull.LDF

MS-UserProxy.LDF enthält die Definition für die einfache userProxy-Klasse, die über grundlegende Attribute verfügt und die msDS-BindProxy-Hilfsklasse enthält. Auch MS-UserProxyFull.LDF enthält die msDS-BindProxy-Hilfsklasse, aber diese Datei lädt außerdem die Benutzerattribute in das mayContain-Attribut der Klasse. Daher müssen die Attributklassen zuvor bereits vorhanden sein. Das heißt, beim Importieren der userProxyFull-Klasse muss zuerst entweder die user- oder die inetOrgPerson-Klasse importiert werden. Sowohl die user- als auch die inetOrgPerson-Klasse enthalten die Attributklassendefinitionen für die Attribute, die von userProxyFull verwendet werden. Abbildung 2 zeigt die Unterschiede zwischen der userProxy-Klasse und der userProxyFull-Klasse.

Abbildung 2 Die Klassen userProxy und userProxyFull (zum Vergrößern auf das Bild klicken)

Die Tatsache, dass beide Klassen msDS-BindProxy als Hilfsklasse enthalten, ist wichtig. Eine Hilfsklasse ist eine Art von Klasse, die einer strukturellen Klasse zusätzliche Daten bieten kann. In LDS zum Beispiel ist die User-Klasse eine strukturelle Klasse, die von der Organizational-Person-Klasse geerbt wird. Das bedeutet, dass die User-Klasse alles hat, was die Organizational-Person-Klasse hat. Aber die User-Klasse hat auch eine Hilfsklasse namens „msDS-BindableObject“. Das heißt, die User-Klasse verfügt außer den Attributen der Organizational-Person-Klasse über alle erforderlichen und optionalen Attribute von msDS-BindableObject. In diesem Fall wird dadurch, dass das msDS-Bindable­Objekt als Hilfsklasse verwendet wird, die Bindung der User-Klasse ermöglicht.

Da die userProxy-Klasse als Hilfsklasse msDS-BindProxy hat (siehe Abbildung 3), enthält sie jetzt auch den gesamten erforderlichen und optionalen Attributsatz von msDS-BindProxy. Die msDS-BindProxy-Hilfsklasse ist das, was ein Objekt in ein Proxyobjekt verwandelt. Auch wenn Sie eine benutzerdefinierte Klasse haben, können Sie die msDS-BindProxy-Hilfsklasse hinzufügen und Ihre benutzerdefinierten Objekte für die Proxyauthentifizierung verwenden.

Abbildung 3 Erstellen eines Proxyobjekts (zum Vergrößern auf das Bild klicken)

Bei einer Untersuchung der msDS-BindProxy-Klasse würden Sie feststellen, dass nur ein erforderliches Attribut definiert ist – objectSID. Dies ist das Attribut, in das die SID des Active Directory-Benutzerkontos platziert wird, um die Zuordnung zwischen dem Proxyobjekt in LDS und dem Benutzerobjekt in Active Directory zu erstellen. Dieses Attribut kann nur aufgefüllt werden, wenn das Objekt erstellt wird. Es kann nicht geändert werden, ohne das Objekt zu löschen und neu zu erstellen.

Durchführung der Authentifizierung

Um wirklich zu verstehen, was im Hintergrund geschieht, muss die Durchführung der Authentifizierung näher erläutert werden. Im Folgenden werden Sie durch zwei Netzwerkablaufverfolgungen geführt, mit deren Hilfe veranschaulicht werden kann, wie die Proxyauthentifizierung funktioniert. Die erste Ablaufverfolgung ist eine Netzwerkaufzeichnung einer einfachen Proxybenutzerbindung zwischen einer Windows XP-Arbeitsstation und einer Windows Server 2008-LDS-Instanz. In dieser Aufzeichnung stellt Lucy eine Bindung zu ihrem Proxybenutzerobjekt her, indem sie LDP.EXE von ihrer Arbeitsstation verwendet.

Abbildung 4 zeigt die drei Pakete in der Aufzeichnung, die untersucht werden müssen. Paket 1 ist die Bindungsanforderung von der Arbeitsstation (10.0.0.107) an den AD LDS-Server (10.0.0.201). Die Bindungsanforderung enthält den DN von Lucy, „cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com“. Paket 2 ist die Antwort des AD LDS-Servers an die Arbeitsstation und zeigt eine erfolgreiche Bindung an. Paket 3 ist die Bestätigung der Arbeitsstation an den AD LDS-Server und zeigt die Bestätigung der Bindungsantwort an.

Abbildung 4 Bindungsanforderung und -antwort (zum Vergrößern auf das Bild klicken)

Wenn Sie die Details von Paket 1 näher betrachten (siehe Abbildung 5), werden Sie sicher erschrecken. Das von Lucy bereitgestellte Kennwort (P@ssw0rd) wird in der Aufzeichnung in Klartext angezeigt. Dies ist in der Tat einer der Gründe, die gegen die Verwendung einer einfachen LDAP-Bindung für die Authentifizierung sprechen. Sofern die Bindung nicht in einer SSL-Verschlüsselung verpackt ist, wird das Kennwort des Benutzers allen im Netzwerk angepriesen.

Abbildung 5 Einfache Bindung mit deaktiviertem SSL (zum Vergrößern auf das Bild klicken)

Von AD LDS wird SSL jedoch standardmäßig aktiviert. Sie müssen sich etwas anstrengen, um es zu deaktivieren, und das ist genau das, was ich für diese Übung getan habe, damit die Netzwerkablaufverfolgung lesbar wird. Dabei habe ich keinen Aufwand betrieben, um dem AD LDS-Server ein Zertifikat zuzuweisen, aber in einer tatsächlichen Implementierung müssen Sie unbedingt sicherstellen, dass der AD LDS-Server ein gültiges Zertifikat hat, das für SSL verwendet werden kann.

Die zweite Ablaufverfolgung ist eine Netzwerkaufzeichnung vom AD LDS-Server zum Domänencontroller (DC). Diese Ablaufverfolgung ist etwas umfassender als die erste und wird deshalb in Abschnitte aufgeteilt. Die ersten 9 Pakete dieser Ablaufverfolgung sehen Sie in Abbildung 6.

Abbildung 6 AD LDS stellt eine Verbindung zum Domänencontroller her (zum Vergrößern auf das Bild klicken)

Das erste Paket sollte Ihnen bekannt vorkommen. Es befindet sich in der von der Arbeitsstation eingehenden Bindungsanforderung. Wie weiter oben enthält dieses Paket den DN von Lucy und das Kennwort als Klartext. Die Pakete 2 bis 9 zeigen den AD LDS-Server (10.0.0.201) an, der eine Verbindung zum Domänencontroller (10.0.0.200) herstellt. Dies besteht aus ARP-Nachrichten (Address Resolution-Protokoll), gefolgt von einer RPC-Verbindung (Remote Procedure Call) zum DC.

In Abbildung 7 rufen die Pakete 10 und 11 eine Methode namens „LsarLookupSids3“ auf, einen Remoteprozeduraufruf, der den DC auffordert, einen Batch von SIDs zu nehmen und ihre entsprechenden Namen zurückzugeben. Der AD LDS-Server sendet die Anforderung in Paket 10 und erhält die Antwort vom DC in Paket 11.

Abbildung 7 Kerberos-Authentifizierungsversuch (zum Vergrößern auf das Bild klicken)

Nach einem kurzen TCP-Handshake zum Starten der Kerberos-Sitzung (Pakete 12 bis 14) versucht der AD LDS-Server in Paket 15, das Authentifizierungsdienstticket (AS-REQ) vom Schlüsselverteilungscenter (Key Distribution Center, KDC) abzurufen. In Paket 16 wird die Anforderung des Authentifizierungsdiensttickets verweigert, weil der DC einige Vorauthentifizierungsdaten erwartet, die der AD LDS-Server nicht bereitgestellt hat. In diesem Fall erfordert der DC den Zeitstempel, damit er für die Identitätsüberprüfung verwendet werden kann. Die Kerberos-Sitzung wird beendet, und es wird ein Zurücksetzen angefordert (Pakete 17 bis 19).

Abbildung 8 zeigt die restliche Aufzeichnung. Die Pakete 20 bis 22 richten eine neue Kerberos-Sitzung ein, und in Paket 23 wird eine neue Authentifizierungsdienstanforderung vom AD LDS-Server zum DC gesendet. Diese neue Anforderung enthält die notwendigen Vorauthentifizierungsdaten, die von der erfolgreichen Antwort vom DC in Paket 25 angezeigt werden. Der AD LDS-Server hat jetzt das Authentifizierungsdienstticket und kann eine Anforderung an den Ticket genehmigenden Dienst stellen, um die Anmeldeinformationen von Lucy zu authentifizieren.

Abbildung 8 Erfolgreiche Authentifizierung (zum Vergrößern auf das Bild klicken)

Die Anforderung und Antwort des Ticket genehmigenden Diensts werden in den Paketen 33 und 34 aufgezeichnet. Der Empfang von KRB_TGS_REP in Paket 34 zeigt an, dass Lucy erfolgreich authentifiziert wurde. Abschließend leitet der AD LDS-Server in Paket 38 die Bindungsantwort zurück zur Arbeitsstation und lässt Lucy wissen, dass sie erfolgreich an die AD LDS-Instanz gebunden wurde. Obwohl dieser Prozess mehrere Schritte beinhaltet, dauert die gesamte Transaktion nur etwa ein Zehntel einer Sekunde.

Was würde geschehen, falls Lucy das falsche Kennwort eingegeben hat? In diesem Beispiel würde die Authentifizierungsdienstanforderung an Paket 25 fehlschlagen. Der Fehler der Authentifizierungsdienstanforderung würde dem AD LDS-Server mitteilen, dass Lucys Anmeldeinformationen ungültig waren. Statt eine Anforderung an den Ticket genehmigenden Dienst auszugeben, würde der AD LDS-Server eine Bindungsantwort an die Arbeitsstation zurücksenden und erklären, dass die Anmeldeinformationen ungültig waren.

Hier ist eine kurze Zusammenfassung dessen, was im erfolgreichen Austausch geschehen ist:

1. Die Arbeitsstation sendet dem AD LDS-Server eine Bindungsanforderung.
2. Der AD LDS-Server richtet eine Verbindung zum DC ein.
3. Der AD LDS-Server fordert den DC auf, die SID von Lucy in ein Bezeichner zu übersetzen, den er für die Authentifizierung verwenden kann.
4. Der DC gibt dem AD LDS-Server die ID von Lucy.
5. Der AD LDS-Server erhält vom DC ein TGT (Ticket Granting Ticket) mit der ID von Lucy.
6. Der AD LDS-Server erhält ein an sich selbst gerichtetes Sitzungsticket, indem er das TGT von Lucy verwendet.
7. Der AD LDS-Server sendet eine erfolgreiche Bindungsantwort zurück zur Arbeitsstation.

Dieser Prozess zeigt, dass die Verbindung von der Arbeitsstation zum AD LDS-Server eine Standard-LDAP-Bindungstransaktion ist. Dann wird, vom AD LDS-Server zum DC, Kerberos verwendet, um den Benutzer zu authentifizieren.

Einrichten einer Testumgebung für die Proxyauthentifizierung

Nun, da Sie wissen, wie die Proxyauthentifizierung funktioniert, erfahren Sie im Folgenden, wie Sie dies in einer Testumgebung einrichten können. Beachten Sie, dass für diese Übung die SSL-Anforderung in der Proxyauthentifizierung deaktiviert wird. Wie weiter oben erwähnt, denken Sie aber bitte daran, dass Sie diese Anforderung in einer realen Implementierung nicht deaktivieren sollten.

Vor dem Start benötigen Sie eine voll funktionsfähige Domäne mit einem Windows Server 2008-Mitgliedsserver und einer damit verknüpften Arbeitsstation. Der Windows Server 2008-Mitgliedsserver wird AD LDS ausführen, und die Arbeitsstation wird der Clientendpunkt sein. Der Vorteil, den das Trennen dieser Computer hat, besteht darin, dass Sie deren Interaktion in Netzwerkaufzeichnungen festhalten können. Beim Einrichten der Testumgebung durchlaufen Sie die folgenden Schritte:

• Installieren Sie AD LDS auf dem Mitgliedsserver.
• Deaktivieren Sie die SSL-Anforderung für die Proxyauthentifizierung.
• Importieren Sie die userProxy-Klasse in das AD LDS-Schema.
• Erstellen Sie das Proxyobjekt, und weisen Sie ihm Berechtigungen zu.
• Stellen Sie eine Bindung zum AD LDS-Verzeichnis mit dem Proxyobjekt her.

Der erste Schritt ist die Installation von AD LDS auf dem Windows Server 2008-Mitgliedsserver. Im Server-Manager finden Sie im Assistenten „Rollen hinzufügen“ die Option für die Installation von LDS. Nachdem die Rolle installiert ist, wird im Menü „Verwaltung“ eine neue Option namens „Setup-Assistent für Active Directory Lightweight Directory Services“ angezeigt. Verwenden Sie diesen Assistenten, um eine neue LDS-Instanz zu erstellen.

Wenn Sie aufgefordert werden, den Namen der Anwendungspartition einzugeben, geben Sie einen beliebigen DN ein. Denken Sie daran, dass LDS die X.500-Benennung unterstützt. Sie sind also nicht darauf beschränkt, einen Namen im Stil von „DC=“ zu verwenden. In diesen Beispielen habe ich „cn=appdir,dc=contoso,dc=com“ verwendet, aber ich hätte auch „cn=appdir,o=contoso,c=us“ verwenden können.

Nachdem die AD LDS-Instanz installiert wurde, besteht der nächste Schritt darin, die SSL-Anforderung für die Proxyauthentifizierung zu deaktivieren. Im ADSI Edit-Snap-In (adsiedit.msc) empfiehlt sich die Verbindung zur Konfigurationspartition der AD LDS-Instanz unter Verwendung des Administratorkontos, das Sie während der Installation angegeben haben. Wenn Sie den DN der Konfigurationspartition nicht kennen, können Sie in ADSI Edit im Dialogfeld „Verbindungseinstellungen“ in der Dropdownliste „Bekannten Namenskontext auswählen“ den Eintrag „Konfiguration“ auswählen.

Navigieren Sie zum Container „CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}“, und öffnen Sie den Eigenschaftendialog des Containers „CN=Directory Service“. Die Attributliste enthält ein Attribut mit mehrwertiger Zeichenfolge namens „msDS-Other-Settings“, das mehrere Zeichenfolgen auflistet, von denen jede eine unterschiedliche Einstellung für die AD LDS-Instanz angibt. Bearbeiten Sie dieses Attribut, und ändern Sie die Zeichenfolge „RequireSecureProxyBind“ in den Wert „0“.

Der nächste Schritt besteht darin, die Schemaklassendefinition für die userProxy-Klasse zu importieren. Sie haben sie wahrscheinlich bereits importiert, als Sie im AD LDS-Assistenten dazu aufgefordert wurden. Falls dies zutrifft, können Sie diesen Schritt auslassen. Falls Sie die Definition noch nicht importiert haben, können Sie dies mit dem folgenden LDIFDE.EXE-Befehl nachholen. Stellen sicher, dass Sie den Namen des AD LDS-Servers und den richtigen Port im Befehl angeben:

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

Nach dem Importieren der Objektklasse kann das Proxyobjekt erstellt werden. Ich werde LDP.EXE verwenden, aber Sie können auch ein anderes Tool oder eine programmgesteuerte Methode verwenden. Stellen Sie unter Verwendung von LDP eine Verbindung zu Ihrer AD LDS-Instanz und eine Bindung zu Ihren Administratoranmeldeinformationen her. Navigieren Sie zum DN Ihrer AD LDS-Instanz, und wählen Sie den Container aus, in dem Sie das Proxyobjekt erstellen möchten. Klicken Sie mit der rechten Maustaste auf den Container, und wählen Sie in der Dropdownliste die Option „Untergeordnetes Objekt hinzufügen“ aus. Im Dialogfeld „Hinzufügen“ müssen Sie im entsprechenden Feld den DN des neuen Proxyobjekts eingeben. Sie können zum Beispiel „cn=lucy,cn=appdir,o=contoso,c=us“ verwenden.

Sie müssen außerdem zwei Attribute mit diesem Objekt erstellen. Das erste ist objectClass und zeigt an, welche Art von Objekt erstellt wird. Der für dieses Beispiel zu verwendende Wert ist „userProxy“. Geben Sie diese Informationen im Abschnitt „Eingabe bearbeiten“ des Dialogfelds ein, und klicken Sie auf die Schaltfläche „Eingabe“.

Das zweite Attribut, das hinzugefügt werden muss, ist objectSID. Es enthält die SID des Active Directory-Benutzerkontos, dem dieses Proxyobjekt zugeordnet ist. Sie können diese SID mit verschiedenen Methoden abrufen, aber ich habe eine Active Directory-Verbindung in einer separaten LDP-Instanz hergestellt und das objectSID-Attribut vom Benutzerkonto kopiert. Nach dem Eingeben dieser Informationen sollte das Dialogfeld so ähnlich wie in Abbildung 9 aussehen. Klicken Sie abschließend auf die Schaltfläche „Ausführen“, um die Änderung zu übernehmen.

Abbildung 9 Erstellen eines Proxyobjekts

Für die Verwendung des eben erstellten Proxyobjekts müssen Sie ihm einige Berechtigungen zuweisen. Sie können dies problemlos durch Auswählen des Objekts „CN=Readers“ unter dem Container „CN=Roles“ in LDP erreichen. Klicken Sie mit der rechten Maustaste, und wählen Sie in der Dropdownliste „Ändern“ aus. Fügen Sie ein Attribut namens „member“ hinzu, und geben Sie für den Wert den neuen DN des userProxy-Objekts ein, das Sie erstellt haben. Denken Sie daran, auf die Schaltfläche „Eingabe“ zu klicken, bevor Sie auf „Ausführen“ klicken. Jetzt sollte das userProxy-Objekt ein Mitglied der Readers-Gruppe in der LDS-Instanz sein.

Alles sollte so weit eingerichtet sein, dass Sie jetzt die Proxyauthentifizierung testen können. Öffnen Sie eine neue Instanz von LDP, und stellen Sie eine Verbindung zum AD LDS-Server her. Wählen Sie dieses Mal beim Binden Ihrer Instanz jedoch „Einfache Bindung“ aus, und geben Sie den DN des Proxyobjekts im Feld für den Benutzernamen ein. Geben Sie als Kennwort das Kennwort des Active Directory-Kontos ein, an das Sie dieses Proxyobjekt gebunden haben. Klicken Sie auf „OK“. Jetzt sind Sie an die Instanz im schreibgeschützten Modus gebunden.

Verweilen Sie etwas bei Netzwerkablaufverfolgungen, und probieren Sie verschiedene Bindungsmethoden aus. Eine Übung wäre zum Beispiel, SSL wieder zu aktivieren und dann den LDAP-Bindungsprozess aufzuzeichnen. Sie könnten sich dabei absichtlich beim Benutzernamen oder Kennwort vertippen, um zu sehen, wie sich dies auf den Authentifizierungsprozess auswirkt.

Schlussbemerkung

Machen Sie sich keine Sorgen wegen der Schwierigkeiten beim Verwenden der Proxyauthentifizierung. Um diesen Prozess zu demonstrieren, habe ich den Ansatz mit LDP und ADSI Edit gewählt, weil Sie dadurch einen besseren Einblick in das Geschehen im Hintergrund erhalten. Daher veranschaulicht das Beispiel, durch das Sie geführt wurden, die Proxyauthentifizierung aus einer sehr praktischen Perspektive.

In der Praxis ist der langwierige Prozess, bei dem userProxy-Objekte erstellt und geändert werden, meist durch ein Identitätsverwaltungssystem oder ein eigens entwickeltes Front-End für das Erstellen von Konten festgelegt. Ich ermutige Sie, Ihre eigene LDS-Testumgebung zu erstellen und selbst herauszufinden, wie Sie die Proxyauthentifizierung für die Integration Ihrer Drittanbieterverzeichnisse und Anwendungen verwenden können.

Ken St. Cyr ist ein Berater für Microsoft und hat seit der Einführung von Active Directory darauf basierende Verzeichnislösungen entworfen und implementiert. Er hat als einer der ersten die Microsoft-Zertifizierung „Microsoft Certified Master“ für Verzeichnisdienste erhalten. Sie erreichen ihn unter ken.stcyr@microsoft.com.