Missing Linux-PAM as a showstopper for LDAP server
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Missing Linux-PAM as a showstopper for LDAP server
I've been spending a few days and a few long nights experimenting with setting up an LDAP server for central authentication.
I have a new client (medium-size town hall here in South France) who's considering migrating 35 desktop clients from Windows to Linux. Their server is already running Zentyal, with all user accounts on LDAP. Which means I have to configure LDAP authentication for Slackware clients.
The non-inclusion of Linux-PAM in Slackware makes this task nearly impossible. I'm facing the choice of rebuilding a bunch of base packages... or just quitting. This is a real showstopper, and the only choice I have is use another distribution. Which sucks.
I know that page, but as far as I can tell, the stuff is only available for -current. There's no information about the Slackware version, e. g. 13.37, 14.0, 14.1. Of course I could try and figure this all out by myself, but in that case, this is clearly the distributor's job.
I know that page, but as far as I can tell, the stuff is only available for -current. There's no information about the Slackware version, e. g. 13.37, 14.0, 14.1.
The last update there was in August 2012, so it has never been tried on Slackware 14.1.
Of course I could try and figure this all out by myself, but in that case, this is clearly the distributor's job.
Vincent's files are a voluntary effort, he was not paid or asked to produce this. This collection of sources, diffs and packages must be seen "as is" because it is not going to be part of the Slackware distribution any time soon. I estimate that it should be feasible to update the sources to match Slackware 14.1 but this is of course a different kind of enhancement than adding a MLED layer on top of Slackware - you are effectively changing the way your Slackware computers deal with user authentication. If you apply this to a stable Slackware release, the maintenance effort of adding PAM should be minimal but not zero (for instance you would have to recompile an openssl package if Slackare released a vulnerability fix in /patches).
- being it updated on 29 sep 2012, it's updated at Slackware 14.0 (released on 26 sep 2012);
- AFAIK, as long as it doesn't get officially in Slackware it's testing stuff (as written on the page), so use it at your own risk.
I suggested that because I thought you will be able to support it yourself (you can also see what's changed and rebuild 14.1 packages), but if I have misunderstood and you're looking for an official PAM supported distribution with all the bells and whistles maybe you're better off with something else.
EDIT: Eric beated me (and actually answered better)!
You don't need such a thing for NIS, so I'd be surprised that you would for ldap.
NIS distributes Unix user and group database files (/etc/passwd, /etc/group, /etc/shadow, /etc/gshadow) across all systems. OpenLDAP is a centralized system and doesn't touch any of these files. To locate a user or group object or authenticate a user, one must query the LDAP service.
Not only do you have to alter the way every program in the "shadow" suite works, you also have to provide new NSS libraries. PAM does all that and more.
As far as I can tell, this is just false information.
It seems he got as far as the NSS libraries, but no further. I don't see how one could ever progress beyond that without PAM.
I have some PAM scripts for Slackware if you're interested. I have one for PAM itself + cracklib, one for the shadow suite, one for OpenSSH and one for Samba. They all attempt to check for the latest versions (for the Slackware packages that means checking for a later version in patches/source) before downloading, compiling and installing.
I haven't gotten as far as creating proper .txz packages for Linux-PAM and cracklib, so the scripts simply compile and install those directly from source.
Huh? Are you suggesting somehow using OpenLDAP as a backend for Kerberos? It that even possible? I don't think so.
Also, that document has several issues:
It does not patch or alter the shadow suite, only OpenSSH. None of the shadow applications (login et al) will know anything about Kerberos.
User account integration is non-existent. I quote: "Note: the principal must be associated with an account on the system, either in the local passwd database or via a network system such as NIS or LDAP." In other words, a nonsensical solution that requires all accounts to be created in two separate user databases manually.
The document suggests installing MIT Kerberos, which is probably a bad idea, as that is likely to break Samba 4. Heimdal is not only more or less the de facto standard on Linux, it also contains significantly better functionality.