On Wed, 2012-10-10 at 13:31 -0500, Will Fiveash wrote: > On Wed, Oct 10, 2012 at 12:40:12PM -0400, Greg Hudson wrote: > > On 10/10/2012 11:27 AM, Tomas Kuthan wrote: > > > in MIT krb there used to be a check making sure, that the principal name > > > of a keytab entry used to decode enc-part of a ticket equals sname from > > > that ticket. But this check went away [...] > > > > We removed this check in 1.7 and changed the way rd_req_dec works in > > order to support server principal aliases. You can read a bit about > > this at: > > > > http://k5wiki.kerberos.org/wiki/Projects/Aliases#Server_principals > > In that project description I see: > > "Server principals need to be handled differently. The problem is that > the KDC cannot generally change the name of the server principal. So, > instead, we must return the principal name exactly as the client asked > for it. However we need to come up with a solution so that the server > doesn't need to know the comparison function the KDC is using. > > We do this by ignoring the server name in the ticket (except in the KDB > keytab) and finding a key in the keytab that can decrypt the ticket. If > the application passes in constraints about what principal names are > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > used, we use these constraints. If not, we accept any key in the keytab. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > We update the context claiming that the client authenticated to whatever > principal is we found in the keytab. " > > How does the server application pass in the service principal > constraints? Does this mean that if a server calls gss_acquire_cred() > like so: > > maj = gss_acquire_cred(&min, GSS_C_NO_NAME, 0, indicated, > ^^^^^^^^^^^^^ desired name > GSS_C_ACCEPT, &creds, &acquired, NULL); > > the krb code will use any service princ keys found in the keytab, as > long as the hostname component matches, for accepting the AP_REQ?
That's exactly it. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
