Thoughts on initial ticket acquisition/verification on Sun (slightly OT)
Nicolas.Williams at sun.com
Thu Nov 17 18:52:00 EST 2005
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
> 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
Medium-term we will just open the krb5 API.
Long-term we'd like to have a generic API based on extensions to the
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.
More information about the krbdev