LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 01-27-2014, 10:37 AM   #16
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,334

Rep: Reputation: Disabled

Quote:
Originally Posted by Richard Cranium View Post
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.
 
Old 01-27-2014, 11:03 AM   #17
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,858

Rep: Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225Reputation: 2225
Quote:
Originally Posted by Ser Olmy View Post
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.
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.
 
Old 01-27-2014, 11:18 AM   #18
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,334

Rep: Reputation: Disabled
Quote:
Originally Posted by Richard Cranium View Post
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.
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 View Post
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.

Last edited by Ser Olmy; 01-27-2014 at 11:23 AM.
 
Old 01-27-2014, 12:36 PM   #19
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453

Original Poster
Rep: Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154
Quote:
Originally Posted by Ser Olmy View Post
(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
 
Old 01-27-2014, 03:44 PM   #20
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417

Rep: Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985Reputation: 1985
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.
 
Old 01-27-2014, 10:01 PM   #21
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,334

Rep: Reputation: Disabled
Quote:
Originally Posted by Richard Cranium View Post
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'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.

Last edited by Ser Olmy; 01-28-2014 at 12:22 AM.
 
Old 01-27-2014, 10:16 PM   #22
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,334

Rep: Reputation: Disabled
Quote:
Originally Posted by kikinovak View Post
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.

Last edited by Ser Olmy; 01-28-2014 at 12:36 AM.
 
Old 01-28-2014, 08:39 AM   #23
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453

Original Poster
Rep: Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154
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.
 
3 members found this post helpful.
Old 01-28-2014, 09:02 AM   #24
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 3,334

Rep: Reputation: Disabled
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.)

Last edited by Ser Olmy; 01-28-2014 at 09:05 AM.
 
Old 01-28-2014, 09:31 AM   #25
kikinovak
MLED Founder
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453

Original Poster
Rep: Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154Reputation: 2154
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?
 
1 members found this post helpful.
Old 01-28-2014, 11:11 AM   #26
commandlinegamer
Member
 
Registered: Dec 2007
Posts: 163

Rep: Reputation: 51
Quote:
Originally Posted by kikinovak View Post
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.
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
 
Old 01-31-2014, 02:59 PM   #27
NeoMetal
Member
 
Registered: Aug 2004
Location: MD
Distribution: Slackware
Posts: 114

Rep: Reputation: 24
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

Last edited by NeoMetal; 02-03-2014 at 04:33 PM.
 
1 members found this post helpful.
Old 01-31-2014, 05:57 PM   #28
chemfire
Member
 
Registered: Sep 2012
Posts: 422

Rep: Reputation: Disabled
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.
 
Old 02-02-2014, 06:45 PM   #29
dunric
Member
 
Registered: Jul 2004
Distribution: Void Linux, former Slackware
Posts: 498

Rep: Reputation: 100Reputation: 100
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.
 
Old 02-04-2014, 06:27 AM   #30
MadMaverick9
Member
 
Registered: Aug 2010
Posts: 353
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by kikinovak View Post
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:
  1. Home directories will not be created automatically when a user logs in to the Slackware box using an LDAP account.
  2. 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.

Last edited by MadMaverick9; 02-04-2014 at 06:34 AM.
 
  


Reply

Tags
ldap, pam



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
pam-ldap and pam-mysql gangadhar402 Linux - Software 2 03-09-2013 04:50 AM
sudo: Can't contact LDAP server with SSL and PAM sebastienliu Linux - Server 1 01-15-2013 12:02 AM
Enable freenx-server with pam/ldap brianmcgee Linux - Software 1 09-03-2010 03:29 AM
Openssh + PAM + LDAP fails only with LDAP users asimula Linux - Newbie 2 04-01-2010 07:10 AM
School switching some boxes to linux, showstopper: samba idamlaj Linux - Networking 5 05-22-2005 06:55 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:17 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration