Another user at realm type issue/bug

[Stefan Metzmacher]

Am 12.10.2016 um 00:30 schrieb Andrew Bartlett:
> On Wed, 2016-10-05 at 08:47 +0200, Stefan Metzmacher wrote:
>> 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 samba.e
>>>>>> xample.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.
>>>
>>> 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.
> 
> Thanks metze!
> 
> I've not forgotten this either, and I'm currently writing a new test
> for the credentials python bindings to help lock down the current
> behaviour. 

One important thing is that we need support

-U'MicrosoftAccount\user at example.com' and that
should result in domain "MicrosoftAccount" and
username "user at example.com", I'm unsure about the value
for principal. (Maybe principal and realm should be both NULL,
so that we don't try kerberos)
For NTLMSSP we need to send "MicrosoftAccount" as Domain.

and

-U'user at example.com' should result in domain = NULL (or ""?),
username = NULL and principal = "user at example.com", realm needs to be
unchanged (the value from smb.conf), after a successful kinit
we need to update realm (and maybe principal) to reflect
the values we got from the kdc.
For NTLMSSP we need to send "" as Domain.


The other thing is that with 'smbclient -k -Uuser' or
'smbclient -k -Uuser at example.com' we need to check that the
ccache values match the given values.
For these cases and the 'smbclient -k' case we
need to pickup the principal and realm from the ccache
and invalidate username and domain.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20161012/21a381a7/signature.sig>