AD LDS Proxy Authentication

Das AD LDS – Active Directory Lightweight Directory Services (ehemals ADAM) LDAP Directory bietet verschiedene Authentifizierungsmethoden, z.B.

• simple LDAP bind
• anonymous bind oder
• bind redirection  – auch bekannt als Proxy Authentication.

Den Nutzen der Proxy Authentication werde ich in diesem Beitrag näher betrachten.

Was bedeutet AD LDS Proxy Authentication?

Bei der AD LDS Proxy Authentication wird ein Simple LDAP Bind einer Anwendung von AD LDS an eine Active Directory Domain weitergeleitet – bind redirection. Für diesen Zweck kennt AD LDS eine spezielle User Object Class: userProxy oder userProxyFull. Es ist ein Zusammenspiel zwischen dem userProxy Object der AD LDS Instanz und dem User Object in einer Active Directory Domain. Das userProxy Object der AD LDS Instanz enthält die SID des User Objects aus der AD Domain. Eine Anmeldung eines Benutzers an der AD LDS Instanz mit Benutzername und Passwort wird von AD LDS automatisch an die AD Domain mit dem echten Benutzerkonto weitergeleitet (redirected). Die AD Domain des User Objects, an welche die Anmeldung weitergeleitet werden soll, erkennt AD LDS anhand des Domain-Anteils der UserSID. Der Server, auf welchem die AD LDS Instanz läuft, muss Mitglied in einer vertrauten (trusting) Domain sein, damit das User Object anhand seiner SID gefunden werden kann.

Beispiel für ein AD User Object mit zugehörigem AD LDS userProxyFull

Das Proxy Object der AD LDS Instanz hat die objectClass „userProxyFull“: 

Die objectSID des User Objects aus der AD Domain (grün) entspricht der objectSID des Proxy Objects der AD LDS Instanz (blau):

Welchen Nutzen bringt eine AD LDS Proxy Authentication?

Authentifizierung unternehmensweiter Anwendungen

Ein Unternehmen betreibt eine AD Domänen Struktur mit mehreren Domains und Forests und möchte eine neue unternehmensweite Anwendung einführen. Diese Anwendung unterstützt allerdings nur eine Instanz zur Authentifizierung und kann nicht eigenständig durch die Windows Domains browsen. Hier kann eine zentrale AD LDS Instanz mit Proxy Authentication genutzt werden um die Anmeldung der Benutzer an die richtige Windows Domain weiterzuleiten. Somit kann die Anwendung mit einer einzigen LDAP Instanz zur Authentifizierung konfiguriert werden und AD LDS übernimmt die Weiterleitung.

Anwendung erfordert eine Schema Erweiterung

Zusätzlich zur reinen Proxy Authentication kann die AD LDS Instanz genutzt werden um z.B. spezielle Schema Erweiterungen für eine Anwendung bereitzustellen. Somit kann eine Schema Erweiterung der produktiven Active Directory Domains umgangen werden.

X.500 Notation

Die AD LDS Proxy Authentication kann ebenfalls hilfreich sein, wenn Anwendungen einen Directory Service in typischer X.500 Notation erwarten. Ein Active Directory User Object hat einen Distinguished Name (DN) nach folgendem Aufbau “CN=Username,CN=OU-Name,DC=Domain,DC=com“. Eine typische X.500 Notation erwartet aber einen etwas anderen DN „CN=Username,CN=OU-Name,O=Organization,C=DE“. Hier kann eine AD LDS Instanz eine Art Proxy für die Übersetzung zwischen X.500 und AD bereitstellen.

What’s next?

Die AD LDS Proxy Authentication stellt eine schöne Möglichkeit zur zentralen Weiterleitung von Authentifzierungsanfragen dar. Dies setzt aber voraus, dass alle Benutzerkonten ein userProxy Object als Spiegelbild in der AD LDS Instanz haben. Diese userProxy Objekte benötigen einen vollständigen Life-Cycle-Prozess (create / change / delete), damit z.B. neue AD Benutzerkonten automatisch in der AD LDS Instanz angelegt werden. Wie dieser Sychronisationsprozess mit der Unterstützung der Microsoft FIM 2010 R2 / MIM Sync-Engine bereitgestellt werden kann, werde ich in einem nachfolgenden Artikel behandeln.

Update 22.03.2016

Wie bereits angekündigt, gibt es hier einen weiterführenden Artikel, welcher die Anbindung einer AD LDS Instanz mit der Unterstützung von Microsoft MIM 2016 beschreibt: AD Domain und AD LDS via MIM 2016 synchronisieren