LDAPS - Recommendations for a read-only troubleshooting utility?

Question

I'm trying to find a good tool for a customer service team to better qualify LDAPS issues. When a customer enters their LDAPS details into our client and it errors, I'd like the customer service team to be able to qualify the issue by reproducing the same connection/bind/search in another utility as well to see if the same error happens, etc.

What tool would you recommend for that use case?

Ideally:

• Runs on Windows
• Can test connection, test authentication (bind user DN), enter search base/search filter to test searching for a specific user
• Pretty lightweight
• Does not require elevated rights to run
• Has a read-only mode. Bonus points if it simply doesn't have create/modify/delete capabilities or can be shipped with read-only mode locked on from the get-go
• Bonus points: It's easy for a customer to see on a single screen the results of the testing

Tools I'm already aware of:

• Apache Directory Studio - This is pretty perfect on the one hand, but the cons: It does far more than I need. It required tinkering to get it working (download OpenJDK 11 specifically, modify an ini file with the path). If there's something similar but more lightweight that wouldn't require training this team of people or having them follow a guide to get it up and running, that would be ideal. However, it is easy to use and does have a read-only mode; if there's a way to enable that permanently that would be attractive.
• ldp.exe - I've been burned by ldp once so far. An issue that did not occur in ldp did occur in the app I was troubleshooting and in Apache Directory Studio. Not sure what to make of that. I believe this is because ldp has a "User" field, but not a "user bind DN" field, so the test was not equivalent. I need to be able to test with the same user bind DN value the customer has entered into our app. Also, this is not a read-only tool and does more than I need.
• ldapsearch.exe - Hard to find a Windows binary of ldapsearch from a legit looking source these days. Not read-only. Looks like it's been superseded by dsquery.
• dsquery - Not read-only.
• Powershell - Maybe some sort of existing Powershell script would be the best option? Not sure what's possible.

Answer 1

You could use the inbuilt .NET classes [ADSI] & [ADSISearcher] in Powershell.

Specifying ports in the ADSI object can be handy for troubleshooting blocked ports. This is probably the cause of your ldp.exe woes, port 389 might be blocked by firewall, so it may have used port 636 instead and worked. Meanwhile your Apache server might only use 389, and cannot connect.

Try {
    # Create ADSI object
    $LDAPConnection = [ADSI]::new("LDAP://adserver1")
    # Open Connection
    $LDAPConnection.RefreshCache()
} catch {
    Write-Host -ForegroundColor Red $Error[0].InnerException.Message
    # Get Credentials for authenticate
    $Cred = Get-Credential
    # Create ADSI object with credentials
    $LDAPConnection = [ADSI]::new("LDAP://adserver1", $Cred.UserName, $Cred.GetNetworkCredential().Password)
    # Open Connection
    $LDAPConnection.RefreshCache()
}

# Other examples
# Open LDAP Connection with a specific port
    # Create ADSI object using port 389
    $LDAPConnection = [ADSI]::new("LDAP://adserver1:389")
    # Open Connection
    $LDAPConnection.RefreshCache()

# Utilize ADSISearcher for read-only
    # Create ADSI object using port 389
    $LDAPConnection = [adsisearcher][ADSI]::new("LDAP://adserver1:389")
    # LDAPFilter for current user
    $LDAPConnection.Filter = "(&(samaccountname=$Env:USERNAME)(objectclass=user))"
    # Open Connection / Search for user
    $LDAPConnection.FindOne()