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

RE: PAM, When?



Luke,

Excuse me for being the voice of reason :-)

It sounds like you're suggesting that PAM subsume the functionality of the
GSS-API and SASL (for network-based authentication) and the NSS (for
acquiring account information). Whilst I'm sure PAM could be extended to do
this, I'm not sure whether it's such a good idea, when there are other
technologies that specifically address this.

> 1) PAM security negotiation to be abstracted from PAM itself.
>  take the
> example of the SMB protocol for NT5: SMBnegprot request now has an
> "EXTENDED_SECURITY" capabilities flag.  if set and the server responds
> that it supports it, the session goes into "abstracted
> security" mode.

You're sure Microsoft aren't using a SASL mechanism here? I know they are
for Active Directory. If so, then it would make sense to use GSS-API to
implement the token exchange (at least for Kerberos). I agree that a GSS-API
implementation which supported dynamic loading/unloading of mechanisms, per
PAM, would be a useful thing.

> 2) an extension to PAM to obtain user information and group
> information,
> abstracted sufficiently so that you no longer have to store
> /etc/group or
> any other authentication information on local machines _at all_.

Sure, but the only reason I can think of to do this would be to deal with
identities other than an integer UID and GID set (such as an NT5 PAC) --
otherwise you may as well write an NSS module. In this case, you're going to
have to modify a lot of stuff to deal with the new identities.

As far as additional credentials are concerned (such as acquiring a Kerberos
TGT) PAM already does the job. (And, yes, it works with an NT5 KDC.)


-- Luke



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