pam_ldap and password management and rsh/ssh without password

pam_ldap and password management and rsh/ssh without password

Post by Polly Squire » Sat, 18 Jun 2005 08:09:06



The System Administration Guide: Naming and Directory Services (DNS,
NIS, and LDAP) says that if you enable pam_ldap that rsh/ssh and
authentication that doesn't require a password will fail.  So it seems
my choices are to fall back to pam_unix_account which ignores the fact
that accounts may be expired (via ldap).  This doesn't make sense to
me.  (Why isn't there a pam_ldap_account ?)

I am not hiding expiry information from my proxy...why is this a
problem?

At any rate, I'm sure that there are people out there who are using
ldap for password management that have a working solution with
ldap/rsh/ssh and password aging.  What are people doing?

 
 
 

pam_ldap and password management and rsh/ssh without password

Post by Jason Kin » Sat, 18 Jun 2005 09:31:19



> The System Administration Guide: Naming and Directory Services (DNS,
> NIS, and LDAP) says that if you enable pam_ldap that rsh/ssh and
> authentication that doesn't require a password will fail.  So it seems
> my choices are to fall back to pam_unix_account which ignores the fact
> that accounts may be expired (via ldap).  This doesn't make sense to
> me.  (Why isn't there a pam_ldap_account ?)

> I am not hiding expiry information from my proxy...why is this a
> problem?

> At any rate, I'm sure that there are people out there who are using
> ldap for password management that have a working solution with
> ldap/rsh/ssh and password aging.  What are people doing?

Funny you should mention that, I just mentioned something about this on
the opensolaris-rfe list -- basically what's happening is that it's
using an LDAP control that's returned as part of an ldap bind operation
to obtain password expiration information, which means of course that
pam_ldap has to actually be able to bind to the ldap server as the user
(which it cannot do when using public key auth or rhosts since it never
actually gets the password), so it returns a failure.

You might be able to get away with manually maintaining the
shadowAccount attributes (though I haven't tried this).  The
disadvantage to this is that then the clients are managing the password
policy instead of letting the ldap server do it (i.e. each client would
have to check the shadowLastChange, etc. attributes and enforce action
appropriately).  If you're doing only UNIX authentication, this might
work, if you also want to have other things authenticate against the
same ldap server to authenticate users, then you might start to run into
issues (as they would also have to know to check those attributes to
make sure an account isn't expired, or if they need to change their
password).

 
 
 

pam_ldap and password management and rsh/ssh without password

Post by Polly Squire » Wed, 29 Jun 2005 12:41:15




> > The System Administration Guide: Naming and Directory Services (DNS,
> > NIS, and LDAP) says that if you enable pam_ldap that rsh/ssh and
> > authentication that doesn't require a password will fail.  So it seems
> > my choices are to fall back to pam_unix_account which ignores the fact
> > that accounts may be expired (via ldap).  This doesn't make sense to
> > me.  (Why isn't there a pam_ldap_account ?)

> > I am not hiding expiry information from my proxy...why is this a
> > problem?

> > At any rate, I'm sure that there are people out there who are using
> > ldap for password management that have a working solution with
> > ldap/rsh/ssh and password aging.  What are people doing?

> Funny you should mention that, I just mentioned something about this on
> the opensolaris-rfe list -- basically what's happening is that it's
> using an LDAP control that's returned as part of an ldap bind operation
> to obtain password expiration information, which means of course that
> pam_ldap has to actually be able to bind to the ldap server as the user
> (which it cannot do when using public key auth or rhosts since it never
> actually gets the password), so it returns a failure.

> You might be able to get away with manually maintaining the
> shadowAccount attributes (though I haven't tried this).  The
> disadvantage to this is that then the clients are managing the password
> policy instead of letting the ldap server do it (i.e. each client would
> have to check the shadowLastChange, etc. attributes and enforce action
> appropriately).  If you're doing only UNIX authentication, this might
> work, if you also want to have other things authenticate against the
> same ldap server to authenticate users, then you might start to run into
> issues (as they would also have to know to check those attributes to
> make sure an account isn't expired, or if they need to change their
> password).

I kind of figured it did a bind for account management , although I was
hoping that it only used the bind for authentication verification.

I can't believe there isn't anyone else with a working solution
already.  Especially with audits pushing for password aging and
increased security(while still having some automated processes to make
your business run).

I don't have a problem falling back to pam_unix but what's really the
most effective way of updating the shadow entries?  A custom passwd
command?

Does anyone know if PADL pam_ldap handles this more gracefully?

I'm really drawing for straws here.

--Polly

 
 
 

pam_ldap and password management and rsh/ssh without password

Post by Jason Kin » Wed, 29 Jun 2005 13:58:36





>>>The System Administration Guide: Naming and Directory Services (DNS,
>>>NIS, and LDAP) says that if you enable pam_ldap that rsh/ssh and
>>>authentication that doesn't require a password will fail.  So it seems
>>>my choices are to fall back to pam_unix_account which ignores the fact
>>>that accounts may be expired (via ldap).  This doesn't make sense to
>>>me.  (Why isn't there a pam_ldap_account ?)

>>>I am not hiding expiry information from my proxy...why is this a
>>>problem?

>>>At any rate, I'm sure that there are people out there who are using
>>>ldap for password management that have a working solution with
>>>ldap/rsh/ssh and password aging.  What are people doing?

>>Funny you should mention that, I just mentioned something about this on
>>the opensolaris-rfe list -- basically what's happening is that it's
>>using an LDAP control that's returned as part of an ldap bind operation
>>to obtain password expiration information, which means of course that
>>pam_ldap has to actually be able to bind to the ldap server as the user
>>(which it cannot do when using public key auth or rhosts since it never
>>actually gets the password), so it returns a failure.

>>You might be able to get away with manually maintaining the
>>shadowAccount attributes (though I haven't tried this).  The
>>disadvantage to this is that then the clients are managing the password
>>policy instead of letting the ldap server do it (i.e. each client would
>>have to check the shadowLastChange, etc. attributes and enforce action
>>appropriately).  If you're doing only UNIX authentication, this might
>>work, if you also want to have other things authenticate against the
>>same ldap server to authenticate users, then you might start to run into
>>issues (as they would also have to know to check those attributes to
>>make sure an account isn't expired, or if they need to change their
>>password).

> I kind of figured it did a bind for account management , although I was
> hoping that it only used the bind for authentication verification.

> I can't believe there isn't anyone else with a working solution
> already.  Especially with audits pushing for password aging and
> increased security(while still having some automated processes to make
> your business run).

> I don't have a problem falling back to pam_unix but what's really the
> most effective way of updating the shadow entries?  A custom passwd
> command?

> Does anyone know if PADL pam_ldap handles this more gracefully?

> I'm really drawing for straws here.

> --Polly

As someone pointed out to me, there is a bugid on this (
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4962745 )
unfortunately all it shows is 'in progress' which unfortunately to those
of us not employed by Sun, only means it'll be done when it's finished :)

I'm not sure if PADL's pam_ldap does any better.  I'm personally leaning
towards writing a replacement for the pam_ldap accounting piece that
will simply do an LDAP search and grab the needed attributes to
accomplish this as a stopgap since at this point the availability of the
fix unknown.

The thing I've been debating though is that where I work, we are using
separate proxy accounts (each with their own password) for each server
in order to control visibility of user entries to each server. Since
libsldap is not documented, there is no nice way to be able to perform
searches against the configured ldap server(s) using the ldap client
information (include proxy account credentials).

This means the password for the proxy account for a server would need to
be kept in two places on the server (one for the system ldap support  -
/var/ldap/ldap_client_cred as well as for this module), which then
complicates support (which becomes an issue with 2000+ servers, all with
varying user access requirements) if the passwords ever need to be
changed. There are a couple other options (special account all servers
bind as to check this, or allow it to be checked anonymously), but
present issues of their own.

 
 
 

pam_ldap and password management and rsh/ssh without password

Post by Jason Kin » Wed, 29 Jun 2005 14:09:12





>>>The System Administration Guide: Naming and Directory Services (DNS,
>>>NIS, and LDAP) says that if you enable pam_ldap that rsh/ssh and
>>>authentication that doesn't require a password will fail.  So it seems
>>>my choices are to fall back to pam_unix_account which ignores the fact
>>>that accounts may be expired (via ldap).  This doesn't make sense to
>>>me.  (Why isn't there a pam_ldap_account ?)

>>>I am not hiding expiry information from my proxy...why is this a
>>>problem?

>>>At any rate, I'm sure that there are people out there who are using
>>>ldap for password management that have a working solution with
>>>ldap/rsh/ssh and password aging.  What are people doing?

>>Funny you should mention that, I just mentioned something about this on
>>the opensolaris-rfe list -- basically what's happening is that it's
>>using an LDAP control that's returned as part of an ldap bind operation
>>to obtain password expiration information, which means of course that
>>pam_ldap has to actually be able to bind to the ldap server as the user
>>(which it cannot do when using public key auth or rhosts since it never
>>actually gets the password), so it returns a failure.

>>You might be able to get away with manually maintaining the
>>shadowAccount attributes (though I haven't tried this).  The
>>disadvantage to this is that then the clients are managing the password
>>policy instead of letting the ldap server do it (i.e. each client would
>>have to check the shadowLastChange, etc. attributes and enforce action
>>appropriately).  If you're doing only UNIX authentication, this might
>>work, if you also want to have other things authenticate against the
>>same ldap server to authenticate users, then you might start to run into
>>issues (as they would also have to know to check those attributes to
>>make sure an account isn't expired, or if they need to change their
>>password).

> I kind of figured it did a bind for account management , although I was
> hoping that it only used the bind for authentication verification.

> I can't believe there isn't anyone else with a working solution
> already.  Especially with audits pushing for password aging and
> increased security(while still having some automated processes to make
> your business run).

> I don't have a problem falling back to pam_unix but what's really the
> most effective way of updating the shadow entries?  A custom passwd
> command?

> Does anyone know if PADL pam_ldap handles this more gracefully?

> I'm really drawing for straws here.

> --Polly

One other thing I should mention... I suspect part of the issue as well
is that by using the LDAP controls to obtain the information, it
achieves a level of abstration from the actual implementation within the
LDAP server.  I suspect part of the problem is that the RFCs or draft
RFCs at this point I believe only define those password policy controls
as part of a bind operation, so that you if you want that information
outside of an ldap_bind(), you're out of luck (can anyone more familiar
with this comment/correct/elaborate?).