Another user at realm type issue/bug

[Jeremy Allison]

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.