How to increase logging for debugging of LDAP authentication setup?

[gromit]

I'm converting a pfSense 2.4.5_1 HA firewall setup over to an OPNsense 21.1.1 setup and am having trouble getting LDAP authentication working successfully on OPNsense.

I believe I've figured out the correspondence from the working pfSense config to OPNsense.  However, in pfSense there's a "Peer Certificate Authority" setting in the LDAP server setup whereas there is nothing corresponding to that in OPNsense.  Apparently, you are supposed to just ensure that all the certificates presented by the LDAP server are in the Trust settings.

Well, I've put what I believe are all the certificates into Trust but, using the System : Access : Tester all I get is this:

The following input errors were detected:

• Authentication failed.

I can't find any errors logged relating to this under System : Log Files : General.

Is there some other place I can look for logging information relating to LDAP?  (It would be helpful if the "Tester" would output more verbose debug information, at least as an option.)  It would be nice to know at which stage it is failing.

Is it possible to increase the verbosity of the LDAP auth process to debug this problem.  It's frustrating that this works on pfSense but I can't get it to work on OPNsense. 

[Fright]

hi
can you try to press Select button on "Authentication containers" row on ldap-server config and look for new error in general log (should be something like "LDAP bind error")?

[Patrick M. Hausen]

When debugging LDAP I personally like to do the following:

• Configure stunnel to listen on 127.0.0.1:389 unencrypted and to relay to ldap-server:636 with SSL
• Configure your LDAP authentication to use 127.0.0.1:389 without SSL
• tcpdump -i lo0 -n -s0 -X port 389

You will see unencrypted authentication attempts including passwords that way. But they won't leave the local OPNsense machine and your SSH session, so it's not a big deal if you are the trustworthy admin.
LDAP error messages are mostly ASCII and rather verbose. I have always figured it out that way - up until now.

HTH,
Patrick

[Fright]

in theory php supports error and diagnostic messages. and mvc ldap.php adds error_string to system log.
the question is where the transport errors go: to ERROR_STRING or DIAGNOSTIC_MESSAGE. I'll try to check

[Fright]

quick checked: delete my internal trusted root CA cert from trusted CAs, tried to select 'Authentication containers' in System: Access: Servers->Server config. get empty list and

Code: [Select]

LDAP bind error [error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get local issuer certificate),error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get local issuer certificate),Can't contact LDAP server]in General log
TLS error goes to ERROR_STRING and to DIAGNOSTIC_MESSAGE

[gromit]

hi
can you try to press Select button on "Authentication containers" row on ldap-server config and look for new error in general log (should be something like "LDAP bind error")?

When I do that there is a delay and then eventually I get an empty popup headed "Please select which containers to Authenticate against:".  I don't get anything showing up in the General log section.

Note, I don't expect anything to show up in the popup showing the containers because I'm doing an anonymous bind ("Bind credentials" are empty in this section) and the target LDAP only shows "public" information in return for anonymous binds.

That's okay for my purposes.  I only want to use this LDAP server for authentication, not other user information such as group memberships and such.  I'm happy to keep all of that other stuff in the local user database.  I only want LDAP for user authentication (so that people can use their centrally-managed password).  This setup works fine under pfSense 2.4.5_1 (and seems to have done so for many years).  The semantics there appear to be that, during authentication, if an LDAP bind succeeds with the given username and password then authentication has deemed to have succeeded for that user.

As a final complication, the target LDAP server is actually a Duo authentication proxy.  My preferred method of specifying my second factor is to supply the token directly as part of the password (i.e., "<password>,<token>").  The <token> is generated by my YubiKey.  The "<password>,<token>" encoded password can be fairly long---mine is 77 characters currently.

Is there a limitation on the length of input passwords?  (If so, this limitation does not appear to affect pfSense.)

[Fright]

Is there a limitation on the length of input passwords? 

tested with 80-character AD password. works

When I do that there is a delay and then eventually I get an empty popup headed "Please select which containers to Authenticate against:".  I don't get anything showing up in the General log section

so bind is successful?
can you try to add test user to 'Bind credentials' and request "Authentication containers" again? maybe then something will appear in the log?

[Fright]

from what I see I would add

Code: [Select]

                } else {
                    $this->logLdapError("User DN not found");
                }

at line #564 of
https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php

[Fright]

tested small changes.
it is possible to receive such diagnostics (see attachments)
I don't know if it's worth the PR

[Patrick M. Hausen]

Why don't you do what I suggested? You will see all LDAP errors in full that way.

[gromit]

Many thanks for all your help so far.

Is there a limitation on the length of input passwords? 

tested with 80-character AD password. works

That is good to know.

When I do that there is a delay and then eventually I get an empty popup headed "Please select which containers to Authenticate against:".  I don't get anything showing up in the General log section

so bind is successful?

It's not clear to me whether the bind with the username and password succeeds.  One of the possible second factors I have associated with my account is a regular telephone.  If I supply my password as "<password>,phone" then it will force using the phone as my second factor.  If the bind succeeds, I should get a call to that phone number and have it ring as part of the second factor challenge.  That didn't happen when I tried it, making me think that the authenticated bind did not succeed.  (This LDAP authentication succeeds if the user bind succeeds AND the associated Duo second factor challenge succeeds.  The fact I don't get a phone call makes me think the first step of binding as a user is not succeeding.)

can you try to add test user to 'Bind credentials' and request "Authentication containers" again? maybe then something will appear in the log?

Unfortunately, the LDAP server in question is managed by our central division of IT and contains only production usernames.  Thus, I am not able to create a test user.  I will try a one-shot test using my user credentials, though.

[gromit]

Why don't you do what I suggested? You will see all LDAP errors in full that way.

I did try what you suggested but didn't appear to have success.     It may have been pilot error on my part, though, as I haven't used stunnel before.  I will try again.

[Patrick M. Hausen]

The stunnel part is optional. It's just a way to get an unencrypted connection without transferring everything in the plain over the wire. If this is a small controlled environment you can of course just use plain LDAP on port 389.

I just tried to recreate the config I suggested to send you a screenshot and embarrassingly enough stunnel on OPNsense does not support client mode. Sorry! In pfSense it does.

OK, now I know which plugin I am working on next. This is essential.

So you are really stuck with using plain text LDAP if you want to use tcpdump.

[Fright]

can you try this changes to add some debug to Tester and try again?
in /usr/local/www/diag_authenticatiopn.php add

Code: [Select]

            foreach ($authenticator->getLastAuthProperties() as $attr_name => $attr_value) {
                if (is_array($attr_value)) {
                    $attr_value = implode(",", $attr_value);
                }
                $input_errors[] = "{$attr_name}: {$attr_value}";
            }

after

Code: [Select]

            $input_errors[] = gettext("Authentication failed.");
string


in /usr/local/opnsese/mvc/app/library/opnsense/auth/ldap.php add

Code: [Select]

            $this->lastAuthProperties['error'] = $error_string;
            $this->lastAuthProperties['ldap_error'] = ldap_error($this->ldapHandle);
after

Code: [Select]

            syslog(LOG_ERR, sprintf($message . " [%s,%s]", $error_string, ldap_error($this->ldapHandle)));
string in logLDAPError function
and add

Code: [Select]

else {
                    $this->lastAuthProperties['error'] = "User DN not found";
                }
after brace in

Code: [Select]

                if ($result !== false && count($result) > 0) {
                    $user_dn = $result[0]['dn'];
                    $ldap_is_connected = $this->connect($this->ldapBindURL, $result[0]['dn'], $password);
                }
in authenticate function

[crayon]

The stunnel part is optional. It's just a way to get an unencrypted connection without transferring everything in the plain over the wire. If this is a small controlled environment you can of course just use plain LDAP on port 389.

I just tried to recreate the config I suggested to send you a screenshot and embarrassingly enough stunnel on OPNsense does not support client mode. Sorry! In pfSense it does.

OK, now I know which plugin I am working on next. This is essential.

So you are really stuck with using plain text LDAP if you want to use tcpdump.

Just to note, there's already a pull request related to this: https://github.com/opnsense/plugins/pull/2166