> >> 2. Proposal
> >> -----------
> >
> >> This is deliberately a file on the local host rather than something
> >> held in LDAP against the user or host. There are other means for
> >> restricting authentication when pam_ldap is used, these based on the
> >> capabilities of the LDAP server and are sometimes specific to a given
> >> LDAP server.
> >
> > I'm confused with what point is being made. LDAP is a name
> > service and can serve up name service requests such as
> > getpwent(), getnetrent(), ... pam_ldap(5) is a PAM service
> > module that coerces an LDAP style directory service into
> > an account authority.
> > But you know that, thus my confusion.
>
> PAM is what should be used to control access to a given system, this
> case provides a module to do that with the data stored in a local file.
I agree with PAM account management being the correct control
point. This part of my comment was more about conflagration
with pam_ldap that I wasn't sure of your point. More below.
> >> There is also purposely no admin command, the customers requesting
> >> this functionality want a raw file as that is what they already use
> >> on Linux or on Solaris with the existing open source module.
> >
> > IMO, this is an excuse for not providing a properly auditable
> > administrative interface and not a reason.
>
> I disagree, we are giving the customers what they want and what they
> need. I agree it doesn't provide an easily audited admin interface but
> the funding just isn't there to provide that capability and we really
> can't hold of providing this simple module any longer our customers are
> already really really annoyed it has taken us so long to do so.
Not saying the CU be damned, but just the opposite. IMO, as
I believe I stated this 3.5 years ago when this started, this
project is kludge/bandaid for lack of a proper architecture.
I'm saddened that such an architecture doesn't seem to be
forthcoming.
Gary..
