gid numbers changed after upgrading from 4.1.14 to 4.2.1

[Rowland Penny]

On 23/04/15 16:43, Daniele Dario wrote:
>
> On gio, 2015-04-23 at 13:03 +0200, Daniele Dario wrote:
>> On mer, 2015-04-22 at 13:42 +0100, Rowland Penny wrote:
>>> On 22/04/15 13:20, Daniele Dario wrote:
>>>> On mer, 2015-04-22 at 12:34 +0100, Rowland Penny wrote:
>>>>> On 22/04/15 12:12, Daniele Dario wrote:
>>>>>> About the libnss_winbind links, kdc01 is a VM with ubuntu 10.04 32bit so
>>>>>> I have
>>>>>>
>>>>>> [root at kdc01:~]# ll /lib/i386-linux-gnu/libnss_winbind.so*
>>>>>> lrwxrwxrwx 1 root root 38 2014-12-11
>>>>>> 18:03 /lib/i386-linux-gnu/libnss_winbind.so
>>>>>> -> /usr/local/samba/lib/libnss_winbind.so*
>>>>>> lrwxrwxrwx 1 root root 40 2014-12-11
>>>>>> 18:03 /lib/i386-linux-gnu/libnss_winbind.so.2
>>>>>> -> /usr/local/samba/lib/libnss_winbind.so.2*
>>>>> This is what I would expect on a DC where samba4 was self compiled, the
>>>>> references to libnss_winbind in /lib/i386-linux-gnu are symbolic links
>>>>> to the actual files in /usr/local/samba/lib
>>>>>
>>>>>> kdc03 is a real machine 64bit with ubuntu 12.04
>>>>>>
>>>>>> [root at kdc03:/usr/local/samba/private]#
>>>>>> ll /lib/x86_64-linux-gnu/libnss_winbind.so*
>>>>>> lrwxrwxrwx 1 root root 19 May 19
>>>>>> 2014 /lib/x86_64-linux-gnu/libnss_winbind.so -> libnss_winbind.so.2*
>>>>>> lrwxrwxrwx 1 root root 24 May 12
>>>>>> 2014 /lib/x86_64-linux-gnu/libnss_winbind.so.2
>>>>>> -> /lib64/libnss_winbind.so*
>>>>>>
>>>>>>
>>>>> And here, the first one appears to be a symbolic link to the second,
>>>>> which appears to be another symbolic link to a file that appears to have
>>>>> nothing to do with the files you compiled in /usr/local/samba.
>>>>>
>>>>> Could these be the remains of the previous samba install ?
>>>>> Try renaming them and then create the symbolic links as per the VM, see
>>>>> here for more info:
>>>>>
>>>>> https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server#Make_domain_users.2Fgroups_available_locally_through_Winbind
>>>>>
>>>>> Rowland
>>>> No, I just created them before the wiki reported that on Debian like
>>>> distros, it was expected to have the links in /lib64, in /usr/lib and/or
>>>> in /usr/lib/x86_64-linux-gnu. I found that the application that was
>>>> failing was looking for the lib in /lib/x86... so instead of creating
>>>> the links to /usr/local/samba/lib/... that time I used as source the
>>>> link in /lib64 which was already a link to the correct lib. BTW now I
>>>> fixed the names but that didn't change anything.
>>> The problem is that the links need to go in different places based on
>>> what OS & versions you have, for instance I am typing this on a Linux
>>> Mint 17 laptop and this is where the links are:
>>>
>>> rowland at ThinkPad ~ $ locate libnss_winbind
>>> /lib/x86_64-linux-gnu/libnss_winbind.so
>>> /lib/x86_64-linux-gnu/libnss_winbind.so.2
>>>
>>> This is the same  on my Debian 7 backports DC
>>>
>>> The reference to /lib64 is meant for a RHEL based machine, so it is
>>> possible that you need to remake the links as above.
>>>
>>> Rowland
>>>
>>>
>>>> I'm stuck now and really don't know how to go on.
>>>> A brutal force action like removing the group and creating it again
>>>> seems a way but that means to change the ACLs on the root of the shares
>>>> and it takes long so I really hope there's another solution.
>>>>
>>>> Daniele.
>>>>
>> Hi samba-team, everybody
>> I'm still trying to understand why I'm getting the strange behavior
>> above.
>>
>> This morning I tried to stop the DC and remove everything from the
>> samba/private folder than re-join it to the domain.
>> Before join I just made a copy of idmap.ldb from the working DC to the
>> one to join.
>> Join went well, replication started and seems ok because an ldapcmp says
>> everything is good but:
>>
>> ldbsearch -H sam.ldb -a name="Ufficio\ Tecnico"
>> # record 1
>> dn: CN=Ufficio Tecnico,OU=groups,OU=saitel,DC=saitel,DC=loc
>> objectClass: top
>> objectClass: group
>> cn: Ufficio Tecnico
>> description: Personale Ufficio Tecnico
>> instanceType: 4
>> whenCreated: 20120924144535.0Z
>> uSNCreated: 3763
>> name: Ufficio Tecnico
>> objectGUID: 2e58f8d0-5a28-47c1-9468-ec7b202cf560
>> objectSid: S-1-5-21-1132727046-140625262-2935381992-1105
>> sAMAccountName: Ufficio Tecnico
>> sAMAccountType: 268435456
>> groupType: -2147483646
>> objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=saitel,DC=loc
>> gidNumber: 4000113
>> whenChanged: 20150423072617.0Z
>> member: ...
>> uSNChanged: 5367
>> distinguishedName: CN=Ufficio
>> Tecnico,OU=groups,OU=saitel,DC=saitel,DC=loc
>>
>> # Referral
>> ref: ldap://saitel.loc/CN=Configuration,DC=saitel,DC=loc
>>
>> # Referral
>> ref: ldap://saitel.loc/DC=DomainDnsZones,DC=saitel,DC=loc
>>
>> # Referral
>> ref: ldap://saitel.loc/DC=ForestDnsZones,DC=saitel,DC=loc
>>
>> # returned 4 records
>> # 1 entries
>> # 3 referrals
>>
>> So "Ufficio Tecnico" has gid 4000113 and sid
>> S-1-5-21-1132727046-140625262-2935381992-1105
>>
>> wbinfo -G 4000113
>> S-1-5-21-1132727046-140625262-2935381992-1105
>>
>> wbinfo -s S-1-5-21-1132727046-140625262-2935381992-1105
>> SAITEL\Ufficio Tecnico 2
>>
>> is correct but trying to get the reverse lookup
>>
>> wbinfo --group-info Ufficio\ Tecnico
>> ufficio tecnico:x:3000022:
>>
>> and
>>
>> wbinfo -G 3000022
>> S-1-5-21-1132727046-140625262-2935381992-1129
>>
>> lbdsearch -H sam.ldb -a
>> objectSid=S-1-5-21-1132727046-140625262-2935381992-1129
>> # record 1
>> dn: CN=UA01,OU=Computers,OU=saitel,DC=saitel,DC=loc
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalPerson
>> objectClass: user
>> objectClass: computer
>> cn: UA01
>> instanceType: 4
>> whenCreated: 20120925094429.0Z
>> whenChanged: 20150223125833.0Z
>> displayName: UA01$
>> uSNCreated: 3747
>> uSNChanged: 3747
>> name: UA01
>> objectGUID: ddbc89cb-68a2-492a-a7f9-6d2c38ebe5ac
>> userAccountControl: 4096
>> codePage: 0
>> countryCode: 0
>> pwdLastSet: 130691699130000000
>> primaryGroupID: 515
>> objectSid: S-1-5-21-1132727046-140625262-2935381992-1129
>> accountExpires: 9223372036854775807
>> sAMAccountName: UA01$
>> sAMAccountType: 805306369
>> operatingSystem: Windows XP Professional
>> operatingSystemVersion: 5.1 (2600)
>> operatingSystemServicePack: Service Pack 3
>> dNSHostName: ua01.saitel.loc
>> servicePrincipalName: HOST/ua01.saitel.loc
>> servicePrincipalName: HOST/UA01
>> objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=saitel,DC=loc
>> isCriticalSystemObject: FALSE
>> distinguishedName: CN=UA01,OU=Computers,OU=saitel,DC=saitel,DC=loc
>>
>> This is consistent with the other DC but I can't understand why on this
>> DC there is a swap between two sids. The result is that I cannot anymore
>> use the shares owned by the group "Ufficio Tecnico" because trying to
>> connect to the shares all people gets permission deny.
>>
>> Can anybody help me please?
> Sorry for the noise, I know you guys are hardworking on many tasks but I
> really need to understand what's happening or how to fix this problem.
> In Italian ufficio tecnico means R&D and I'm having problems with the
> network share where all R&D stuff is so ... please help!!!
>
> Daniele.
>

OK, somebody over on the samba mailing list is having what seems to be a 
similar problem with 4.2.1

Are you using the internal dns or bind 9 ?
If bind9, find the 'server services' line in smb.conf, change 'winbindd' 
to 'winbind', do this on both machines and then restart samba
If using the internal dns, you probably don't have the 'server services' 
line, so you will have to add it in this format 'server services 
-winbindd +winbind' , again restart samba.

Try 'getent group Ufficio\ Tecnico' on both machines and see if this 
cures your problem, you may have to run 'net cache flush' to clear out 
the winbind cache.

Rowland