AD LDS Proxy Authentication

AD LDS – Active Directory Lightweight Directory Services LDAP Directory offers different authentication methods, i.e.:

• simple LDAP bind
• anonymous bind or
• bind redirection  – also known as Proxy Authentication.

In this article I will take a closer look at the benefits of Proxy Authentication.

What does AD LDS Proxy Authentication actually mean?

AD LDS Proxy Authentication is a bind redirection. A Simple LDAP bind of an application is transferred from AD LDS to an Active Directory domain. For this purpose AD LDS uses a special User Object Class: userProxy or userProxyFull. It is an interaction between the userProxy object of the AD LDS instance and the user object in the Active Directory domain. The userProxy object of the AD LDS instance contains the SID of the user object in the AD domain.

AD LDS automatically transfers the login of a user on an AD LDS instance with user name and password to the AD domain which contains the actual user account (redirected). In other words, AD LDS is using the domain part of the user SID to determine the corresponding AD domain of the current user object. But in order to find a user object by its SID the server running the AD LDS instance has to be a member in a trusted domain. 

An example of an AD user object and corresponding AD LDS userProxyFull

The proxy object of the AD LDS instance has the objectClass „userProxyFull“: 

The objectSID of the user object (AD domain (green)) complies with the objectSID of the proxy object of the AD LDS instance (blue):

What is the benefit of AD LDS Proxy Authentication?

Authentication of company-wide applications

A company runs an AD domain structure with several domains and forests. Now it wants to introduce a company-wide application. Unfortunately, this application only supports one instance for authentication and cannot browse Windows domains by itself. By using a central AD LDS instance with proxy authentication the user logins are redirected to the correct Windows domain. This means that the application can be configured with a single LDAP instance for authentication and AD LDS takes care of the redirection process. 

Application requires a schema extension

In addition to the proxy authentication you may use the AD LDS instance to provide special schema extensions for an application. It allows you to avoid schema extension of productive Active Directory domains.

X.500 Notation

The AD LDS proxy authentication can also be helpful, if applications need a directory service in a standard X.500 notation. Every Active Directory user object has a Distinguished Name (DN) of the following form: “CN=Username,CN=OU-Name,DC=Domain,DC=com“. But a typical X.500 notation expects a different version of the DN, „CN=Username,CN=OU-Name,O=Organization,C=DE“. And this is where an AD LDS instance provides some sort of proxy for the translation between X.500 and AD.

What’s next?

The AD LDS Proxy Authentication is a helpful method of centrally redirecting authentication requests. A precondition is that all user accounts must have a userProxy Object as a mirror image on the AD LDS instance. These userProxy objects need to have a complete lifecycle process (create / change / delete), i.e. in order to create new AD user accounts automatically in the AD LDS instance. I will explain in a follow-up article how this synchronisation process can be provided with the support of the Microsoft FIM 2010 R2 / MIM Sync Engine.