samba - Oct 2016 - winbindd losing track of RFC2307 UIDs

Am 05.10.2016 um 22:12 schrieb Rob via samba:
> On Tue, 4 Oct 2016, Rowland Penny wrote:
>
>> This is very strange, have you tried running 'net cache flush'
on the
>> domain member ?
>>
>> Have you compared the users AD objects ?
>
> Running 'net cache flush' on the member does fix things, albeit
only
> for a while:
>
> # wbinfo -i auser
> auser:*:2020:10000:User Name:/home/auser:/bin/bash
> # net cache flush
> # wbinfo -i auser
> auser:*:10028:10000:User Name:/home/auser:/bin/bash
> [...wait a few hours...]
> # wbinfo -i auser
> auser:*:2020:10000:User Name:/home/auser:/bin/bash
>
> Using ldbsearch on sam.ldb on the DC, I compared the attributes of 
> problematic users and normal users... I couldn't find anything obvious 
> distinguishing them.
>
> Also, on the member:
>
> # net idmap dump
> dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb
> [...]
> UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177
>
> (where S-*-1177 is the SID for auser)
>
> But I'd think winbindd would prefer the mapping in AD, given smb.conf 
> having our domain listed explicitly and 2xxx only as a 
> default/fallback. Or maybe I misunderstand how the idmaps work... does 
> the order in smb.conf matter at all?
>
> _Rob
>
>
Hi Rob,

You can try to use tdbtool to delete the offending key with uid 2020. 
https://www.samba.org/samba/docs/man/manpages-3/tdbtool.8.html
I'd stop samba make an backup of winbind_idmap.tdb and give it a try.
In my case deleting the mappings from idamp.tdb fixed the issue of 
changing uid's.

achim~

Am 05.10.2016 um 22:31 schrieb Achim Gottinger via
samba:
>
>
> Am 05.10.2016 um 22:12 schrieb Rob via samba:
>> On Tue, 4 Oct 2016, Rowland Penny wrote:
>>
>>> This is very strange, have you tried running 'net cache
flush' on the
>>> domain member ?
>>>
>>> Have you compared the users AD objects ?
>>
>> Running 'net cache flush' on the member does fix things, albeit
only
>> for a while:
>>
>> # wbinfo -i auser
>> auser:*:2020:10000:User Name:/home/auser:/bin/bash
>> # net cache flush
>> # wbinfo -i auser
>> auser:*:10028:10000:User Name:/home/auser:/bin/bash
>> [...wait a few hours...]
>> # wbinfo -i auser
>> auser:*:2020:10000:User Name:/home/auser:/bin/bash
>>
>> Using ldbsearch on sam.ldb on the DC, I compared the attributes of 
>> problematic users and normal users... I couldn't find anything 
>> obvious distinguishing them.
>>
>> Also, on the member:
>>
>> # net idmap dump
>> dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb
>> [...]
>> UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177
>>
>> (where S-*-1177 is the SID for auser)
>>
>> But I'd think winbindd would prefer the mapping in AD, given
smb.conf
>> having our domain listed explicitly and 2xxx only as a 
>> default/fallback. Or maybe I misunderstand how the idmaps work... 
>> does the order in smb.conf matter at all?
>>
>> _Rob
>>
>>
> Hi Rob,
>
> You can try to use tdbtool to delete the offending key with uid 2020. 
> https://www.samba.org/samba/docs/man/manpages-3/tdbtool.8.html
> I'd stop samba make an backup of winbind_idmap.tdb and give it a try.
> In my case deleting the mappings from idamp.tdb fixed the issue of 
> changing uid's.
>
> achim~
>
>
Did the uid change from 2018 to 2020 or is this an different user or 
member server? If it changed editing winbindd_idmap.tdb might not fix 
your problem.

This is what there is in winbindd_idmap.tdb of both members that i have,
whewre file server 2 is working well and file server 1 lose winbind rfc
track.

#
# FILE SERVER 1 - PROBLEM
#
# tdbdump winbindd_idmap.tdb
{
key(9) = "USER HWM\00"
data(4) = "\D0\07\00\00"
}
{
key(10) = "GROUP HWM\00"
data(4) = "\D0\07\00\00"
}
{
key(14) = "IDMAP_VERSION\00"
data(4) = "\02\00\00\00"
}



#
# FILE SERVER 2 - OK
#
# tdbdump winbindd_idmap.tdb
{
key(9) = "GID 2002\00"
data(9) = "S-1-5-11\00"
}
{
key(9) = "S-1-5-11\00"
data(9) = "GID 2002\00"
}
{
key(9) = "USER HWM\00"
data(4) = "\D0\07\00\00"
}
{
key(9) = "GID 2000\00"
data(8) = "S-1-1-0\00"
}
{
key(8) = "S-1-1-0\00"
data(9) = "GID 2000\00"
}
{
key(8) = "S-1-5-2\00"
data(9) = "GID 2001\00"
}
{
key(10) = "GROUP HWM\00"
data(4) = "\D3\07\00\00"
}
{
key(9) = "GID 2001\00"
data(8) = "S-1-5-2\00"
}
{
key(14) = "IDMAP_VERSION\00"
data(4) = "\02\00\00\00"
}

2016-10-05 18:44 GMT-03:00 Achim Gottinger via samba <samba at
lists.samba.org>
:
>
>
> Am 05.10.2016 um 22:31 schrieb Achim Gottinger via samba:
>
>>
>>
>> Am 05.10.2016 um 22:12 schrieb Rob via samba:
>>
>>> On Tue, 4 Oct 2016, Rowland Penny wrote:
>>>
>>> This is very strange, have you tried running 'net cache
flush' on the
>>>> domain member ?
>>>>
>>>> Have you compared the users AD objects ?
>>>>
>>>
>>> Running 'net cache flush' on the member does fix things,
albeit only for
>>> a while:
>>>
>>> # wbinfo -i auser
>>> auser:*:2020:10000:User Name:/home/auser:/bin/bash
>>> # net cache flush
>>> # wbinfo -i auser
>>> auser:*:10028:10000:User Name:/home/auser:/bin/bash
>>> [...wait a few hours...]
>>> # wbinfo -i auser
>>> auser:*:2020:10000:User Name:/home/auser:/bin/bash
>>>
>>> Using ldbsearch on sam.ldb on the DC, I compared the attributes of
>>> problematic users and normal users... I couldn't find anything
obvious
>>> distinguishing them.
>>>
>>> Also, on the member:
>>>
>>> # net idmap dump
>>> dumping id mapping from
/usr/local/samba/var/locks/winbindd_idmap.tdb
>>> [...]
>>> UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177
>>>
>>> (where S-*-1177 is the SID for auser)
>>>
>>> But I'd think winbindd would prefer the mapping in AD, given
smb.conf
>>> having our domain listed explicitly and 2xxx only as a
default/fallback. Or
>>> maybe I misunderstand how the idmaps work... does the order in
smb.conf
>>> matter at all?
>>>
>>> _Rob
>>>
>>>
>>> Hi Rob,
>>
>> You can try to use tdbtool to delete the offending key with uid 2020.
>> https://www.samba.org/samba/docs/man/manpages-3/tdbtool.8.html
>> I'd stop samba make an backup of winbind_idmap.tdb and give it a
try.
>> In my case deleting the mappings from idamp.tdb fixed the issue of
>> changing uid's.
>>
>> achim~
>>
>>
>> Did the uid change from 2018 to 2020 or is this an different user or
> member server? If it changed editing winbindd_idmap.tdb might not fix your
> problem.
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


-- 

-------------------------------------------
Edson Tadeu Almeida Silveira
http://sites.google.com/site/edsontadeu/
-------------------------------------------

On Wed, 5 Oct 2016, Achim Gottinger wrote:
>> Hi Rob,
>> 
>> You can try to use tdbtool to delete the offending key with uid 2020. 
>> https://www.samba.org/samba/docs/man/manpages-3/tdbtool.8.html
>> I'd stop samba make an backup of winbind_idmap.tdb and give it a
try.
>> In my case deleting the mappings from idamp.tdb fixed the issue of
changing
>> uid's.
>> 
>> achim~
>> 
>> 
> Did the uid change from 2018 to 2020 or is this an different user or member
> server? If it changed editing winbindd_idmap.tdb might not fix your
problem.
It didn't change, it was my copy+paste mistake.  (At the time, the UID 
from the "broken" state was outside of my terminal's scrollback
range; I
thought it was 2018 but I was wrong; it was 2020 all along.)

All of my users seem to have entries in winbindd_idmap.tdb, actually; not 
just the ones that have UID-changing problems.

_Rob