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
- LDAP Path: LDAP://int.domain1.local:636/DC=int,DC=domain1,DC=local
- Authentication Type used Encryption and Secure.
- 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
+ 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?