LinuxQuestions.org - Missing Linux-PAM as a showstopper for LDAP server

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Missing Linux-PAM as a showstopper for LDAP server (https://www.linuxquestions.org/questions/slackware-14/missing-linux-pam-as-a-showstopper-for-ldap-server-4175492713/)

Quote:

Originally Posted by Richard Cranium (Post 5106155)

Please explain. I believe this is incorrect, but perhaps I am misunderstanding what you meant by the above.

The NIS/YP master server distributes account files (unencrypted across the network, unless you use NIS+ which is Solaris-only) to all servers in the NIS domain. You're right in that it does not simply copy files (well, it can do that too); it syncs partial entries against the master server, so you can still have local (system) accounts on each server.

My knowledge of NIS is limited, as I've found little use for it. Most of what I've learned about the inner workings of NIS, I got from the FreeBSD handbook.

Quote:

Originally Posted by Ser Olmy (Post 5106170)

I've actually used it in a corporate environment. The files on any NIS client servers are untouched; requests for user/password/account information requires a remote call to the NIS master or one of the slave servers.

I don't see why nss_ldap would be unable to provide the same service that either nss_nis or nss_nisplus do.

Quote:

Originally Posted by Richard Cranium (Post 5106191)

Really? The FreeBSD manual clearly refers to files being synchronized, including the /etc/hosts file if one so desires. Very strange.

This really piqued my curiousity, so I went to the Linux Documentation Project site and found this page. In section 7.6 they recommend putting the password in /etc/passwd for NIS users. Does that not imply that NIS uses and alters this file?

I'm not saying you're mistaken, but could there be different implementaions of NIS? Because it really, really looks like the ypclient daemon relies on /etc/passwd.

(I'm now in the process of installing two virtual servers to find out exactly how NIS works. I obviously should have done so years ago, thanks for the push! :))

Quote:

Originally Posted by Richard Cranium (Post 5106191)

I don't see why nss_ldap would be unable to provide the same service that either nss_nis or nss_nisplus do.

The nss files do not perform authentication, only lookup/resolve functions.

Quote:

Originally Posted by Ser Olmy (Post 5106197)

(I'm now in the process of installing two virtual servers to find out exactly how NIS works. I obviously should have done so years ago, thanks for the push! :))

Some time ago, I wrote a little HOWTO on NIS+NFS for the Slackware Documentation Project. This should help you to get started.

http://docs.slackware.com/howtos:net...aming_profiles

There certainly are different versions of NIS / NIS+ / YP. There's three for a start.

They don't modify the actual files, they store a cache, but fundamentally the passwords (when used for authentication) are available as hashes on the client in question, often ripe for hash dictionary attacks etc. Unlike LDAP which uses the password to access a remote service (binding to the LDAP server), and access to that service proves the password was correct.

Quote:

Originally Posted by Richard Cranium (Post 5106191)

I've now successfully configured NIS in a small test environment, and just as you said, /etc/password et al are not modified on any servers. Instead, separate NIS database files are replicated (one for every file which service is to be incorporated in NIS) between NIS masters and NIS slaves. NIS clients perform lookups via the nss library file, and authenticate using RPC.

It was that last part that really had me confused; how could the programs in the shadow suite possibly be using an alternate authentication mechanism, when no such support was compiled into the executables? After all, PAM authentication only works after you've recompiled the applications in question to include PAM support.

The answer is as simple as it is obvious (in retrospect, anyway): The NIS hooks exist in glibc itself.

Quote:

Originally Posted by kikinovak (Post 5106241)

Some time ago, I wrote a little HOWTO on NIS+NFS for the Slackware Documentation Project. This should help you to get started.

http://docs.slackware.com/howtos:net...aming_profiles

Nice!

The only issues I ran into while following those instructions, were:

The ypinit executable resides in /usr/lib64/yp on a Slackware64 system (fairly obvious)
/usr/lib64/yp/ypinit -m on Slackware64 fails, as ypinit expects to find certain files in /usr/lib/yp, while the directory is of course actually called /usr/lib64/yp. I created a symlink as a workaround.
It was not immediately obvious (to me, at least) which server names ypinit was asking me to enter (NIS slaves and/or NIS clients), but a quick Google search revealed that it was asking for the names of slave servers.
Running yppasswd on the NIS clients results in a "crypt() called failed" error. Still looking into this.

I could negotiate a delay of about a month until I have to decide what system I am going to use for this migration. I'd *really* *really* like to use Slackware for that. I'm feeling somewhere between mildly adventurous and slightly panicked at the prospect of configuring your average Slackware desktop for use in a corporate environment with LDAP authentication. At least, I'd like to give it a serious try.

Maybe some folks are interested in having such a solution? So why not join our efforts?

I'm using this detailed and excellent blog article as a starting point. I guess it's currently the best available documentation on the subject:

http://karellen.blogspot.fr/2011/11/...are-linux.html

User management should be possible for the clients (meaning: a school director should be able to add or delete users with some graphical application). I thought about integrating this tool: https://www.ldap-account-manager.org/lamcms/ If you know something better and/or more appropriate, let me know here.

I'm writing SlackBuilds for all the stuff that has to be rebuilt. They're currently available in my Git repo:

# git clone https://github.com/kikinovak/slackware

Take a peek in the testing/ directory.

I'm also taking (laconic) notes in the Linux-HOWTOs/LDAP-HOWTO.txt file. I plan to elaborate this in the future, but for the moment, this is one big terra incognita, and I'm out there fighting the darkness with a bush knife.

I'll keep you posted.

I can't offer any insights on OpenLDAP, but I can say that in my experience, adding PAM to Slackware is a painless experience.

Mind you, I mostly use a small subset of the packages in Slackware, and there may very well be other packages (Apache?) besides shadow, OpenSSH and Samba that would need rebuilding in order to work properly with PAM.

(I may have to look into OpenLDAP soon, though, as work is underway to support the use of OpenLDAP as a backend for Samba 4.)

I wonder if this is the solution to my problem. Unfortunately the available documentation is sparse:

http://arthurdejong.org/nss-pam-ldapd/

What's the Unix admin guru's opinion on this?

Quote:

Originally Posted by kikinovak (Post 5106780)

I'd suggest have another test setup (a more PAM-friendly distro, for example) running in parallel so you have some alternative in case Slackware doesn't do what you need.

I looked into this some years back and this site seemed to have a fair amount of useful documentation. How much use it is now, though, I'm not sure:

http://www.bayour.com/LDAPv3-HOWTO.html

For fun I decided to get my vbox 14.1 x64 install authenticating against ADS via pam_winbind yesterday, finished up today.
Its not too terrible, and once, you've built the packages and baseline confs out you could rig them into your installer. You would have to rebuild a few packages occasionally when they got updates though. I suppose if you were pulling updates from a local mirror you could just rebuild them and replace the packages in the mirror before updating clients or some such.

Anyways heres the rough stream of consciousness notes on what was involved, this was on a vbox install so I just took a snapshot before hand, backup before you do anything that could lock you out of your machine, this isn't a thorough guide and I haven't tested it extensively so you take your fate into your own hands if you want to do it,etc etc , just what worked for me in case it helps anyone out getting through some of the little things that crop up:

Code:



Step 1:  Download and build LinuxPAM.  This part was fairly straightforward to me,  I downloaded the source to a new directory and basically did:



BuildDir=$(pwd)



cd /etc && mkdir pam.d  && cd pam.d

echo "#%PAM-1.1" > ./other

echo "auth    required  pam_deny.so" >> ./other

echo "account  required  pam_deny.so" >> ./other

echo "password required  pam_deny.so" >> ./other

echo "session  required  pam_deny.so" >> ./other





cd $BuildDir/Linux-PAM-1.1.8/



#Todo:  Check if cracklib is installed and disable if not

./configure --disable-selinux 

make

make check

make install





Better way to do this:  Make a proper slackbuild, check for things like cracklib,  build packages so you can redistribute easily.  





Step 2:



Rebuild shadow,  I just took the shadow directory from Slack 14.1 x64,  added the --with-libpam option to the slack build,  and ran the slack build.  Then reinstall the resulting package.  If you rebuild after installing libpam,  it might detect pam as part of the configure process without explicitly specifying, I saw something to this effect when reading a bunch of stuff while doing this, but its easy enough to add the option anyways.





Step 3:  At this point I had to readjust some permissions making /sbin/unix_chkpwd root.shadow and setgid again,  making sure /usr/bin/su was root.root and setuid.

Note:  Local login was failing because of these issues,  Could still ssh in.  As you go along make sure you can log in local before messing with ssh and vice versa



Step 4:  Make sure the basic /etc/pam.d/ conf files are in place,  and changes to login.defs.  For this part I relied on  the instructions here:  http://www.linuxfromscratch.org/blfs/view/svn/postlfs/shadow.html  under the "Configuring Linux-PAM to Work with Shadow"  header.





At this point, as far as functionality you want to be sort of back where you started, local login works with local users, but its using PAM in the process.



Step 5:  Rebuild sshd.  Downloaded the 14.1 openssh contents again, change --without-pam to --with-pam, run the slackbuild, install the package.



Step 6:  Rebuild Samba,  download the 14.1 samba goodies,  remove the --without-pam option and run the slackbuild.  Here I ran into a build issue,

          Samba wanted to use /usr/include/com_err.h  instead of using the files in source4/heimdal/lib/com_err/  which caused a compile time error, so you might have to 

          work around that,  my hacky solution while still trying to figure out the problem, was just swapping the files during the build then swapping them back.



Step  7:  Install new samba package.  I think I might have had to 'ln -s /usr/lib64/security/pam_winbind.so /lib64/security/pam_winbind.so' as well but Im not sure it matters,                            

          I still get a warning on that file not existing in /var/log/secure but the file exists,  module is there and working :shrug:



Step 8:  Modify rc.samba  to start and stop windbind -D along with the other samba components.





Step 9:    Set up your samba smb.conf with ads security, put in domain info,  set template shell = /bin/bash, I can post conf later if wanted.  Start samba and net ads join -U username  # join to the ads domain



Step 10:  Configure local logins to use winbind,  edit the pam.d/system-session  system-account, system-auth, system-password files to require pam_winbind.so after the 'auth sufficient pam_unix.so'  lines  [I will post the conf files I ended up with for all this stuff later if anyone wants,  just remind me about it]  Edit nsswitch conf to look at 'files winbind'  for users, groups, hosts.  Make sure you can su - to other users and login from fresh terminals



Step 11:  Once local logins are working,  for ssh you create an /etc/pam.d/sshd  which in my case looks like this (and since its mostly the same I could have probably just included the various system-* files instead of pasting them into this file :\  ) :



auth            sufficient      pam_unix.so            

auth            required        pam_winbind.so  try_first_pass use_authtok



account        sufficient      pam_unix.so

account        required        pam_windbind.so try_first_pass use_authtok





session  required    pam_mkhomedir.so  skel=/etc/skel umask=0022

session  sufficient  pam_unix.so

session  sufficient  pam_winbind.so  use_first_pass use_authtok

session  required    pam_limits.so

session  required    pam_env.so





and set UsePam  to yes  in your sshd config,  restart sshd.

And then local and ssh logins with ads credentials are working, and theoretically samba shares that you want to allow access to from specific AD users should work as well.
You can restrict via ad/ldap group with options in the various pam files I believe.

This was the first time I've done this and a lot of steps could be combined and automated to simplify the process. And as Ser Olmy said , if there are other services that need to authenticate against PAM then you might have more rebuilding in there. Not too bad to get basic authentication and samba services up though, and good way to learn how some of these pieces fit together :)

Edit: Oh yeah, you'll probably want to rebuild sudo with pam enabled as well

Have you considered Samba and nss winbindd? I know not exactly the most UNIXy thing to do but a rebuild of the samba, and openldap after installing the MIT kerberos package worked great on 14.0 joining an active directory domain as a member server; with pretty complete AAA integration with the domain.

The MIT kerberos package also contains a kerberized login program which you can use instead of /bin/login; works great on the console though I don't know what you would do for X11 based logins.

winbindd takes care of all your group memberships. I can vouch for this setup working well on Slackware 14.0 with the versions of Samba, and openldap that shipped with that release. I have a number of Slackware member servers doing various things in our corporate AD environment. I don't see why it would not work with a Samba server acting as the domain controller.

The problems really are X11 greeters and having and as others have pointed out MIT Kerberos package does not seem to be the direction the Linux world is moving it.

I'd be very interested if you've finally succeeded to set LDAP-based authentication without PAM.
About 4-5 yerars ago my collegue played with openldap services incl. authentication with Slackware in a heterogenous Win/Lin network. If I remember correctly NSS module from PADL sw. company was used. I've sent an email with that question and link to this forum. Hope he'll share his experience and knowledge.

Quote:

Originally Posted by kikinovak (Post 5106808)

I wonder if this is the solution to my problem. Unfortunately the available documentation is sparse:

http://arthurdejong.org/nss-pam-ldapd/

What's the Unix admin guru's opinion on this?

It works. Which is cool. I did find a thread which helped me to get it all setup correctly: http://lists.arthurdejong.org/nss-pa.../msg00217.html
The other posts on that thread are also informative.

But there are two issues:

Home directories will not be created automatically when a user logs in to the Slackware box using an LDAP account.
You are limited to the "{CRYPT}" password hash for the "userPassword" field in your LDAP database. If the LDAP database, that you are connecting to, uses a different password hash for the "userPassword" fields, it may not work.

All of the above is without installing pam.

AFAICT the two issues above can easily be resolved by installing pam - the pam_mkhomedir module will automatically create a home directory if it doesn't exist.

On a small network with only a few users and a few computers the above two issues are not really an issue, I would say. On a bigger network, I would install pam.