[PATCHES] winbindd: fix sid->xid for SID History SIDs

[Uri Simchoni]

On 03/28/2017 11:08 PM, Uri Simchoni via samba-technical wrote:
> On 03/28/2017 03:11 PM, Stefan Metzmacher wrote:
>> Hi Uri,
>>
>>>> The fix finds the domain of the SID by resolving a SID with same domain
>>>> component and an RID of 513 (domain users), which hopefully never gets
>>>> migrated.
>>
>> I think we should better try to resolve the domain sid, instead
>> of relying on RID 513.
>>
>> And we should only do that if we don't know about the domain yet.
>>
>>>> We've discussed other means such as smb.conf stuff or netsamlogon - I
>>>> think those methods can come on top of this method, because if they
>>>> don't work we should always fall back to something. The added resolving
>>>> doesn't cost much because it's in the same round-trip.
>>>>
>>>> The key thing about this fix is that doesn't try to translate sid->xid
>>>> in any possible case (such as when old domain is gone and forgotten), it
>>>> just avoids getting the *wrong* result. As such, it's a good minimal fix
>>>> that can be applied to stable versions. For master, we can add the
>>>> smb.conf-based stuff, that will support more cases.
>>>>
>>>> Review appreciated.
>>>> Thanks,
>>>> Uri.
>>>
>>> mostly lgtm, just one issue, see below.
>>>
>>> Fwiw, I'm currently working on another issue in sids2xids. Not really related
>>> but I'm mentioning it here as you're currently having fun with the same area of
>>> code.
>>
>> I think this is related...
>>
>> I'm wondering if your fixes would also fix Uri's problem.
>>
>> At least we should carefully think about this and have one
>> combined and tested patchset.
>>
>> Otherwise both of you have tested something that won't reflect the reality.
>>
>> Uri, can you run a command like this:
>> bin/rpcclient -UW4EDOM-L4\\administrator%A1b2C3d4
>> w2008r2-133.w4edom-l4.base -c 'lookupsids
>> S-1-5-21-278041429-3399921908-1452754838-66666
>> S-1-5-21-278041429-3399921908-1452754838
>> S-1-5-21-278041429-3399921908-1452754837-77777
>> S-1-5-21-278041429-3399921908-1452754837 S-1-5-32-66666 S-1-5-32
>> S-1-5-32-544' -d 10
>>
>> That tries to resolve the primary sid of a user, the sid history value
>> and both domain sids and invalid sids in both domains at the same time
>> (in various order combinations)?
>> I guess that will help a lot to see the answers from a Windows DC in that
>> case.
>>
>> Thanks!
>> metze
>>
> One of my DCs was moved somewhere, can't find it right now, will sort
> this out tomorrow. So meanwhile I queried just one DC, in various
> combinations - all provided the same results.
> 
> See attached Python script and its output. I'll extend that to work vs
> two DCs of both domains simultaneously- throw some of the combinations
> on one and some on the other.
> 
> Thanks,
> Uri.
> 

I also added same queries to the DC of the other domain, and in
parallel, and with permutations, all yielded same result.

However, all the SIDs I asked about belonged to DOMAIN2 (primary SID or
sid history SID). When adding SIDs of DOMAIN1 to the mix, I got one
peculiar finding, namely that one of the DC's is unable to resolve sid's
which are in sid history of another domain, while the other DC can:

My domains:
uri-vgw-6:~ # wbinfo -n 'DOMAIN1\'
S-1-5-21-3293503978-489118715-2763867031 SID_DOMAIN (3)
uri-vgw-6:~ # wbinfo -n 'DOMAIN2\'
S-1-5-21-1387724271-3540671778-1971508351 SID_DOMAIN (3)

(DOMAIN1 is forest root)

The DC that can:

Ask DOMAIN1 about primary SID in DOMAIN2:
uri-vgw-6:~ # rpcclient dom1.domain1.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-1387724271-3540671778-1971508351-1115'
S-1-5-21-1387724271-3540671778-1971508351-1115 DOMAIN2\d1u1 (1)

Ask DOMAIN1 about sid-history in DOMAIN2:
uri-vgw-6:~ # rpcclient dom1.domain1.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-3293503978-489118715-2763867031-1106'
S-1-5-21-3293503978-489118715-2763867031-1106 DOMAIN2\d1u1 (1)

Ask DOMAIN1 about primary SID in DOMAIN1:
uri-vgw-6:~ # rpcclient dom1.domain1.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-3293503978-489118715-2763867031-1114'
S-1-5-21-3293503978-489118715-2763867031-1114 DOMAIN1\d1u8 (1)

Ask DOMAIN1 about sid-history in DOMAIN1:
uri-vgw-6:~ # rpcclient dom1.domain1.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-1387724271-3540671778-1971508351-1114'
S-1-5-21-1387724271-3540671778-1971508351-1114 DOMAIN1\d2u10 (1)
uri-vgw-6:~ #

Now same questions to DOMAIN2, last one returns unknown:

uri-vgw-6:~ # rpcclient dom2.domain2.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-1387724271-3540671778-1971508351-1115'
S-1-5-21-1387724271-3540671778-1971508351-1115 DOMAIN2\d1u1 (1)

uri-vgw-6:~ # rpcclient dom2.domain2.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-3293503978-489118715-2763867031-1106'
S-1-5-21-3293503978-489118715-2763867031-1106 DOMAIN2\d1u1 (1)

uri-vgw-6:~ # rpcclient dom2.domain2.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-3293503978-489118715-2763867031-1114'
S-1-5-21-3293503978-489118715-2763867031-1114 DOMAIN1\d1u8 (1)

uri-vgw-6:~ # rpcclient dom2.domain2.local -U
'administrator%activenas08!' -c 'lookupsids
S-1-5-21-1387724271-3540671778-1971508351-1114'
S-1-5-21-1387724271-3540671778-1971508351-1114 *unknown*\*unknown* (8)
uri-vgw-6:~ #


- There's a two-way trust between the DCs
- The one that *can* is 2008R2
- The one that can't is 2012R2

With respect to the sid-history fix though, what we know so far is that
a DC will give you the correct result or no result, and if we always
lookup in our domain, that's good enough IMHO.

Thanks,
Uri.