In my company on the department host I lost authentication connectivity to the
Windows domain controller sometime during the year change for Apache web authentication
purposes. I was using the mod_auth_samba
to allow authentication against the domain controller. This was working ok more or less. If the
configured domain controller was unavailable, the module would core dump however. And also
the group management for this module was somehow fragile. And after I came back after the
Christmas and New Years holidays, I couldn’t get authentication to work again. Maybe some NTLMv1 vs. NTLMv2 issue.
Anyway, on my Linux PC, I tried to prototype a scheme, which I then would install on the
production system. And because the production system still runs an older SuSE Linux 8.1, I needed to stay with Apache 1.3. If I’ve wanted to move to Apache 2.0 I would have needed to update to a recent SuSE version. At this time I did have time for such an undertaking.
This also caused some problems along the way. I started with to protect a location with Basic Authentication backed by a Berkeley Database (mod_auth_db.so). I couldn’t this simple setup to work. After a long search I found, that it was a problem with differing DB version. My Gentoo PC has DB 3.x, 4.0 and 4.1 installed. Apache 1.3 is explicitly build with DB 4.0. To setup the password and group files I used dbmmanage, which is a Perl program and part of an Apache 1.3 installation.
However the Perl DB_File module, which dbmmanage utilizes is of course linked against the latest and greatest, which is 4.1. And Apache 1.3 linked with DB 4.0 can’t use 4.1 database file. So I removed DB 4.1 and reinstalled the Perl DB_File module now linked with DB 4.0. After recreating the password and group files my basic setup worked as expected.
Next I tried mod_auth_ldap
to authenticate against the Windows Active Directory, but unfortunately it doesn’t work (or I couldn’t get it to work). Sometime ago I tried Apache 2.0 with the integrated mod_auth_ldap module and this worked immediately. But not Apache 1.3.
On to mod_auth_pam in connection with pam_ldap. This setup worked. After making the required changes for pam_ldap in /etc/ldap.conf or /etc/openldap/ldap.conf depending on your Linux distribution and changing the file /etc/pam.d/httpd to use the pam_ldap.so shared library, I could successfully authenticate against the Active Directory. I could also integrate with the AuthDBGroupFile directive, so that authenticated users could be authorized depending on the membership of a particular group. As a side note, which wasn’t immediately obvious to me from reading the documentation and I learned only by consulting the mod_auth_ldap source code, that mod_auth_pam reads the /etc/group file. This means, that a possible authentication scheme might be done through the system files. But that also means, that any user to be authenticated must be existing in the /etc/passwd file.
So I moved this setup to the production system. From first glance it really appeared to work, but the Apache error log showed frequent segmentation faults. I couldn’t really isolate the problem, but it definitely it had something to do with authentication through mod_auth_ldap. So, again a no go.
In the end I settled for the Perl AuthenLDAP module (since the production system also has mod_perl installed). This worked flawlessly direct from the beginning. Integration with AuthDBGroupFile was also working fine. So this is it.
The setup has still problems though since the passwords go unencrypted over the wire. In future another change might be necessary possibly with the integration of SSL and Samba 3.0.