Using AD LDS for Windows Authentication for MOSS 2007
I have come across a requirement where we require to provide access to AD LDS users to SharePoint site using Windows Authentication. Though we have made it possible by creating LDAP source for AD LDS and implementing Forms Authntication. But now the requirement is to use only Windows Authentication with AD LDS. Pls. note here that we are already using Active Directory for user profiles with windows authentication. Can anyone tel me if it is possible to use Windows Authentication using AD LDS and if it is possible what steps do i need to follow in order to set it up. Thanks!
February 3rd, 2010 11:21am
Hi,Please look this: 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 http://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 http://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 http://technet.microsoft.com/en-us/magazine/2008.12.proxy.aspx provides more insight into proxy authentication. This article http://technet.microsoft.com/en-us/library/cc784622.aspx explains how to set up each of the authentication available in AD LDS. Source: http://blogs.technet.com/idaguys/archive/2009/06/19/overiview-of-authentication-in-ad-lds.aspx MCTS
February 3rd, 2010 12:59pm
Hi Denis, Thanks a lot for replying....but i am still not able to find out the answer to my question.....let me explain it again.....Suppose i have my users in AD LDS and i have a SharePoint Server ....When i create a Web Application i select an authentication mode (Windows / Forms) ....If i select windows authentication for my Web Application can my AD LDS users log into the SharePoint site using their AD LDS credentials? I know that they can log into the SharePoint site using their AD LDS credentials when i select Forms Based Authentication on the Web Application. source : http://sharepointgeorge.com/2009/ad-lds-and-forms-based-authentication/
February 4th, 2010 1:33pm
I also have a requirement to expand users to ADAM/AD LDS, and want to maintain the Windows Authentication through NTLM. We are currently using ISA as authentication through FBA and pass to SharePoint as Windows Authentication. I am not sure how to enhance this environment using AD LDS?
February 26th, 2010 2:39pm