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 passwd a > crede_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? Is this patch already in RT? -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos