[modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari
Douglas E. Engert
deengert at anl.gov
Tue Jun 27 14:24:40 EDT 2006
Russ Allbery wrote:
> Douglas E Engert <deengert at anl.gov> writes:
>>Some comments on this approach. It appears that you are trying to
>>correct a fundalmental problem in the underlying Kerberos gss
> Well, actually, I'm doing GSSAPI cargo cult programming, but your way of
> phrasing that sounds so much nicer and more sophisticated. :)
>>On the server/acceptor side, if the gss_acquire_cred is called with a
>>GSS_C_NO_NAME, (or the gss_init_sec_context is not passed a
>>cred_handle) then any principal in the keytab should be acceptable,
>>In the MIT krb5-1.4.1 if the call to krb5_rd_req in
>>accept_sec_context.c: at line 405 has the cred->princ == NULL then the
>>krb5_rd_req will look in the keytab for the principal requested by the
>>We have a mod for this, see attachment, which would also allow for a
>>service principal in multiple realms. This mod was sent to the Kerberos
>>list a few years ago but never acted on by MIT. as far as I know.
> Aha! So this doesn't work currently with MIT Kerberos but would if your
> patch were applied? Am I reading your message correctly?
Its been a long time, since I tested the MIT without the patch. The MIT
code comments say it tries to fill in the cred->princ, but I don't see where
it does this and it could be it leaves it NULL.
The first test would be to not have mod_auth_kerb pass in a desired_name to
gss_accquire_cred, and see if the cred->princ is NULL. That might be the only
The patch was added to let krb5_rd_req use any entry in the keytab, even if
a desired_name was passed, check only the service and host. This is consistent
with the gss_import_name which only allows the application to specify
the service and host and not the realm, therefore don't assume the realm.
> Is this patch already in RT?
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
More information about the Kerberos