pam_krb5 patch questions, feedback

[Jason Gerfen]

This might be a bit lengthy but I think my patch submission and the 
feedback I am requesting might warrant an explanation.

I work at the University of Utah, where in our decision to push Linux in 
our public and student lab computers I was tasked with researching 
possible authentication methods of ensuring any user account (all 100k+) 
could log into any one of the possible linux systems in any of our 
public or lab areas.

During this research I came across two possible configuration scenarios 
utilizing the pam_ldap and/or nss_ldap and pam_krb5 within the pam stack.

After testing in our computing environment my bosses decision was to 
develop an easier method; in terms of configuration and need for 
additional network services.

We utilize a Kerberos realm and have the UNIX4AD extensions configured 
in the Active Directory domain for our students, faculty, staff and 
public logins. Originally the UNIX4AD schema objects were added to 
ensure the same authentication for the MAC OSX clients also in our 
environment.

The need to prevent additional network resources and extensive 
configuration for the linux clients was deemed unnecessary and unwanted 
by by boss and others. So development began to add a simple to 
configure, easy to use method of configuring the krb5.conf file with 
additional OpenLDAP/Active Directory options to generate a password-less 
account after a successful Kerberos authentication took place.

As an example of the easy to use configuration options I am detailing a 
sample krb5.conf here:

[appdefaults]
pam = {
        ticket_lifetime = 1d
        renew_lifetime = 1d
        forwardable = true
        proxiable = false
        retain_after_close = false
        minimum_uid = 2
        try_first_pass = true
        ignore_root = true

        schema = ad
        ldapservs = 192.168.20.130 192.168.20.131
        ldapport = 389
        binddn = uid=[username],ou=Users,dc=sample,dc=domain,dc=com
        basedn = dc=sample,dc=domain,dc=com
        ldapuser = [readonly-username]
        ldappass = [readonly-password]
        
        passwd = /etc/passwd
        shadow = /etc/shadow
        groups = /etc/group

        groups_list = audio,cdrom,cdrw,usb,plugdev,video,games

        # If you define these they will
        # over write anything obtained from
        # ldap/active directory
        homedir = /home
        defshell = /bin/bash
}

And of course an example configuration of the pam stack:

#%PAM-1.0

auth            required        pam_env.so
auth            sufficient      pam_krb5.so
auth            sufficient      pam_unix.so try_first_pass likeauth nullok
auth            required        pam_deny.so

account         required        pam_unix.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password        sufficient      pam_krb5.so
password        sufficient      pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password        required        pam_deny.so

session         required        pam_limits.so
session         required        pam_env.so
session         optional        pam_krb5.so
session         required        pam_unix.so
session         required        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session         optional        pam_permit.so

Simply configure the module with the --with-ldap option and you are off 
an running. This may not be an option for everyone or should it serve as 
a replacement for utilizing the pam_ldap/nss_ldap modules. It is just 
another option for desktop linux configurations.

I have recently submitted a patch to Nalin Dahyabhai and was wondering 
if anyone could possibly provide feedback and possible testing?

If interested in the patch (which still needs a bit of tweaking and some 
ssl, tls addition features), however until then you can view it here: 
[http://bugzilla.redhat.com/show_bug.cgi?id=517096]

Thanks.

-- 
Jason Gerfen
Systems Administration/Web application development
jason.gerfen at scl.utah.edu