Thoughts on initial ticket acquisition/verification on Sun (slightly OT)

[Nicolas Williams]

On Wed, Nov 16, 2005 at 05:12:01PM -0800, Henry B. Hotz wrote:
> I just finished an auth plugin for Sun LDAP 5.2 that will accept a  
> simple bind username/password and verify it against a K5 server.  It  
> carefully does nothing if it's a SASL bind so the native SASL/GSSAPI/ 
> K5 bind works as expected, using the native Sun Kerberos libraries.   
> It calls the MIT-API routines discussed on this list, so it works  
> with either MIT or Heimdal libraries (linked so they don't  
> interfere).  It uses the same ldap/... principal and keytab that the  
> Sun SASL support uses, and we will configure things so that keytab  
> isn't the system one.
> 
> Nico suggested that I consider using PAM for this function.  That  
> does fill the functionality gap in GSSAPI, but. . .  Sun's pam_krb5  
> uses the system keytab and the host/... principal.  There don't seem  
> to be any options to change the keytab location and principal used to  
> do the verifications.
> 
> I think pam_krb5 should let you specify the keytab file and the check  
> principal.
> 
> I think GSSAPI and MIT-API libraries should have an environment  
> variable that sets the default keytab file, analogous to KRB5CCNAME.   
> The commercial sendmail authproxy uses KRB5_KTNAME.
> 
> Alternatively I think the keytab file location could be put in the  
> [appdefaults] section of krb5.conf.  Or both.  The point is:  this is  
> best practice;  you should support it in the libraries, not require  
> every application to program it independently.

So, short-term we have gss_acquire_cred_with_password() in Solaris
Nevada.

Medium-term we will just open the krb5 API[0].

Long-term we'd like to have a generic API based on extensions to the
GSS-API.

As to selection of a keytab file and/or principal to use for TGT
verification, neither gss_acquire_cred_with_password() nor the PAM
method will allow you to do more than to specify a keytab file using the
KRB5_KTNAME environment variable.  Given that we will open the krb5 API
we're not likely to consider any RFEs for adding some mechanism for
selecting a principal to use in TGT verification to pam_krb5 or libgss/
mech_krb5 to be high priority RFEs, but if you'd like I'll open one.

[0]  http://blogs.sun.com/roller/page/craigsblog/20050921


Nico
--