LDAPS (only) implementation - feature request

I would like to have an ldaps implementation. In our environment the domain controllers only accept connection using ldaps on port 636, so nomad fails to connect/query. You can easily test it by creating a self signed certificate using IIS management console (I found this is the easiest and fastest way). Afterwards you should get an eventlog entry that the machine listens on 636. Thanks!

changed milestone to %v. 1.0.3

assigned to @Mactroll

Is the SSL cert your using on the AD DCs publicly trusted? I believe I have NoMAD working on port 636 now, but the cert trust for openLDAP is probably not something that NoMAD will handle on it's own.

I /believe/ that if you add the root cert to the Keychain on the Mac openLDAP will use it... otherwise you'll have to edit the openldap conf file.

defaults write com.trusourcelabs.NoMAD LDAPoverSSL 1

and try the attached binary.

NoMAD-1.0.3_502_.zip

No, certificates are from an internal pki. Root certificates have been added to system keychain. Unfortunately it does work with the new binary and the "defaults write" command. In console, after applying a filter to "nomad", these entries are shown:

level: debug - Did Receive Query Result: [{ port = 389; priority = 0; target = "##dc1.domain.local"; weight = 100; }, { port = 389; priority = 0; target = "##dc2.domain.local"; weight = 100; }]

So, it looks as it successfully received the correct domain controllers, but the wrong port is still used.

Also: level: info - Site "DNSDummy" found. level: notice - Looking up DCs for site. level: debug - Query Error: The operation couldn’t be completed. (kDNSResolverErrorDomain error -65554.)

But DNS should be set up correctly.

Everytime NoMAD stops, this message is logged: AMFI: allowing exception handler for 'NoMAD' (2665) because the process is not restricted.

The "Did Receive Query Result" is just the DNS response from looking up the SRV records, so that's not an issue as we don't use that for anything.

Although it should be noted, that your DNS is implying that LDAP works over 389.

dig -t SRV _ldap._tcp.domain.com Will show you what's actually being returned.

The "kDNSResolverErrorDomain" error implies a DNS lookup error for the DNSDummy site.

Let me see about setting up LDAP over SSL on our test environment and I'll be able to explore more.

Once you have a kerberos ticket, via kinit, can you perform ldap lookups agains the domain controller?

ldapsearch -LLL -Q -N -H ldaps://server.domain.com -s base

For example?

I see... "dig -t..." returns the domain controllers with port 389. I'm not sure if it's possible to change. However, do we have a chance to ignore it in NoMAD and force 636? ldapsearch using to command above results in "ldap_result: Can't contact LDAP server (-1)". When changing it to "ldapsearch -LLL -Q -N -p 636 -h server.domain.com -s base" it returns "ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)"

No worries about the 389 DNS returns, as I said, we ignore that.

For the ldapsearch, can you try this:

ldapsearch -LLL -Q -N -O maxssf=0 -p 636 -h server.domain.com -s base

Try this build. It has the maxssf set for LDAPS connections and has been tested successfully in our lab. NoMAD-1.0.3_504_.zip

added Ready for Testing label

This ldapsearch command shows the same error: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Unfortunately there's no change when using the new build - the application starts and closes after 1-2 seconds. Are there any settings I should flush?

can you reach out to me on the #nomad Slack channel? It may be easiest to do some interactive troubleshooting for this.

closed