Another user at realm type issue/bug

Stefan Metzmacher metze at
Wed Oct 5 06:47:18 UTC 2016

Am 03.10.2016 um 19:42 schrieb Jeremy Allison:
> On Mon, Oct 03, 2016 at 10:30:28AM -0700, Jeremy Allison wrote:
>> 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
>>>>  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 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.
> So if it doesn't break anything in current make test
> I plan to push. If we need a test around differing
> samAccountName and UPN behavior we should add that
> and a separate function to use it IMHO. The pre-patch
> behavior is too strange to remain for general command
> line processing.

Please hold on on this.

I'm also looking at this currently and I think the topic is much
more complex.


More information about the samba-technical mailing list