gid numbers changed after upgrading from 4.1.14 to 4.2.1

Thu Apr 23 09:43:06 MDT 2015

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.