I am trying to use the windows principal authenticationmethod with AD LDS described in the link below.
I am looking for assistance in how to populate my AD LDS instance to test this. Again I know how to create an instance, but for this scenario I do not know what object to put in AD LDS nor how to populate it or what to use as the source of data. I am not trying to do proxy authentication noram I trying to do LDS security principal authentication.
http://blogs.technet.com/b/idaguys/archive/2009/06/19/overiview-of-authentication-in-ad-lds.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.
leo