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:[EMAIL PROTECTED] Sent: 22 October 2003 15:25 To: Tim Alsop Cc: Michael Conlen; [EMAIL PROTECTED] Subject: Re: .k5login wildcard >>>>> "Tim" == Tim Alsop <[EMAIL PROTECTED]> 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. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
