[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: schema for NSS LDAP with not all accounts active



On Friday 30 March 2001 08:55, Russell Coker wrote:
> > That's not clean. And what you do with FTP and IMAP/POP? You don't need
> > to have a shell for both, but you want to allow only one of those. Of
> > course, yeah, I could have access lists for each of that service not
> > stored in the LDAP tree, but looking up always elsewhere is quite a
> > hassle.
> > Or am I the only one who wants such a feature? That would amaze me...
> >
> > If there is the possibility to store and lookup some sort of
> > "per-service" accesslist in the LDAP tree I would prefer that solution
> > compared to the "hey, let's check what shell the user has" one.
>
> Good point.  The problem is that the NSS interface doesn't allow for such
> things so you would have to use pam_ldap for all authentication (no big
> deal just a minor PITA to change all the /etc/pam.d files and keep them
> maintained).  Then what we need is an option for pam-ldap to specify which
> filter should be used.

OK, I think I've got a workable solution to this.  The pam_ldap.so module has 
a "config=file" option to specify which config file to use.
First thing to do is to stop nss being used for password authentication, this 
is easy, configure nss to use an LDAP account that has no read or auth access 
to the userPassword attribute.
Then configure the /etc/pam.d/* files to use pam_ldap.so for everything.  For 
any that you want different filters for you simply use 
config=/etc/pam-ldap-filter.conf .

The down-side to this is that you need a separate config file for each 
service that is to be independantly controlled.  However it shouldn't be to 
difficult to create these with M4 macros.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page



Reply to: