OPNsense Forum
Archive => 21.1 Legacy Series => Topic started by: gromit on February 18, 2021, 10:11:19 pm
-
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:
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. :(
-
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 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
-
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
-
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
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
-
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.)
-
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?
-
from what I see I would add
} 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
-
tested small changes.
it is possible to receive such diagnostics (see attachments)
I don't know if it's worth the PR
-
Why don't you do what I suggested? You will see all LDAP errors in full that way.
-
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.
-
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.
-
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.
-
can you try this changes to add some debug to Tester and try again?
in /usr/local/www/diag_authenticatiopn.php add
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
$input_errors[] = gettext("Authentication failed.");
string
in /usr/local/opnsese/mvc/app/library/opnsense/auth/ldap.php add
$this->lastAuthProperties['error'] = $error_string;
$this->lastAuthProperties['ldap_error'] = ldap_error($this->ldapHandle);
after
syslog(LOG_ERR, sprintf($message . " [%s,%s]", $error_string, ldap_error($this->ldapHandle)));
string in logLDAPError function
and add
else {
$this->lastAuthProperties['error'] = "User DN not found";
}
after brace in
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
-
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
-
Just to note, there's already a pull request related to this: https://github.com/opnsense/plugins/pull/2166
Thanks!
-
can you try this changes to add some debug to Tester and try again?
in /usr/local/www/diag_authenticatiopn.php add
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
$input_errors[] = gettext("Authentication failed.");
string
in /usr/local/opnsese/mvc/app/library/opnsense/auth/ldap.php add
$this->lastAuthProperties['error'] = $error_string;
$this->lastAuthProperties['ldap_error'] = ldap_error($this->ldapHandle);
after
syslog(LOG_ERR, sprintf($message . " [%s,%s]", $error_string, ldap_error($this->ldapHandle)));
string in logLDAPError function
and add
else {
$this->lastAuthProperties['error'] = "User DN not found";
}
after brace in
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
I added the above debugging code and now when I use Tester I get this error:
The following input errors were detected:
- Authentication failed.
- error: User DN not found
I have tried to use the same LDAP server configuration options that I use with the same LDAP server on pfSense. The pfSense setup works (or at least worked). The two setup screens aren't parallel in how you specify the configuration (e.g., pfSense has an explicit specification for CA), so I'll go back and double-check to see if I haven't made any obvious mistakes.
-
PS: The extra debugging info output by Tester is very helpful. It would be great if this could be added to the OPNsense release itself.
-
so I'll go back and double-check to see if I haven't made any obvious mistakes
as you can see in the proposed code, the "User DN not found" error occurs when the user's search does not return any results. that is, the binding itself is successful. so it's not about the SSL params.
search uses username from tester input, "User naming attribute" from server config and "Extended Query" from server config (if any). plus underlying search function uses "Base DN" and "Authentication containers" (if any) from server config.so I would pay attention to these parameters of server config
-
so I'll go back and double-check to see if I haven't made any obvious mistakes
as you can see in the proposed code, the "User DN not found" error occurs when the user's search does not return any results. that is, the binding itself is successful. so it's not about the SSL params.
search uses username from tester input, "User naming attribute" from server config and "Extended Query" from server config (if any). plus underlying search function uses "Base DN" and "Authentication containers" (if any) from server config.so I would pay attention to these parameters of server config
I double-checked the working pfSense configuration against the OPNsense configuration and didn't see any obvious differences.
It turns out the problem may stem from misleading help text and that the solution ultimately turned out to be straightforward.
The problem lay with the setting in "Authentication containers." The help text states this: "Semicolon-separated list of distinguished names optionally containing DC= components" (my emphasis). Indeed, in my working pfSense setup I have only "ou=People" for this, and that is the value I was using in OPNsense.
What got authentication working was to append the base DN to this value to fully qualify it. ???
Another odd difference is that in the pfSense setup I can press the "Select a container" button alongside the "Authentication containers" setting and it will pop up a window with a couple of entries (including the one with "ou=People"). OPNsense always just pops up an empty list.
-
What got authentication working was to append the base DN to this value to fully qualify it.
I think it's worth a ticket on github: either change the help text or attach a basedn to the container in the search function
I can press the "Select a container" button alongside the "Authentication containers"
tried without specifying a "Authentication containers"? with "base dn" only
(button uses the same search function, which does not attach the basedn to the container) <- error:
listOUs function not using auth containers when searching for OUs.
-
I can press the "Select a container" button alongside the "Authentication containers"
tried without specifying a "Authentication containers"? with "base dn" only
(button uses the same search function, which does not attach the basedn to the container)
This is even when pressing "Select a container" with the fully-specified DN entered in the setting field. It also has the unfortunate side effect of clearing the "Authentication containers" setting if you dismiss the pop-up window via the "Close" button (given there's nothing to select in the pop-up).
-
setting if you dismiss the pop-up window via the "Close" button (given there's nothing to select in the pop-up)
hm. agree. it looks like the button can be renamed to Save. and modal should be closed by 'x' button in this case
This is even when pressing "Select a container" with the fully-specified DN entered in the setting field
I have a feeling that when calling the lists of containers with this button, the value of this field is not involved in the search. only baseDN. "Authentication containers" values are used to check for matches and mark the matched containers as selected in the result table. so can you try with empty "Authentication containers" and Base DN only?
-
I have a feeling that when calling the lists of containers with this button, the value of this field is not involved in the search. only baseDN. "Authentication containers" values are used to check for matches and mark the matched containers as selected in the result table. so can you try with empty "Authentication containers" and Base DN only?
When I try the "Select" button alongside "Authentication containers" with just a base DN and the "Authentication containers" field empty I get an empty popup as a result.
I have not been able to find any combination of inputs in OPNsense that will yield anything but an empty popup.
-
can you try to modify listOUs function in /usr/local/opnsese/mvc/app/library/opnsense/auth/ldap.php:
before:
if ($searchResults !== false) {
for ($i = 0; $i < $searchResults["count"]; $i++) {
$result[] = $searchResults[$i]['dn'];
}
after:
if ($searchResults !== false) {
$this->logLdapError("LDAP containers search result count: " . $searchResults["count"]);
for ($i = 0; $i < $searchResults["count"]; $i++) {
$result[] = $searchResults[$i]['dn'];
}
try to "Select" again and look General log for some ldap errors?
-
can you try to modify listOUs function in /usr/local/opnsese/mvc/app/library/opnsense/auth/ldap.php:
before:
if ($searchResults !== false) {
for ($i = 0; $i < $searchResults["count"]; $i++) {
$result[] = $searchResults[$i]['dn'];
}
after:
if ($searchResults !== false) {
$this->logLdapError("LDAP containers search result count: " . $searchResults["count"]);
for ($i = 0; $i < $searchResults["count"]; $i++) {
$result[] = $searchResults[$i]['dn'];
}
try to "Select" again and look General log for some ldap errors?
I modified the code as given above and tried "Select" again. The result was the same (nothing in the popup) and also no errors appeared in "System: Log Files: General".
-
I'm sorry, I probably didn't guess the place where we need to catch the error (it worked for AD in my case).
If you are not tired yet, can you try to replace the listOUs function with (try to log it from another place also):
public function listOUs()
{
$result = array();
if ($this->ldapHandle !== false) {
$searchResults = $this->search("(|(ou=*)(cn=Users))");
if ($searchResults !== false) {
$this->logLdapError("LDAP containers search result count: " . $searchResults["count"]);
for ($i = 0; $i < $searchResults["count"]; $i++) {
$result[] = $searchResults[$i]['dn'];
}
return $result;
} else {
$this->logLdapError("LDAP containers search returned no results");
}
}
return false;
}
-
I replaced the listOUs code with the version with extra debugging. When I try "Select" afterwards, I get this in the general log file:
LDAP containers search returned no results [,Time limit exceeded]
OPNsense doesn't let you set a timeout in the LDAP server setup, and in the pfSense version I do set this to 60 in order to allow extra time for the Duo second factor challenge to be completed during actual authentication attempts. However, in the OPNsense case, it takes > 20 seconds for the popup to appear after pressing select whereas in the pfSense setup it pops up immediately. I'm taking this to indicate that whatever search the OPNsense version is doing is not completing (or not completing in a timely fashion) whereas the pfSense search is completing quickly.
-
well, at least some result )
(will try to make PR to add this debug info too)
Time limit exceeded
hm. have you tried with "One level" in "Search scope" parameter?
and imho (not tested) you can try to play with timelimit in ldap_list and ldap_search functions in search function.
can try to make it like (for 60 sec limit. if LDAP server allows it) in search function:
if ($this->ldapScope == 'one') {
$sr = @ldap_list($this->ldapHandle, $baseDN, $filter, $this->ldapSearchAttr, 0, 0, 60);
} else {
$sr = @ldap_search($this->ldapHandle, $baseDN, $filter, $this->ldapSearchAttr, 0, 0, 60);
}
-
hm. have you tried with "One level" in "Search scope" parameter?
and imho (not tested) you can try to play with timelimit in ldap_list and ldap_search functions in search function.
can try to make it like (for 60 sec limit. if LDAP server allows it) in search function:
if ($this->ldapScope == 'one') {
$sr = @ldap_list($this->ldapHandle, $baseDN, $filter, $this->ldapSearchAttr, 0, 0, 60);
} else {
$sr = @ldap_search($this->ldapHandle, $baseDN, $filter, $this->ldapSearchAttr, 0, 0, 60);
}
I am using "One Level" in the "Search scope" parameter, which is the setting I took from the working pfSense setup.
I applied the suggested code change but it didn't make any difference. The popup also appeared after the same amount of time, too, as far as I could discern. I did manually restart the WebGUI via /usr/local/etc/rc.restart_webgui after making the edit.
Note, the LDAP server works for me in OPNsense as far as authentication is concerned. It's only the "Select" popup that doesn't, and given this is basically used to know what to put in the "Authentication containers" setting, I can say it's a moot point it not working for me (as I've figured out via trial and error what to put in there). :)
I consider this "solved" for me, though I am willing to help test things if you want.
-
I consider this "solved" for me, though I am willing to help test things if you want
thanks for sharing the results.
if the main problem is solved, then I suggest stopping at this. further research would be more convenient to carry out with access to the ldap server ;)
all the diagnostic additions mentioned in the topic except the last one have already been merged by @AdSchellevis. I will try to make a request to add the latter (with a timelimit diagnostic message).
Thanks again, imho the result is quite good additions to the tester page
-
Thank you for all your help, and I agree that more information in the "Tester" page is a welcome addition.