Another user at realm type issue/bug
Jeremy Allison
jra at samba.org
Mon Oct 3 17:30:28 UTC 2016
On Mon, Oct 03, 2016 at 02:31:39PM +0200, Andreas Schneider wrote:
> On Friday, 30 September 2016 07:07:38 CEST Andrew Bartlett wrote:
> > What was the consumer in this case?
> >
> > While very strange, this was deliberate, as it was expected that the
> > callers would try and get the principal if that was set at a more
> > certain level (eg SPECIFIED compared to GUESS).
> >
> > The reason is that if I have a UPN of andrew.bartlett at samba.example.com
> > I may have a username of abartlet in samAccountName, and so logging in
> > over NTLM with andrew.bartlett wouldn't match, I would have to use andr
> > ew.bartlett at samba.example.com without a domain.
> >
> > Naturally, see bugs around that handling server-side, but that was the
> > idea, and it was hoped that very few codepaths would be asking for
> > either directly, hopefully only the gensec modules and the client SMB1
> > NTLM session setup code.
> >
> > This is why the patch to make the s3 session setup code take
> > cli_credentials (and so pass that down to NTLMSSP and krb5) is so
> > important.
> >
> > I hope this clarifies things, and reminds me that I should write a good
> > python testsuite to encode these expectations.
>
> As this parses a string obtained from the commanline with -U we should set
> username here! If you do not want to do that you should not use that function
> and call the function to set username directly! On the commandline there is
> only one option to set the username/principal and that is -U!
Yep, I have to agree. This is being called with CRED_SPECIFIED
from the command line means "shut up and do as I say here". The
patch is correct IMHO to fix the command line handling.
More information about the samba-technical
mailing list