gss_krb5_import_cred fails for Samba

[Andrew Bartlett]

On Fri, 2011-07-22 at 23:12 -0500, Nico Williams wrote:
> On Fri, Jul 22, 2011 at 10:29 PM, Greg Hudson <ghudson at mit.edu> wrote:
> > On Fri, 2011-07-22 at 20:14 -0400, Andrew Bartlett wrote:
> >> This case is where the principal is specified, and the incoming GSSAPI
> >> request has the same key and knvo, but a different server name?
> >
> > Contrary to what Luke says, I would expect this to work out of the box
> > in krb5 1.9.  If you look at the logic of
> > krb5_rd_req_decrypt_tkt_part() in rd_req_dec.c, you'll see that if
> > server != NULL, we look up server in the keytab and ignore
> > req->ticket->server.
> 
> I think using req->ticket->server is precisely what Andrew wants,
> which means using GSS_C_NO_CREDENTIAL *or* a credential acquired for
> desired_name == GSS_C_NO_NAME.  (GSS doesn't [yet] have a strong
> concept of credential sets, as it requires that desired_name be the
> same for all elements of a credential -- that is, it has a concept of
> credential set, but what must differ from one element to the next is
> the mechanism, not the name.)

I have two different use cases in Samba:
 - match by key (S3)
 - match to specified (by Samba) principal (S4)

The different use cases come from different historical implementation
choices, and in particular the difficult issue of creating code that
works with multiple kerberos libraries and versions, particularly as
behaviour of identically named functions changes. 

We almost never want to honour the principal in the ticket, as this only
ever works when Samba3 is a member of a MIT Kerberos realm, the clients
are not windows and the administrator has provided the keytab.  In any
case match by key optimistically tries this first, and would work here
anyway. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org