New PAM module pam_krb5+ldap

[Aaron Hope]

I was just trying to understand what problem you are trying to solve.
It wasn't clear to me from your description that you were performing
on-the-fly imports to the local password database.  It sounded like you
were trying to do without libnss account resolution, and the only reason
I could think of doing so was a desire to restrict access to the
directory to authenticated kerberos principals.  I see now that the idea
is to eliminate/reduce the dependency on the LDAP server.  The talk of
NIS and referring to pam_ldap instead of nss_ldap helped muddy the
waters.

Now that I understand, I can definitely see the appeal.  

I have now read the install doc, and parts of the configuration file
seem a little counterintuitive.  I would have expected "Default_foo" to
only come into play if "foo" is otherwise unset.  What about either
dropping the Default_ sense and making the account values definitive and
allowing reference to the LDAP attribute name or at least separating out
the override mandate, e.g. Ignore_LDAP_Uid: bool?  Being able to specify
the LDAP attribute would be handy anyway, to allow for different account
schemas, such as posixAccount instead of the microsoft SFU variant.

On Fri, 2005-10-14 at 05:48 -0600, Jason Gerfen wrote:
> Well it certainly isn't a solution for everyone, just an alternative.
> 
> Aaron Hope wrote:
> 
> >Hello,
> >I am rather curious as to why nss_ldap is not appropriate for the
> >situation you describe.  My experience is with OpenLDAP and nss_ldap
> >+pam_ldap, so I am probably missing something here.  With OpenLDAP, if I
> >wanted to keep the contents of the directory private, I would just have
> >the hosts authenticate to a service account, probably using
> >certificates, and have nscd perform the authenticated name resolution.
> >Could you not accomplish something similar with kerberos?  What about
> >group support?  Is this meant to complement a libnss module?
> >
> >On Thu, 2005-10-13 at 08:55 -0600, Jason Gerfen wrote:
> >  
> >
> >>Morning,
> >>    I have been working on making some additions to the original 
> >>pam_krb5 module for a little while and I can say that it is stable 
> >>enough for release.  Details on the additions follow;
> >>
> >>pam_krb5+ldap
> >>
> >>requirements:
> >>Linux-PAM libs
> >>Kerberos libs
> >>OpenLDAP libs
> >>
> >>summary:
> >>Anyone that has used the existing pam_krb5 authentication module for 
> >>linux clients has at some point had to configure a new service to 
> >>provide user enumeration such as NIS, Samba etc., or as well as setting 
> >>up a new service had to configure the pam_ldap module or some other 
> >>method of keeping user accounts, more specifically the uid, and gid for 
> >>the user available to the pam_krb5 module during the TGT verification 
> >>process.
> >>
> >>Since we do not authenticate users against LDAP, NIS or Samba but have a 
> >>LDAP / AD directory filled with users, uid's, gid's, home directory's 
> >>and default shell's I have added a couple of functions to generate the 
> >>userdata that populates the AD (unix services schema) / LDAP directory 
> >>and hand it off to the TGT verification process.
> >>
> >>Not everyone out there has this type of setup I understand, but for 
> >>those that do require Kerberos authentication and don't wish to run a 
> >>secondary service such as NIS when they already have a good AD / LDAP 
> >>directory filled with user data this is your module.
> >>
> >>I hope this helps some people out and if you find anything wrong with it 
> >>let me know.
> >>
> >>http://sourceforge.net/projects/pam-krb5-ldap
> >>
> >>    
> >>
> 
>