1

I have a client which uses Okta LDAP Interface facility. We have a LDAP v3 tool which connects with AD, Open LDAP other LDAP v3 supported servers.

We want to integrate Okta LDAP Interface into our tool as it is LDAPv3 Compatible. Our Code is based on .NET framework + C Sharp.

We are facing some issues/challenges while connecting with Okta LDAP Interface.

We use System.DirectoryServices by Microsoft library provided by microsoft currently. But facing issues with LDAP Interface.

For StartTLS/389

I get the error :

Unwilling to perform. LDAP Error Code 53

More: A secure connection cannot be established. To admin: This service requires TLS. LDAP

For SSL/636

Error: The server is not operational.

Links:

https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices?view=netframework-4.8

https://learn.microsoft.com/en-us/dotnet/api/system.directoryservices.directoryentry?view=netframework-4.8

https://ldapwiki.com/wiki/LDAP_UNWILLING_TO_PERFORM

var oktaLDAPPath = "LDAP://dev-506668.ldap.oktapreview.com:636/ou=users,dc=dev-506668,dc=oktapreview,dc=com";
        var un = "uid=*******,dc=dev-506668,dc=oktapreview,dc=com";
        var pass = "*******";
        var filter = "((objectClass=*))";
        try
        {
            using (var userDirectoryEntry = new DirectoryEntry(oktaLDAPPath, un, pass,AuthenticationTypes.SecureSocketsLayer))
            { 
                using (var directorySearcher = new DirectorySearcher(userDirectoryEntry, filter) { PageSize = 100 })
                {
                    directorySearcher.FindOne();
                }
            }
        }
        catch (DirectoryServicesCOMException dex)
        {

        }
        catch (Exception ex)
        {

        }

Thanks

CodeConstruct
  • 290
  • 3
  • 17

2 Answers2

1

Update: So I did some testing for myself. I see what's going on.

If you do a DNS lookup on dev-506668.ldap.oktapreview.com, it gives you a CNAME result to op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com.

A browser will use the IP address of the CNAME, but still make the request with the host name that you originally gave it. However, for some reason, when starting an LDAP connection, Windows is using the CNAME to iniatate the connection.

In other words, Windows is changing the request to LDAP://op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com:636. But then it receives the SSL certificate which has the name *.ldap.oktapreview.com and it panics because that doesn't match the name it used to make the request (op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com).

I verified all of this using Wireshark, monitoring traffic on port 636. The SSL Client Hello is using op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com instead of dev-506668.ldap.oktapreview.com.

I don't know of a way to make it not do that. DirectoryEntry has no way to override how it verifies the SSL certificate either. LdapConnection does, which you can see here, but it might be a little harder to work with. I've never used it. (you probably should do some verification of your own and no just return true like that example does).

This might be something you can share with Okta Support anyway.

Original answer:

It sounds like your computer does not trust the SSL certificate that is used on the server. To verify this, I use Chrome. You have to start Chrome like this:

chrome.exe --explicitly-allowed-ports=636

Then you can put this in the address bar:

https://dev-506668.ldap.oktapreview.com:636

If the certificate is not trusted, you will get a big error saying so. You can click the 'Advanced' button to see the reason Chrome gives for it not being trusted. But Chrome will also let you inspect the certificate by clicking on "Not secure" in the address bar to the left of the address, then click 'Certificate'.

There a couple reasons it might not be trusted:

  1. The fully-qualified domain name you are using (dev-506668.ldap.oktapreview.com) doesn't match what is on the certificate. If that's the case, you might be able to just change the domain name you use to match the certificate.
  2. The certificate is not issued by a trusted authority. It could be a self-signed certificate. If this is the case, then you should see an "Install Certificate" button when you view the certificate, which you can use to explicitly trust the certificate. See here for screenshots, starting on step 3. This will only apply to the current computer.
Gabriel Luci
  • 38,328
  • 4
  • 55
  • 84
  • Hi thanks for your reply, Certificate name is *.ldap.oktapreview.com and this work fine with other LDAPv3 compatible client applications like Apache Directory Studio and LDAPAdmin. – CodeConstruct Jul 23 '19 at 15:56
  • Does the certificate show as trusted on the computer you are testing this on? – Gabriel Luci Jul 23 '19 at 16:03
  • Yes, It shows as trusted, I have placed it on Trusted Root Certification Authorities – CodeConstruct Jul 24 '19 at 03:38
  • https://help.okta.com/en/prod/Content/Topics/Directory/LDAP_Using_the_LDAP_Interface.htm This is what Okta's LDAP Interface is all about. – CodeConstruct Jul 24 '19 at 03:42
  • " * " is a wildcard symbol which means it can be used with any .ldap.oktapreview.com. – CodeConstruct Jul 26 '19 at 06:08
  • There is definitely no firewall in the way? (you can test the connection in PowerShell with `Test-NetConnection dev-506668.ldap.oktapreview.com -Port 636`) Is there anything in the Windows Event Viewer after the connection fails? (Application or System logs) – Gabriel Luci Jul 26 '19 at 12:09
  • Powershell test results in TcpTestSucceeded : True – CodeConstruct Jul 27 '19 at 06:55
  • And get this in System logs - The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com. The TLS connection request has failed. The attached data contains the server certificate. – CodeConstruct Jul 27 '19 at 06:57
  • That's saying that the certificate does not contain the domain name you're connecting to. That will do it. – Gabriel Luci Jul 27 '19 at 12:13
  • Yeah, I contacted with Okta Support and they responded that they can only provide wildcard certificate. This is sad – CodeConstruct Jul 29 '19 at 05:15
  • Thanks @Gabriel Luci. Yeah I am planning to implement the link you provided as of now as thats the only solution, and share this with Okta Dev Support. Hopefully they come up with a solution to this. I really appreciate you help. Thank you very much. – CodeConstruct Jul 29 '19 at 13:33
0

I recently ran into this issue and was pointed to the following solution:

Add the following registry key as a DWORD set to 1, then restart the server and see if it fixes the issue.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP\UseHostnameAsAlias

See relevant Microsoft KB article for more details.

Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
Tony Perri
  • 1