[hylafax-users] HylaFax & LDAP authentication [WAS: HylaFax+ 5.2.2 fails on building w/ PAM support]

["Joshua Kinard" <jkinard@xxxxxxxxxxx>]

Okay, so I've played around with HylaFax's PAM support a bit, but I think my particular setup, since it's a Novell OES2 box, is that PAM tries checking things against my backend eDirectory system and failing in some fashion (at least with regards to HylaFax).  Since I don't really care to mess with PAM too much, I wanted to take a crack at that LDAP auth patch I saw posted in the archives in this message:

http://www.hylafax.org/archive/2004-08/msg00066.php


I quickly discovered it was using older LDAP functions that have since been deprecated in openldap-2.4, so I did my best to port the code to the newer binding commands, and got it to compile & run.  Then I ran into a functionality issue...

It seems when testing against HylaFax's login system (telneting to localhost on 4559), when we pass a username via USER, HylaFax goes on ahead and checks for that user name (via checkUser) in whatever database it's using, be it files, PAM, ldap, etc.  Then it'll query for the password.  In this LDAP patch, that means the code binds to the LDAP server using admin credentials supplied in the config file, and looks up the user by the name provided to the USER command.  Then it'll query for the password.

The problem with this approach that I discovered, is eDirectory doesn't make the user's password available to the LDAP-side of things normally.  It's possible by using NMAS Simple Passwords, but by default, people either use NDS Passwords or the newer Universal Password, all of which is hidden deep in the eDir system.  So the LDAP code in that patch tries looking for the LDAP attribute 'userPassword' and fails.

My idea to work around this is based off of when I was toying with MediaWiki and the LDAP plugin available for it.  Rather than bind to the LDAP server first as an admin, and then look up the user, I'm thinking it would be better to collect both the user AND the password first, then try to bind to the LDAP server as the user.  If that fails, we assume the username or password is invalid, and fails out.  If we succeed, then we can maybe do additional things, like grab the group memberships and test for a specific group to make sure the user is authorized for faxing functionality.

So I'm not real familiar with he guts of HylaFax, but how intrusive might it be to go having HylaFax prompt for user, then password, THEN run its checkUser function to do all the fancy LDAP stuff?  The benefit of this is not needing to expose in plaintext a potentially deadly admin password in any config file, and providing another mechanism to authenticate users with (handy for those environments with a master backend user database like AD or eDir).

I've attached what I have so far, but this is definitely a patch that could use more work if anyone else wants to take a stab at it.  The #define HAVE_LDAP stuff needs to be implemented into configure somehow so that it winds up auto-generated into config.h (and I am staying far away from configure, autoconf/tools is scary).  The string/chars holding data from the char file also don't have buffer overrun checks, according to the code comments.  Anyone familiar with that stuff may also want to take a look.

Thoughts?

Attachment: hylafax-5.2.2-ldap.patch
Description: hylafax-5.2.2-ldap.patch