Re: options for centralized 'passwd' database for a diskless lab ?

From: Stefan Bethke <stb_at_lassitu.de>
Date: Thu, 16 Feb 2006 20:06:13 +0100
Am 14.02.2006 um 18:11 schrieb Luigi Rizzo:

> as per the subjects, what options do i have to set a centralized
> 'passwd' database for a lab with FreeBSD diskless machines ?
>
> In the past (4.x times) i used YP/NIS which did the job but was
> highly insecure (all traffic unencrypted) and also a bit of a pain  
> to configure.
> It was convenient though because it let users change their
> password and other info just using the passwd command.
>
> I have been browsing around a bit, and i see that pam_* (tried  
> pam_radius)
> can do for the authentication part but not for the other info;
> nss_* seems to be a better suit but the only thing i see is nss_ldap
> and i am not familiar with the latter.
>
> So any suggestions or pointers to pages describing what to do ?

We're running a LDAP-based setup at my employer, using pam_ldap and  
nss_ldap.  Getting the clients configured is a piece of cake, getting  
your head wrapped around how to populate your LDAP repository isn't.   
The Samba integration was the most painful to get going, and creating  
machine accounts is still close to black magic for me.

That said, once you have it going, it's really nice.  We have our lab  
with diverse OSes hooked up to the LDAP server as well, and control  
access to the various machines through group membership.  Also, quite  
a number of web-based stuff is tied in.

For management, we're using phpldapadmin, which makes most day-to-day  
tasks quite simple.

One drawback though: without a caching layer in the NSS, every ls(1)  
will hit the LDAP server, and if you've configured nss_ldap to use  
TLS, it's dead slow.  We decided we can live with an unencrypted  
connection for NSS, but use TSL for PAM.


Stefan

-- 
Stefan Bethke <stb_at_lassitu.de>   Fon +49 170 346 0140
Received on Thu Feb 16 2006 - 18:07:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:52 UTC