Force LDAPCP to USE Port 636

[mpatrick210]

Is there a way to force a LDAPCP connect to user port 636 vs 389?

[Yvand]

You can replace the default connection with your own LDAP connection and set the port to 636 in central admin > Security > LDAPCP global configuration. If LDAPS is correctly configured on the LDAP server, then the connection should use SSL encryption.

[mpatrick210]

Hey Yvand - I currently use LDAPCP v2017.10, and do not see a place to set the port. Do we need to update LDAPCP to a new version to see that option? I tried to add the port to the actual LDAP path - LDAP://xx.xx.xx.xx:636 - but that didn't work.

[Yvand]

@mpatrick210 yes it should work, although you should update LDAPCP The LDAP path is correct, but I forgot to mention that you should also check SecureSocketsLayer in the authentication type options

[mpatrick210]

The option I have is "Secure" but don't have "SecureSocketsLayer"....but the adding ":636" behind the LDAP connection does not work...if the option "Secure" will force 636, I can give that a shot...

[Yvand]

@mpatrick210 based on the enum type values, you can use Encryption, which has the same value as SecureSocketsLayer

[mpatrick210]

@Yvand tried the "Encryption" type, and it fails with:

Unable to connect to LDAP for following reason: The server is not operations. It may be expected if w3wp process of central admin has intentionally no access to LDAP server.

[Yvand]

@mpatrick210 can you try to connect to your LDAP using LDAPS on the SharePoint machine, as the SharePoint farm/apppool account, using ldp.exe as documented here ?

[Yvand]

I did some tests and I think it works if you use the following settings: LDAP path: LDAP://dc.contoso.local:636/CN=Users,DC=contoso,DC=local Authentication type: Encryption, Secure

Can you give this a try? Note that, according to my tests, the path is case sensitive: Make sure to type LDAP:// and not ldap://

[Yvand]

@mpatrick210 were you able to validate if it works using the settings above?

[mpatrick210]

Hey @Yvand I was able to use our domain LDAP://domain.com:636 - but it would not allow us to add new users to sites via the People Picker on our production farm...tested same on our Test and Stage farms, and it seemed to work. FYI - I did not select Encryption or Secure, and did not put the entire path to the domain/containers - so trying to play with that a little bit to see what I may have missed...

[Yvand]

@mpatrick210 I did again additional tests to understand how to do LDAPS over SSL. It is more complicated than I thought. There are 2 operations to consider:

• LDAP bind: Authentication to the LDAP server using the credentials
• LDAP search: Doing a query on the LDAP server

Code that uses LDAPS over SSL only for the bind

Code below replays what LDAPCP can use to connect to the LDAP server. Unfortunately, only the LDAP bind will be using port 636 over SSL. The query itself will be executed unencrypted on port 389:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ldapUser = "contoso\spfarm"
# $ldapPassword = Read-Host "Enter the password (will appear in clear text)"
$ldapPath = "LDAP://dc.contoso.local:636/CN=Users,DC=contoso,DC=local"
$filter = "(&(objectClass=user)(|(sAMAccountName=yvand)(cn=yvand)))"
$contextOptions = [System.DirectoryServices.AuthenticationTypes] "SecureSocketsLayer, Encryption, Secure"

$directoryEntry = New-Object System.DirectoryServices.DirectoryEntry ($ldapPath, $ldapUser, $ldapPassword, $contextOptions)
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $directoryEntry
$objSearcher.Filter = $Filter
$objSearcher.SizeLimit = 2

$result = $objSearcher.FindOne()
$result

Code that uses LDAPS over SSL for both bind and search

I verified using the code below that, using class LdapConnection, it is possible to be full LDAPS over SSL for both LDAP bind and query operations

Add-Type -LiteralPath "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.DirectoryServices.Protocols.dll"
$ldapServer = "dc.contoso.local:636"
$ldapDistinguishedName = "DC=contoso,DC=local"
$filter = "(&(objectClass=user)(|(sAMAccountName=yvand)(cn=yvand)))"
$creds = New-Object System.Net.NetworkCredential ("spfarm", "<password>", "contoso.local")

$ldapConnection = New-Object System.DirectoryServices.Protocols.LdapConnection ($ldapServer)
$ldapConnection.SessionOptions.SecureSocketLayer = $true;
$ldapConnection.AuthType = [System.DirectoryServices.Protocols.AuthType]::Negotiate
$ldapConnection.Bind($creds)

$request = New-Object System.DirectoryServices.Protocols.SearchRequest($ldapDistinguishedName, $filter, [System.DirectoryServices.Protocols.SearchScope]::Subtree, @("mail"))
$response = $ldapConnection.SendRequest($request)
if ($response.ResultCode -eq [System.DirectoryServices.Protocols.ResultCode]::Success) {
    $entry = $response.Entries[0]
    $entry
} else {
    Write-Host "Error message: $($response.ErrorMessage)"
}

Unfortunately LDAPCP does not use this implementation, and I'm afraid it's not going that simple to add this. I will check but I make no promise. On your side, could you test both scripts to confirm my investigations are correct?

[mpatrick210]

@Yvand Thank you for the further details...I will test these on my test environment and let you know what I find. Thanks!

[Yvand]

@mpatrick210 I tried again and now both scripts fully use LDAPS over SSL. I'm not sure why I observed differently previously. But the outcome is that LDAPCP can use LDAPS over SSL if the path looks like this: LDAP://contoso.local:636/CN=Users,DC=contoso,DC=local" According to my tests the enum AuthenticationTypes does not even matter. Can you confirm this on your end?

[mpatrick210]

hey @Yvand I will test this approach...my last tests seemed to work on my dev/test farms, but for the production farm, it seemed to break...it would allow "some" users, but not all...it was very odd behavior

[mpatrick210]

Hey @Yvand just a quick follow up....I was able to get this to work, turns out it was an issue with cert chain...the reason it worked on lower tiers was that it only had 1 WFE, where as Prod had 6...thought I had update the cert on all of them, but missed a few, and caused the intermittent issues on some of teh WFEs. I appreciate your assistance and support on helping me try and figure this all out. :-) Have a great weekend!

[Yvand]

@mpatrick210 very good news, thanks for the update!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.