Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
|
01-27-2014, 11:37 AM
|
#16
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep:
|
Quote:
Originally Posted by Richard Cranium
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.
|
|
|
01-27-2014, 12:03 PM
|
#17
|
Senior Member
Registered: Apr 2009
Location: McKinney, Texas
Distribution: Slackware64 15.0
Posts: 3,860
|
Quote:
Originally Posted by Ser Olmy
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.
|
|
|
01-27-2014, 12:18 PM
|
#18
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep:
|
Quote:
Originally Posted by Richard Cranium
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
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 12:23 PM.
|
|
|
01-27-2014, 01:36 PM
|
#19
|
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453
Original Poster
|
Quote:
Originally Posted by Ser Olmy
(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
|
|
|
01-27-2014, 04:44 PM
|
#20
|
Moderator
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,417
|
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.
|
|
|
01-27-2014, 11:01 PM
|
#21
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep:
|
Quote:
Originally Posted by Richard Cranium
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 01:22 AM.
|
|
|
01-27-2014, 11:16 PM
|
#22
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep:
|
Quote:
Originally Posted by kikinovak
|
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 01:36 AM.
|
|
|
01-28-2014, 09:39 AM
|
#23
|
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453
Original Poster
|
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.
|
01-28-2014, 10:02 AM
|
#24
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep:
|
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 10:05 AM.
|
|
|
01-28-2014, 10:31 AM
|
#25
|
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453
Original Poster
|
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.
|
01-28-2014, 12:11 PM
|
#26
|
Member
Registered: Dec 2007
Posts: 164
Rep:
|
Quote:
Originally Posted by kikinovak
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
|
|
|
01-31-2014, 03:59 PM
|
#27
|
Member
Registered: Aug 2004
Location: MD
Distribution: Slackware
Posts: 114
Rep:
|
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 05:33 PM.
|
|
1 members found this post helpful.
|
01-31-2014, 06:57 PM
|
#28
|
Member
Registered: Sep 2012
Posts: 449
Rep:
|
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.
|
|
|
02-02-2014, 07:45 PM
|
#29
|
Member
Registered: Jul 2004
Distribution: Void Linux, former Slackware
Posts: 498
Rep:
|
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.
|
|
|
02-04-2014, 07:27 AM
|
#30
|
Member
Registered: Aug 2010
Posts: 353
Rep:
|
Quote:
Originally Posted by kikinovak
|
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.
Last edited by MadMaverick9; 02-04-2014 at 07:34 AM.
|
|
|
All times are GMT -5. The time now is 07:22 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|