ActiveDirectoryMembershipProvider - How to limit to use only secure connection on port 636 (LDAPS) RRS feed

  • Question

  • We are trying to use the ActiveDirectoryMembershipProvider through Secure connection on port 636, but whatever we tried so far, provider still tries to use/connect also on the unsecure port 389.

    The AD is behind a firewall and only ports 636 and 445 are open, 389 is forbidden!

    We used Wireshark to trace the LDAP communication: provider first starts a connection to port 636, than to 445 and then to 389 ... why?! How to stop the provider to use port 389 at all?

    WCF services are unable to start, because the membership provider results in error on Initialize method immediately.

    .Net FW is 4.6.2

    Thanks in advance,

    Thursday, November 22, 2018 4:07 PM

All replies

  • Have you set "connectionProtection" to "Secure" in your web.config file?
    • Edited by cheong00 Friday, November 23, 2018 1:26 AM
    Friday, November 23, 2018 1:25 AM
  • This is how the web.config looks like (replaced host, user etc. to dummy data)

    <add name="ADMembershipProviderForClients" 
         connectionProtection="Secure" />
    <add name="ADConnectionString" connectionString="LDAP://acme.com:636/DC=test,DC=com" />

    As you can see connectionProtection is Secure and port is 636. Still provider tries to communicate to port 389.

    This is the error message we have

    The specified domain or server could not be contacted.
       at System.Web.Security.DirectoryInformation.InitializeDomainAndForestName()
       at System.Web.Security.ActiveDirectoryMembershipProvider.Initialize(String name, NameValueCollection config)

    Friday, November 23, 2018 9:17 AM
  • Try connect to server through ADSI Edit as mentioned in here to verify the setup to server is done properly. (It's at about one-third of the page, or use "ADSI Edit" as keyword to search for the paragraphs.

    Or use "ldp.exe" at the end of the page to test it.

    Btw, since "sign and seal" method actually uses port 389, if you set the provider to "secure" as connection protection setting, probably means something in the initial try of SSL connection goes wrong, say: the "name" of the e-cert is not exact match of the hostname you supplied to LDAP connection string.


    The Active Directory Domain Service administration tools still use port 389, but they are protected by the sign and seal binding.


    • Edited by cheong00 Friday, November 23, 2018 9:57 AM
    Friday, November 23, 2018 9:46 AM
  • The communication is fine on port 636, we can trace it on Wireshark and also on ldap admin tools.

    When ActiveDirectoryMembershipProvider is initialized the communication is started up on 636 using TLS. But during the initialization sequence there is a call to InitializeDomainAndForestName() in System.Web.Security.DirectoryInformation class. That method triggers the following calls: 

    DirectoryContext context2 = new DirectoryContext(DirectoryContextType.DirectoryServer, serverName, GetUsername(), GetPassword());
    		Domain domain2 = Domain.GetDomain(context2);
    		domainName = GetNetbiosDomainNameIfAvailable(domain2.Name);
    		forestName = domain2.Forest.Name;
    	catch (ActiveDirectoryObjectNotFoundException)
    		throw new ProviderException(SR.GetString("ADMembership_unable_to_contact_domain"));

    By tracing down the behaviour of Domain.GetDomain() it seems that it can only work on port 389/LDAP, and it is just unable to use SSL, by design.

    Once this call is executed, the communication goes back to 636/LDAPS. Traffic trace shows, that initialization starts LDAPS connection on 636, then it opens an LDAP connection on 389, then goes back to 636. All subsequent operation after the initialization (e.g. ValidateUser) goes on 636/LDAPS.   

    If 389 is closed then Domain.GetDomain() fails and the whole initialization sequence fails.

    It really seems that ActiveDirectoryMembershipProvider is just unable to initialize itself without port 389, although everything its fine with SSL connection prerequisites, and able to use SSL.

    Friday, November 23, 2018 12:09 PM
  • Hi Gabor Hollosy,

    This forum discusses and asks questions about .NET Framework Base Classes, since your issue is more related to AD & LDAP, I would suggest that you could post the issue on AD & LDAP forum for suitable support.


    Thanks for your understanding.

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, November 27, 2018 3:19 AM