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 > >> > >> > >> > > _______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
