[17067] in Kerberos_V5_Development
Re: gss_krb5_import_cred fails for Samba
daemon@ATHENA.MIT.EDU (Nico Williams)
Sat Jul 23 00:13:03 2011
MIME-Version: 1.0
In-Reply-To: <1311391765.23877.203.camel@t410>
Date: Fri, 22 Jul 2011 23:12:59 -0500
Message-ID: <CAK3OfOhJ0bkzh2qz=aaTjDyVMzPJx_BHgnOHeWjDVQ96JUydoQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "samba-technical@samba.org" <samba-technical@samba.org>,
"lukeh@PADL.COM" <lukeh@padl.com>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, Jul 22, 2011 at 10:29 PM, Greg Hudson <ghudson@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 fordesired_name == GSS_C_NO_NAME. (GSS doesn't [yet] have a strongconcept of credential sets, as it requires that desired_name be thesame for all elements of a credential -- that is, it has a concept ofcredential set, but what must differ from one element to the next isthe mechanism, not the name.)
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
