gid numbers changed after upgrading from 4.1.14 to 4.2.1

Thu Apr 23 05:03:42 MDT 2015

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?