Russ Allbery wrote:
> Douglas E Engert <[EMAIL PROTECTED]> writes: > > >>Some comments on this approach. It appears that you are trying to >>correct a fundalmental problem in the underlying Kerberos gss >>implementation. > > > 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 >>client. > > >>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 thing needed! 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? Not sure. > -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
