[17054] in Kerberos_V5_Development
Re: gss_krb5_import_cred fails for Samba
daemon@ATHENA.MIT.EDU (Andrew Bartlett)
Tue Jul 19 21:08:53 2011
From: Andrew Bartlett <abartlet@samba.org>
To: Greg Hudson <ghudson@mit.edu>
Date: Wed, 20 Jul 2011 11:08:47 +1000
In-Reply-To: <1311092388.23877.86.camel@t410>
Message-ID: <1311124129.2183.2.camel@obed>
Mime-Version: 1.0
Cc: "lukeh@PADL.COM" <lukeh@padl.com>, "krbdev@mit.edu" <krbdev@mit.edu>,
"samba-technical@samba.org" <samba-technical@samba.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Tue, 2011-07-19 at 12:19 -0400, Greg Hudson wrote:
> On Mon, 2011-07-18 at 10:30 -0400, Andrew Bartlett wrote:
> > This is because alloc_union_cred() calls [...]
>
> Judging by the code in g_acquire_cred.c, the call to
> mech->gss_display_name should be conditional on mech_name !=
> GSS_C_NO_NAME.
>
> If you're in a position to test the attached patch and it let it know if
> it resolves the case where the principal is unspecified, that would be
> helpful.
>
> > If the principal is specified (matching the keytab value of host$@REALM)
> > then the login fails with 'Wrong principal in request'.
>
> I'd be interested in knowing more about why this is; I wouldn't expect
> it to happen as long as the specified principal exists in the keytab.
>
> > Given this function seems to have been added for Samba, is there a test
> > case that could be expanded to ensure that Samba's needs for this
> > function can be met?
>
> I will try to add some automated tests for these scenarios.
I'll try and rebuild the krb5 rpm on my system today or tomorrow, with
that patch (it certainly looks like the right kind of fix).
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
