krb5.conf

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.

Any feedback is appreciated.

-- 
Jason Gerfen
jason.gerfengmail.com
_______________________________________________
krbdev mailing list             krbdevmit.edu
https
://mailman.mit.edu/mailman/listinfo/krbdev

Jason:


On Tue, 3 Apr 2007, 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

This configuration section in krb5.conf is
'application-specific', thus 
you shouldn't need to coordinate its syntax with MIT or
other Kerberos 
implementations.  It's specific to Nalin's PAM module.

> 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.

Are you going to implement principal mapping via the
'krbName' LDAP 
attribute?  That would be particularly interesting for me,
since currently 
there is no good way to configure pam_krb5 to authenticate
users in 
multiple realms, without maintaining a local mapping rules
file on each 
host.  (problematic if you have 1000s of machines)

What else were you intending to do with LDAP?


Thanks,

Chris Wing
wingcengin.umich.edu
_______________________________________________
krbdev mailing list             krbdevmit.edu
https
://mailman.mit.edu/mailman/listinfo/krbdev

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?

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?

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?

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.



> 
> Any feedback is appreciated.
> 

-- 

  Douglas E. Engert  <DEEngertanl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             krbdevmit.edu
https
://mailman.mit.edu/mailman/listinfo/krbdev

On 4/3/07, Douglas E. Engert <deengertanl.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  <DEEngertanl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>


-- 
Jason Gerfen
jason.gerfengmail.com
_______________________________________________
krbdev mailing list             krbdevmit.edu
https
://mailman.mit.edu/mailman/listinfo/krbdev

Jason Gerfen wrote:
> On 4/3/07, Douglas E. Engert <deengertanl.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.

So I assume you add the entry to the password file. Do you
ever clean
them up? Do you have a way to limit which AD users are
allowed on which 
machines? (netgroups could be used for this with NIS or
LDAP.)

> 
>> 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.
> 

Thats what nscd addresses. Available on Linix and Solaris,
maybe
other unix systems too.

> 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  <DEEngertanl.gov>
>>   Argonne National Laboratory
>>   9700 South Cass Avenue
>>   Argonne, Illinois  60439
>>   (630) 252-5444
>>
> 
> 

-- 

  Douglas E. Engert  <DEEngertanl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             krbdevmit.edu
https
://mailman.mit.edu/mailman/listinfo/krbdev

On 4/3/07, Douglas E. Engert <deengertanl.gov> wrote:
>
>
> Jason Gerfen wrote:
> > On 4/3/07, Douglas E. Engert <deengertanl.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.
>
> So I assume you add the entry to the password file. Do
you ever clean
> them up? Do you have a way to limit which AD users are
allowed on which
> machines? (netgroups could be used for this with NIS or
LDAP.)
>

Yeah, I wrote a small set of utilities for that.  There
currently
isn't a limit to the number of users but the cleanup
routines are
invoked each evening to remove old accounts.

> >
> >> 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.
> >
>
> Thats what nscd addresses. Available on Linix and
Solaris, maybe
> other unix systems too.
>

I will look into that.

> > 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  <DEEngertanl.gov>
> >>   Argonne National Laboratory
> >>   9700 South Cass Avenue
> >>   Argonne, Illinois  60439
> >>   (630) 252-5444
> >>
> >
> >
>
> --
>
>   Douglas E. Engert  <DEEngertanl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>


-- 
Jason Gerfen
jason.gerfengmail.com
_______________________________________________
krbdev mailing list             krbdevmit.edu
https
://mailman.mit.edu/mailman/listinfo/krbdev