Re: pam_ldap and password management and rsh/ssh without password
From: Jason King (jasonking_at_sbcglobal.net)
Date: 06/28/05
- Next message: Frank Cusack: "S10 partition table"
- Previous message: Alan DuBoff: "3rd OpenSolaris User Group Meeting in Santa Clara, CA on Tues., June 28th 7:30pm"
- In reply to: Polly Squires: "Re: pam_ldap and password management and rsh/ssh without password"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 28 Jun 2005 05:09:12 GMT
Polly Squires wrote:
>
> Jason King wrote:
>
>>Polly Squires wrote:
>>
>>>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?).
- Next message: Frank Cusack: "S10 partition table"
- Previous message: Alan DuBoff: "3rd OpenSolaris User Group Meeting in Santa Clara, CA on Tues., June 28th 7:30pm"
- In reply to: Polly Squires: "Re: pam_ldap and password management and rsh/ssh without password"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
