.k5login wildcard

[Tim Alsop]

Sam,

Our research on this subject suggests that pam does provide a "standard way" to convey the principal name for authorisation purposes. 

The idea is that the SSHD and/or TelnetD first authenticates the user and then calls the pam module to check if they are authorised to access a specific unix account. With this implementation approach we can create a pam module that uses regular .k5login files for authorisation mapping and then update this pam module to use ldap instead of .k5login. The customer who deployes the pam module can then decided whether they want their sshd or telnetd to use .k5login or ldap. Also, if in the future we find the need to add support for another repository containing centrally managed mapping rules (instead of an ldap directory) we can add this to the pam module without changing any code in the ssh or telnet products. As more implementations of ssh appear on the market with Kerberos support this flexibility, where we have separated authorisation checking from the ssh application will give the customers the capability to use .k5login or something more scalable. Also, if they are using !
 telnetd and sshd on same systems the authorisation checks will be consistent between the two.

What do you think about this ?

Tim.

-----Original Message-----
From: Sam Hartman [mailto:hartmans at mit.edu] 
Sent: 22 October 2003 15:25
To: Tim Alsop
Cc: Michael Conlen; kerberos at mit.edu
Subject: Re: .k5login wildcard

>>>>> "Tim" == Tim Alsop <Tim.Alsop at cybersafe.ltd.uk> writes:

    Tim> Michael, Would you be interested in a pam authorisation (not
    Tim> authentication) module that allowed you to store and manage
    Tim> this account name mapping information centrally in an ldap
    Tim> directory (or other central repository of information) ? You
    Tim> would not need to manage .k5login files in user home
    Tim> directories on 2000 machines if this was available ?

a PAM account module is not the right place for this.  Consider what happens when I ssh into a machine using GSSAPI authentication.  I pass along my credentials and authenticate my principal to the server principal on the remote side.

PAM does not provide a standardized way to let the account modules know what the Kerberos authentication identity is.  Nor does it really seem safe to use PAM for this purpose even with some non-standard PAM item to convey the principal.  I really want to make sure that at least one account module considered the principal and validated the mapping.  The failure mode where say only pam_unix.so is in the account stack and anyone gets in as any user they wish seems very unappealing.