auth_ldap for Apache 1.3: a patch to allow anonymous binds to work properly.

Go directly to: update (2006-02-22) | patch

auth_ldap is a module for Apache 1.3 by Dave Carrigan.

On Jul 4, 2001, auth_ldap 1.6.0 was released.
On Jan 9, 2006, auth_ldap 1.6.1 was released. This release fixes a security issue, and incorporates other contributed patches into auth_ldap.

The following info deals with auth_ldap 1.6.0. For an update, scroll to the bottom of this page.

The module (auth_ldap 1.6.0) seems to work fine, except under certain circumstances.

Brent Putnam wrote a patch in December 2001, but unfortunately that patch never got into the release.

Here's the reason why he wrote the patch:

Hello everyone,
There have been reports previously on the list that auth_ldap was
inconsistently binding as the AuthLDAPBindDN in order to search for
non-publicly visible user accounts, making authentication of these
accounts unreliable. We have to restrict public visibility of some
users in our environment, so we rely on this feature heavily. I have
debugged this problem and written a patch that I believe addresses it.
The patch is attached.

The problem was happening apparently because in
ldap_authenticate_basic_user(), when the module binds as the actual user trying to authenticate, the boundas flag of the LDAPconnection struct was being set to bind_user. However, the bounddn member was not being changed - so it was still set to the AuthLDAPBindDN value from the first, initial search bind.

Then on the next authentication by that httpd child process, in auth_ldap_find_connection() bounddn is compared to the configuration sec->binddn value (AuthLDAPBindDN) and since they
match, boundas is set to bind_system.

Then finally in auth_ldap_connect_to_server() since boundas is now set to bind_system, it returns immediately without rebinding - however the LDAP server connection at this point is still bound as the last successfully authenticated user, and it is as that DN that the directory search is being done for the new user. If that DN doesn't have permissions to see the new non-public user that is trying to authenticate, the search fails and the new user can't authenticate.

The non-public user would be successful if he/she were the first user to authenticate via that httpd child process, because for the very first
search, it _would_ bind as AuthLDAPBindDN. What was interesting was that if the last user to successfully authenticate on that particular
httpd child process was the same non-public user currently trying to
authenticate, the authentication would succeed - because a DN typically has permissions to search for and find itself!

The patch basically just ensures that when boundas is set to bind_user, bounddn is set to the user's DN, and when boundas is set to bind_none, bounddn is set to NULL. I also added the PID to the debug error output for the failed search message.

Comments and suggestions are welcome.

Thanks,
Brent Putman
Georgetown University

After applying the patch, I discoverd there where still problems when AuthLDAPBindDN was not set (thus binding anonymously).

Stig Venaas wrote a patch to solve both problems, in February 2004.

His explanations:

I've looked at the problem, and I think I have a solution. I haven't actually tested it though, since I don't have a test environment ready.

It seems to me that the patch is solving this the wrong way, and it
has some side effects for anonymous binds. It tries to set bounddn
to NULL to show an error, using the fact that NULL is different
from binddn, but in the anonymous case, binddn IS NULL.

The patch does this because, as it says in the patch description:

The problem was happening apparently because in ldap_authenticate_basic_user(), when the module binds as the actual user trying to authenticate, the boundas flag of the LDAPconnection struct was being set to bind_user. However, the bounddn member was not being changed - so it was still set to the AuthLDAPBindDN value from the first, initial search bind. Then on the next authentication by that...

So it tried to work around the bug that the bounddn wasn't changed.
Rather than doing what the patch does, I think one should make sure
that bounddn is changed after every successful bind.

If you look for simple_bind_s() in auth_ldap.c, you will find it in
two places. At the first place, you will a few lines below see this:

sec->ldc->bounddn = sec->binddn? strdup(sec->binddn) : NULL;
sec->ldc->boundas = bind_system;

While at the second place, it does this:

sec->ldc->boundas = bind_user;
if ((result =
ldap_simple_bind_s(sec->ldc->ldap, sec->dn, const_cast(sent_pw))) ==
LDAP_SERVER_DOWN) {
ap_log_rerror(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, r,
"{%d} Server is down; reconnecting and starting over", (int)getpid());
auth_ldap_free_connection(r, 1);
goto start_over;
}

if (result != LDAP_SUCCESS) {
auth_ldap_log_reason(r, "User bind as %s failed: LDAP error: %s; URI %s",
sec->dn, ldap_err2string(result), r->uri);
ap_note_basic_auth_failure(r);
RELMUTEX(conf->mtx);
RELMUTEX(sec->ldc->mtx);
return AUTH_REQUIRED;
}

So, as you can see, it sets boundas even if bind fails, and it never
sets bounddn!

I would move boundas and set bounddn after the test for LDAP_SUCCESS.

To conclude, I think you should forget that other patch, and use the
patch below instead. At least the change seems pretty logical to me
(after spending an hour, trying to see what really happens, in
hindsight I think I should have seen it immediately:) Because I'm
paranoid, I also added a check that the the dn returned by
ldap_get_dn() isn't NULL. If something is wrong ldap_get_dn() will
return NULL, which would result in anonymous bind instead of the
user bind, so the user would be authenticated without really
checking the password.

I've not tested this, I may have missed something. Let me know how
it goes.


Unfortunately, after applying Stig's patch, there still was a problem, which I described, very fuzzy, as:

If you try to login with a non-existing username, the result is that the browser displays 'Authententication is needed' and does NOT redisplay the password prompt. You can reload untill you weigh an ounce, but it will always display that page and never give you a chance to supply username/pass again.

Opera even says ' the browser send a reply code that we don't understand' or something along those lines.

Konquerer has no problems whatsoever.

But Galeon, IE (win), Mozilla, Netscape (win) all display that page and then you have to close the browser to get to that password popup-box again!


Solved by Stig thusly:

Anyway, I think I have good news!!! It just took me a while to find it. AFAICT things are working with the patch I suggested,
except for this problem with not getting new authentication request if wrong username.

After a lot of checking I was 100% it sent AUTH_REQUIRED in both cases. Finally my brain connected and I realised that then something else must be different. And I found it (:

When it works, it does "ap_note_basic_auth_failure(r);" before it
returns AUTH_REQUIRED. In the case where it doesn't find exactly
1 match, this is not done.

So, if you look at the code at about line 635, you see:

ldap_msgfree(res);
RELMUTEX(conf->mtx);
RELMUTEX(sec->ldc->mtx);
return sec->auth_authoritative? AUTH_REQUIRED: DECLINED;
}

What you need to do, is add ap_note_basic_auth_failure(r);
before the RELMUTEX stuff I think. So, change to this:

ldap_msgfree(res);
ap_note_basic_auth_failure(r);
RELMUTEX(conf->mtx);
RELMUTEX(sec->ldc->mtx);
return sec->auth_authoritative? AUTH_REQUIRED: DECLINED;
}

I tried to check whether the bind logic is ok, and it looks to me
like the search is always done as anonymous with the patch I
suggested earlier.


Update Feb 22, 2006

After I downloaded, compiled and installed auth_ldap 1.6.1, which incorporates the patches that Stig Venaas made, I noticed several problems. First of all, I couldn't log in anymore. The error in the apache error log was:

Could not connect to LDAP server: No such file or directory

It turns out that this can be resolved by commenting a couple of lines in auth_ldap.c:

//#if defined(WITH_OPENLDAP) && LDAP_VENDOR_VERSION >= 20000
//if ((ldap_initialize(&(sec->ldc->ldap), (sec->url))) != LDAP_SUCCESS) {
//#else
if ((sec->ldc->ldap = ldap_init(sec->host, sec->port)) == NULL) {
//#endif

For a discussion about this, and a proper patch, look here.

After this problem was solved, there where intermittent login problems, much like the ones that we experienced before Stig Venaas patched auth_ldap 1.6.0.

To resolve this issue, Dave Carrigan (the author of auth_ldap) has suggested that I add the security fix (which is only one line of code) to the patch for 1.6.0.

Message-ID: <43FB85A1.8010202@rudedog.org>
Date: Tue, 21 Feb 2006 13:26:57 -0800
From: Dave Carrigan
To: ace@xxxxxx.an

Ace Suares wrote:

> My entire environment is broken now, and I need to
> restart the webserver often to allow people to login.
> And I can't go back to 1.6.0.

If all you want from 1.6.1 is the security fix, then you should go back to your copy of 1.6.0 and make the following change:

Around line 90, change the line that reads

ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, r, buf);

To

ap_log_rerror(APLOG_MARK, APLOG_ERR|APLOG_NOERRNO, r, "%s", buf);

Dave Carrigan


Patch

You can find the gzipped patch here.
This is a patch for auth_ldap 1.6.0!

How to apply the patch:

• download auth_ldap-1.6.0 from www.rudedog.org


• download this patch


• as root, type:
  gunzip auth_ldap-1.6.0.tar.gz
  gunzip auth_ldap-1.6.0-stig_venaas_plus_security.patch.gz
  tar xf auth_ldap-1.6.0.tar
  cd auth_ldap-1.6.0
  patch < ../auth_ldap-1.6.0-stig_venaas_plus_security.patch
  # the patch should apply. If not, you have a problem!
  ./configure
  make
  cp auth_ldap.so /usr/lib/apache/1.3/
  # if your modules are not in that dir, change it!
  apache-sslctl restart
  # or restart apache some other way.
  
  If you have any questions, try to send me an e-mail.

Ebox 1.4 and HP Color LaserJet 2600N

• Follow instructions here: ubuntuforums.org, except the last step.
  
  
  $ wget -O foo2zjs.tar.gz http://foo2zjs.rkkda.com/foo2zjs.tar.gz
  $ tar zxf foo2zjs.tar.gz
  $ cd foo2zjs
  $ make
  $ ./getweb 2600n # Get HP LaserJet 2600n .ICM files
  $ sudo make install
  $ sudo make cups
  
  
  Now go to Ebox -> Printer Sharing -> Add Printer
  And go find the HP -> Color Laserjet 2600N. It will now have a driver (foo2hp). The next page you can select stuff:
  
  "Color Mode" = Color
  "Bits Per Plane" = 2
  "ICM Color Profile" = (something like hpclj2600n-0.icm)
  

Firefox on LTSP as Local Apps (Thin Client, Ubuntu)

• 
  Firefox as Local App on Ubuntu Jaunty 9.04
  
  LTSP: The possibility of running Local Apps on the Thin Client is part of Ubuntu since Jaunty (9.04). The most obvious choice is to run Firefox (inlcuding Adobe Flash) locally. As you might have experienced video (f.e. on YouTube or Vimeo) can be very slow on the thin client because the content gets decoded on the server and video is sent uncompressed over the network to the thin client. Kind of defeats the whole purpose of Flash. (Rant: Flash should be open sourced, it's a PITA on Ubuntu 64bit!)
  
  On the Edubuntu website, it's advertised that it's very easy to install firefox as a local app. Well. It's kind of easy. See www.edubuntu.com/Download. In fact, my lts.conf looks like this:
  
  
  $ cat /var/lib/tftpboot/ltsp/i386/lts.conf
  # Global defaults for all clients
  # if you refer to the local server, just use the
  # "server" keyword as value
  # see lts_parameters.txt for valid values
  ################
  [default]
  X_COLOR_DEPTH=16
  LOCALDEV=True
  SOUND=True
  NBD_SWAP=True
  SYSLOG_HOST=server
  #XKBLAYOUT=de
  LDM_DEBUG=no
  LDM_DIRECTX=True
  LOCAL_APPS_MENU=True
  DNS_SERVER=10.0.0.1
  #SCREEN_02 = shell
  SCREEN_07 = ldm
  
  
  By the way, I tried 'locate lts_parameters.txt' but found nothing.
  alkisg on #ltsp says:
  zcat /usr/share/doc/ltsp-server/lts-parameters.txt.gz | less
  
  So it's with a dash not and underscore. Someone should file a bug. Why not you!?
  
  What I had to do to get firefox and flash installed:
  
  
  sudo -s
  chroot /opt/ltsp/i386
  apt-get install firefox flashplugin-installer
  exit
  ltsp-update-image
  exit
  
  
  Firefox but no internet...
  Firefox worked right away as local app. Not very fast (my thin client is not a powerhorse, that's what thin clients supposed to be: lean and mean, cheap, low RAM, etc. Be advised that Firefox and Flash need RAM and CPU and everything. No Pentium I with 64 MB that normally works fine as a thin client!
  
  Okay, now how about some browsing? Sorry, you need to do a lot of things to make that possible. After some searching and with help of the kind people in #ltsp, I found this: wiki.ubuntu.com/ThinClientHowtoNAT
  
  Dazzling uh?
  
  My network has a firewall/squid proxy. The proxy is on 10.0.0.1:3128. My LTSP server is on 10.0.0.2 on the LAN side and on the Thin Client side it's 192.168.0.1. The thin clients are in the range 192.168.0.200 - 250, it's a seperate LAN (standard setup by the way).
  
  Now can't I skip the whole ipforward and NAT? The NAT stuff is not that complicated but it opens a whole range of possibilities to get from the Thin Client LAN to the other LAN.
  
  Maybe redir (a TCP redirector) will help? It's helped me many times, when migrating servers for example. Say your old POP3 server is on 1.2.3.4 and the new on on 1.2.3.5. After you changed your DNS there will be a period of time (up to 4 days with our local braindead provider) before all the DNS changes have propagated. Simply install redir on the old server and redirect all TCP traffic for port 110 to the new server. No one will notice any service outage, great!!!
  
  So here's what I did:
  
  
  sudo apt-get install redir
  sudo redir --laddr=192.168.0.1 --lport=3128 --cport=3128 --caddr=10.0.0.1 --bind_addres=10.0.0.2
  
  
  Here is an explanation of the options to redir:
  
  --laddr: the local address of the LTSP server on the Thin Client side
  --lport: arbitrary, but 3128 is the standard.
  --cport: it's the port my squid proxy runs on by default
  --caddr: the address of the firewall/proxy on the LAN
  --bind_addr: the address of the LTSP server on the LAN side.
  
  Be sure to make sure to ensure that redir is not quitting on you, it does that often, build some stuff around it that it will always restart.
  
  The funny thing is that,after you told firefox to use 192.168.0.1:3128 as a http proxy, it also doesn't moan about not being able to resolve DNS. (See https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/348305 and https://help.ubuntu.com/community/UbuntuLTSP/LocalAppsResolvConf)
  
  Of course it only works for http on port 80, but there are probably ways to make it work for https and other ports too. Is https really proxy-able? Hmm. Anyway, for simple requirements this is sufficient, and maybe Ubuntu 9.10 will have the NAT stuff all automated, that would be nice then this post will be absolutely obsolete. That'd be nice :-)
  
  Oh, flash does give me sound but no image, but I guess that's some other problem.
  
  See also https://wiki.ubuntu.com/ThinClientProxyRedirect