krb5.conf

[Jason Gerfen]

On 4/3/07, Douglas E. Engert <deengert at anl.gov> wrote:
>
>
> Jason Gerfen wrote:
> > Hello,
> > I am not sure where to ask this but I have been working on a project
> > for my employer which implements some OpenLDAP/ Active Directory
> > lookup information for the existing pam_krb5 module maintained by
> > Nalin Dahyabhai.
> >
> > Does your group accept proposals regarding *new features for the krb5.conf?
> >
> > If so, I am proposing the following type of configuration directives be added;
> >
> > [appdefaults]
> > pam = {
> >       ticket_lifetime = 1d
> >       ...
> >         schema_type = [ad | ldap]
> >         server_list = server1.ldap.com server2.ldap.com
> >         ldap_port = 389
> >         ldap_ssl = [ ssl | tls ]
> >         bind_dn = uid=username,ou=container,dc=domain,dc=com
> >         base_dn = ou=listofusers,dc=domain,dc=com
> >         read_user = readonlyusername
> >         ldap_pass =  [md5hash of password]
> > }
> >
> > If I am indeed asking the wrong questions or proposing something that
> > would be better off implemented using a separate configuration file
> > etc. etc. Let me know.
> >
> > I am currently using a separate configuration file to manage the
> > application directives and for those that want to know something about
> > the project here is a brief synopsis:
> >
> > Creates a local *password-less user account for the uid/gid mapping
> > currently in the pam_krb5 authentication process from results of the
> > ldap / active directory lookup on the user name. Please note that
> > unlike the nss_ldap, pam_ldap modules currently used this addition to
> > the pam_krb5 module does NOT try to authenticate the user using ldap,
> > it simply uses it as a method of looking up remote users vs. using nss
> > etc. etc.
>
> You meantion the nss_ldap and pam_ldap, but you can use nss_ldap without
> pam_ldap. Thus a pam_krb5 with the nss_ldap should do every thing you are
> proposing to do since the getpwnam and related routines used by pam_krb5
> all end up using nsswitch.conf and thus can use nss_ldap. Also AD
> does have some support for RFC 2307. Am I missing something?
>

In short, my boss asked me to modify the existing pam_krb5 to add this
functionality for ease of configuration, ability to 'not' store local
hashed passwords for domain users, and remove the need for the
nsswitch.conf.

> If you are not going to use nss_ldap, how will you handle calls to
> getpwnam and friends by other non-login programs for example "ls" which
> needs to map uid to names?
>

Instead of using slurpd or another replication application to populate
local accounts the account is created when needed without any password
information.

> Also look at nscd that will cache information obtained via nsswitch
> including nss_ldap. If nss_ldap is not good enough for your applicaiton,
> why not look at modifying nss_ldap?
>

If I remember correctly when I initially started this I did some
testing with stacking the nss_ldap module along with the pam_krb5 and
some issues my boss had with the results were the constant lookups the
nss_ldap module required which caused some lag in processing.

Originally I was going to use this method as everything I saw pointed
me in this direction for the authentication of remote users in linux,
but again... my boss wanted a different solution.

> So I would say the use of the krb5.conf is not the place for your
> configuration.
>
>
> In any case, since this is a Kerberos list, why are you still using
> simple bind, and not SASL with GSSAPI using the host principal? That
> works with AD, if the host is registered.

Next feature I am going to implement to help assure user specific data
is not listened to on the line.

>
>
>
> >
> > Any feedback is appreciated.
> >
>
> --
>
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>


-- 
Jason Gerfen
jason.gerfen at gmail.com