Share via

Overiview of authentication mechanisms in AD LDS

  • Article

Hello All,

I have been working with a customer on application authentication project with AD LDS (Active Directory Lightweight Directory Services) and ADAM (Active Directory in Application Mode) and I thought it might be interested to share my experience on this blog. There are many things to share but I will focus this blog entry on available authentication options and will try to break it down their usage depending on the scenario.

Since this entry explores only the authentication aspect of AD LDS or ADAM, this can apply to both products. I will stick with AD LDS for the remainder of the blog for the sake of clarity.  If you are not familiar with AD LDS or ADAM, look at the Windows Server Tech Center page at https://technet.microsoft.com/en-us/library/cc731868.aspx. Brian Puhl’s recorded session at https://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=342  covers when to use AD LDS or AD DS.

You can use one of three authentication mechanisms available with AD LDS to authenticate: AD LDS principal authentication, Windows principal authentication and AD LDS proxy authentication.

AD LDS principal authentication is the most common scenario that I have seen at customer implementations. Customers who have legacy applications which require specific directory applications for simple LDAP authentication and they do not want to extend schema of their AD DS. It is a simple LDAP authentication which allows users to bind with DN (distinguished name) of their AD LDS account in X.500 format and its password. User account policies such as account locked out and password complexity are enforced by the local security policy of the machine that AD LDS instance is configured, if the server is in a workgroup. Active Directroy Domain account polices are applied, if the server belongs to a domain. The drawback in this authentication type is that users’ password are transmitted in clear text format so it requires additional step to configure LDAP over SSL. The instructions on how to configure LDAP over SSL for AD LDS is at https://technet.microsoft.com/en-us/library/cc725767.aspx.

Let’s look at Windows principal authentication (also known as SSPI authentication). Customers are usually not aware of this authentication type. This approach allows users to authenticate to AD LDS instance using their AD DS domain account or local user accounts on the server that AD LDS instance is hosted. In order for users to authenticate using their domain account, the server that the AD LDS instance is hosted must be a member of the domain. The authentication using the domain account leverages Kerberos protocol (although may fall back to NTLM depending on the AD domain policies) and thus more secure than using a local account which leverages NTLM. This MSDN article https://msdn.microsoft.com/en-us/magazine/dvdarchive/cc300806.aspx explains the capabilities of different authentication protocols and explains why Kerberos protocol is more secured than using other Windows authentication type. Using Windows principal authentication obviates the need to configure LDAP over SSL as it leverages Kerberos or NTLM Sign and Encrypt mechanism to encrypt the traffic. It is also easier to manage domain accounts with domain policies and security groups. If the Windows principal is leveraged to authenticate to an AD LDS instance, users must provide their windows credentials with user name and the domain. The con of Windows principal authentication is that it cannot accommodate legacy and non-Windows applications which still require binding with an X.500 path.

The third option is ADAM proxy user authentication, also known as bind redirection, in which users authenticate with their AD LDS principals but can leverage their corresponding AD DS passwords. Proxy authentication allows reduced sign on for users where users still need to leverage DN of AD LDS account to authenticate but can use the same password as their AD DS account. This option simplifies the account management as account management can be done from AD DS. This option requires the server the AD LDS instance is hosted to join to the AD DS domain or needs a trust relationship with the AD DS domain in which users’ AD DS account resides. This option also requires additional synchronization tools like Identity Lifecycle Manager 2007 or Forefront Identity Manager 2010 (currently in Beta) to synchronize the objectSID of AD DS user account to the corresponding AD LDS account. LDAP over SSL should be configured for users to authenticate with their AD LDS account in order to keep their domain account password secure. This technet article https://technet.microsoft.com/en-us/magazine/2008.12.proxy.aspx provides more insight into proxy authentication.

This article https://technet.microsoft.com/en-us/library/cc784622.aspx explains how to set up each of the authentication available in AD LDS.

My recommendation is to leverage Windows principal authentication leveraging users’ AD DS domain accounts when possible for the reasons mentioned above unless applications cannot support Windows authentication. If your environment has synchronization product like ILM, Bi-directional proxy authentication should be explored to simplify the account management.

Comments

  • Anonymous
    January 01, 2003
    Thanks.

  • Anonymous
    June 22, 2009
    Be careful with using sidHistory when using classes which us the Proxy Bind ability which I tried to outline here: http://jeftek.com/iam/activedirectory/adam-userproxy-and-sidhistory-not-always-what-you-expected/ Also I would recommend sticking to inheriting any userproxy class from an existing user class using a custom schema since most 3rd party applications expect and unfortunately hard code the objectclass=user in their app.

  • Anonymous
    February 28, 2013
    The comment has been removed