views:

286

answers:

2

Hi,

I have set the ActiveDirectoryMembershipProvider connectionProtection attribute to secure, according to MSDN documentation states that when this is set to secure the following holds:

"The ActiveDirectoryMembershipProvider class will attempt to connect to Active Directory using SSL. If SSL fails, a second attempt to connect to Active Directory using sign-and-seal will be made. If both attempts fail, the ActiveDirectoryMembershipProvider instance will throw a ProviderException exception."

The code works and queries can be made against the LDAP but one issue that has me a little confused is that my connection string is prefixed with LDAP and not LDAPS. Changing this to LDAPS results in the following error: "Parser Error Message: Error HRESULT E_FAIL has been returned from a call to a COM component."

What is happening here? In the first instance where the connection string is simply LDAP is SSL being used? The documentation indicates that if it is not, an exception should be thrown. If not, then what would be the likely cause for this error in this context?

A: 

As far as I know, all the LDAP DN's (distinguished names) always have an LDAP only prefix - whether they're over a secure link or not. The secure aspect typically shows up by means of the port on the server being used, 389 being the default for non-secure, and 636 being the default for a secure communication.

But the spec of the LDAP distinguished names doesn't have a LDAPS prefix, really. I've done a lot of LDAP work a few years ago, and I do remember having to deal with different ports for trusted or secured communications, but I never once had a full-qualified LDAP path have anything else but an LDAP:// prefix (case sensitive, too!).

marc_s
+1  A: 

The LDAP:// prefix is used both for clear and SSL connections, to check whether the communication is indeed under SSL try step 3 of this blog entry http://erlend.oftedal.no/blog/?blogid=7

Edgar Sánchez