On 8 Jun 2007, at 17:34, Michael B Allen wrote: > On Fri, 8 Jun 2007 09:00:09 +0100 > Simon Wilkinson <[EMAIL PROTECTED]> wrote: > >> Ultimately, this means you may need to have a keytab containing >> multiple different prinicpals for your service, and have >> mod_auth_kerb accept any one of these principals. Unfortunately, the >> code isn't there to do that in current mod_auth_kerb's. > > This seems odd to me. The krb5 lib should automatically seek out the > right key by searching for the desired principal, enctype and kvno.
No, that's not how it works if you specify a principal when you call gss_accept_sec_context. When a principal is specified the library will only accept incoming connections which are directed at that principal. mod_auth_kerb specifies HTTP/<gethostname()> as its acceptor principal, unless you override that with a mod_auth_kerb configuration directive, and even then you can only change it to use a different, single, principal. Historically, that's the best you could do with MIT Kerberos, unless you open the keytab, parse it to extract principal names, and call gss_accept_sec_context with each of them until it works. Recent MIT libraries (for some value of recent - I'm not sure when the code went in) allow you to pass GSS_C_NO_CREDENTIAL in to the gss_accept_sec_context routine, so that it will accept any principal in the keytab. I suspect that this is the behaviour you are relying on - but mod_auth_kerb doesn't invoke the GSSAPI library in this way, and so doesn't have that feature. Aside: If you're using a single, general purpose, keytab you almost certainly _don't_ want the GSS_C_NO_CREDENTIAL behaviour - you want to be sure that your ssh service will only accept 'host/' principals, for example. Cheers, Simon. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
