This project has moved and is read-only. For the latest updates, please go here.

Not working purely over LDAPS (Ldap Over SSL)


In a locked down environment, i'v tried to add another domain by manually specifying LDAP connection. Following ports were were allowed to another domain's DC's:
  • 636 (for LDAPS)
  • 3269 (for Global Catalog)
  • 88 (For Kerberos)
Connection was added
  1. LDAP Path: LDAP://int.domain1.local:636/DC=int,DC=domain1,DC=local
  2. Authentication Type used Encryption and Secure.
  3. Test LDAP Connection sucesfulyl succeeds.
However queries were not working, were timing out. Having recorded a trace, turns out LDAPCP wants to use UDP 389 (CLDAP) port to query such LDAP query:
+ Udp: SrcPort = 49655, DstPort = LDAP(389), Length = 166
  Cldap: (CLDAP)Search Request, MessageID: 34031, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
- LDAPMessage: Search Request, MessageID: 34031
  + ParserHeader: 
  + MessageID: 34031
  + OperationHeader: Search Request, 3(0x3)
  - SearchRequest: BaseDN: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
   + BaseObject: NULL
   + Scope: base Object
   + Alias: neverDerefAliases
   + SizeLimit: No Limit
   + TimeLimit: No Limit
   + TypesOnly: False
   + Filter: (&(DnsDomain=int.domain1.local)(Host=hostname)(NtVer=16:00:00:00)(DnsHostName=hostname.domain2.local))
   + Attributes: ( Netlogon )
I suspect this is because of this in SetLDAPConnections: directoryEntries[i++] = Domain.GetComputerDomain().GetDirectoryEntry();

This SO Question confirms that this method issues queries without SSL: How to use SSL for System.DirectoryServices.ActiveDirectory?

After opening 389 UDP port, People Picker can now find users/groups in another domain and doesn't time out.

Could you consider making connection to SharePoint domain in another way, so we don't have to depend on non-secure 389 port?


Yvand wrote Jun 2, 2016 at 3:42 PM

Domain.GetComputerDomain().GetDirectoryEntry(); is used when option "Connect to SharePoint domain" is added.
But if you define a LDAP connection manually, it will use what you specified to create LDAP connection.
Below is the relevant code snippet:
if (!LDAPConnection.UserServerDirectoryEntry)
    directoryEntries[i++] = new DirectoryEntry(LDAPConnection.Path, LDAPConnection.Username, LDAPConnection.Password, LDAPConnection.AuthenticationTypes);
    directoryEntries[i++] = Domain.GetComputerDomain().GetDirectoryEntry();
I'm currently working on a new version that introduces a lot of changes and records Authentication options in the logs, are you interested to test it?

liborj wrote Oct 3, 2016 at 5:02 PM

Hello Ivan,

I have a question for you regarding the LDAPCP solution.

I deployed it on my sharePoint farms and it works great over the 389 port. However when I try to establish a connection over the 636 port as a secure LDAP then it does not connect at all. It only spins and spins and nothing happens at all. That is when I try to test the connection. We tried so many LDAP paths with different servers and it simply does want to create a connection with selecting options over the port 636.
I followed the connection path and authentication type as suggested above with selecting "Secure" and "Encryption".
From this blog I see that the poster did not have a problem to create a connection over the 636 port although he had problems to run queries.
So my problem is even before I start to query the LDAP.
Also, I have a question about the authentication types. There is one missing which is the "SSL" or "SecureSocketsLayer". Why is this type missing as an option to check it? Would not it be a crucial type when you are trying to create a secure LDAP connection? Could you help me to see how to troubleshoot this please?
Additionally, how could I create a connection using the Kerberos connection?

I really need to make this work since this is deployed in a very secure environment and the connection over the 389 port is not acceptable.
I can test any newly written solution since I have an environment for that.

thank you for your time and help.

Best regards

janis_veinbergs wrote Oct 4, 2016 at 10:10 AM

Hello @liborj. True that without 389 and 3268 (GC) ports people pickers were working miserably and timing out :(

Regarding SecureSocketsLayer flag - I'v found such a comment in source - 2013/LDAPCP 2013/ADMIN/ldapcp/LdapcpSettings.aspx.cs :
// Encryption and SecureSocketsLayer have same value and it will violate uniqueness of key if attempt to add both to Dictionary

liborj wrote Oct 4, 2016 at 1:06 PM

Hello @janis_veinbergs,

thank you for your feedback. I assumed that there was a redundancy and that was the reason why i did not see that option (SSL) there.

Can you share with me if you had problems to create the secure LDAP connections? Or did you experience problems only with queries?
Also, how would i go about using this solution with Kerberos as an alternative to using the secure LDAP?

thank you for sharing