gid numbers changed after upgrading from 4.1.14 to 4.2.1

Daniele Dario d.dario76 at gmail.com
Wed Apr 22 05:12:08 MDT 2015



On mer, 2015-04-22 at 11:45 +0100, Rowland Penny wrote:
> On 22/04/15 11:11, Daniele Dario wrote:
> >
> > On mer, 2015-04-22 at 09:57 +0100, Rowland Penny wrote:
> >> On 22/04/15 09:29, Daniele Dario wrote:
> >>> Good morning everybody,
> >>> yesterday I completed the upgrade of my two DCs to 4.2.1 but after doing
> >>> that I noticed that the gid of some groups changed on one of the two
> >>> DCs.
> >>>
> >>> The problem is that the DC on which the gid numbers changed acts also as
> >>> a file server and now some users can't anymore connect to some shares.
> >>>
> >>> Replication seems to work correctly but I used samba-tool ldapcmp to see
> >>> if everything is right and found that
> >>>
> >>> [root at kdc03:/usr/local/samba/private]# samba-tool ldapcmp sam.ldb
> >>> ldap://kdc01 -Uadministrator
> >>> Password for [SAITEL\administrator]:
> >>>
> >>> * Comparing [DOMAIN] context...
> >>>
> >>> * Objects to be compared: 563
> >>>
> >>> Comparing:
> >>> 'CN=Administrators,CN=Builtin,DC=saitel,DC=loc' [sam.ldb]
> >>> 'CN=Administrators,CN=Builtin,DC=saitel,DC=loc' [ldap://kdc01]
> >>>       Difference in attribute values:
> >>>           whenChanged =>
> >>> ['20150421175958.0Z']
> >>> ['20150421180002.0Z']
> >>>       FAILED
> >> you can ignore the 'whenChanged' attribute, it is not replicated, so
> >> could be different.
> >>
> >>>
> >>> Looking at the gid numbers that I found changed I see this:
> >>> group ufficio tecnico:
> >>>        kdc01   kdc03
> >>> gid 4000113 3000022
> >>> on both kdc01 and kdc03 I get that
> >>>
> >>> [root at kdc03:/usr/local/samba/private]# wbinfo -G 3000022
> >>> S-1-5-21-1132727046-140625262-2935381992-1105
> >>> [root at kdc03:/usr/local/samba/private]# wbinfo -G 4000113
> >>> S-1-5-21-1132727046-140625262-2935381992-1105
> >> Do both DCs have 'idmap_ldb:use rfc2307 = yes' in smb.conf ?
> >>
> >>> so it seems that I have two gidNumber that map on the same sid
> >>> and looking into idmap.ldb I get
> >>>
> >>> [root at kdc03:/usr/local/samba/private]# ldbsearch -H idmap.ldb -a
> >>> objectSid=S-1-5-21-1132727046-140625262-2935381992-1105
> >>> # record 1
> >>> dn: CN=S-1-5-21-1132727046-140625262-2935381992-1105
> >>> cn: S-1-5-21-1132727046-140625262-2935381992-1105
> >>> objectClass: sidMap
> >>> objectSid: S-1-5-21-1132727046-140625262-2935381992-1105
> >>> type: ID_TYPE_BOTH
> >>> xidNumber: 3000022
> >>> distinguishedName: CN=S-1-5-21-1132727046-140625262-2935381992-1105
> >>>
> >>> # returned 1 records
> >>> # 1 entries
> >>> # 0 referrals
> >>>
> >>> while on sam.ldb I find
> >>>
> >>> [root at kdc03:/usr/local/samba/private]# ldbsearch -H sam.ldb -a
> >>> objectSid=S-1-5-21-1132727046-140625262-2935381992-1105
> >>> # 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: 3592
> >>> 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
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> member: CN=...,OU=users,OU=saitel,DC=saitel,DC=loc
> >>> whenChanged: 20140516075814.0Z
> >>> uSNChanged: 7616
> >>> distinguishedName: CN=Ufficio
> >>> Tecnico,OU=groups,OU=saitel,DC=saitel,DC=loc
> >>>
> >> If you run the same commands on the other DC, do you get the same results ?
> >> It should be the same for sam.ldb, but may be different for idmap.ldb,
> >> this is a know problem, as it is not replicated between DCs.
> >>
> >> Rowland
> >>> Is this a normal behavior or is this related to the problem I'm having
> >>> now in connecting to the shares "owned" by the group "ufficio tecnico"?
> >>>
> >>> Any help would be appreciated,
> >>> Daniele.
> >>>
> > Hi Rowland,
> > yes, both DCs have 'idmap_ldb:use rfc2307 = yes' in smb.conf and
> > ldapsearch gives the same results on the other DC.
> >
> > What seems to happen is that on kdc03 the lookup comes from idmap
> > instead than from AD but only for some groups.
> >
> > An example: Domain Users has his own entry in AD both in kdc01 and kdc03
> >
> > [root at kdc01:/usr/local/samba]# ldbsearch -H private/sam.ldb -a
> > name=Domain\ Users
> > # record 1
> > dn: CN=Domain Users,CN=Users,DC=saitel,DC=loc
> > cn: Domain Users
> > description: All domain users
> > instanceType: 4
> > whenCreated: 20120924143100.0Z
> > uSNCreated: 3223
> > name: Domain Users
> > objectGUID: d40e9068-18cf-4524-9f94-3cf5a63a030a
> > objectSid: S-1-5-21-1132727046-140625262-2935381992-513
> > sAMAccountName: Domain Users
> > sAMAccountType: 268435456
> > groupType: -2147483646
> > objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=saitel,DC=loc
> > isCriticalSystemObject: TRUE
> > memberOf: CN=Users,CN=Builtin,DC=saitel,DC=loc
> > objectClass: top
> > objectClass: group
> > gidNumber: 4000001
> > whenChanged: 20140515073926.0Z
> > uSNChanged: 13534
> > distinguishedName: CN=Domain Users,CN=Users,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
> >
> > [root at kdc03:/usr/local/samba/private]# ldbsearch -H sam.ldb -a
> > name=Domain\ Users
> > # record 1
> > dn: CN=Domain Users,CN=Users,DC=saitel,DC=loc
> > objectClass: top
> > objectClass: group
> > cn: Domain Users
> > description: All domain users
> > instanceType: 4
> > whenCreated: 20120924143100.0Z
> > uSNCreated: 3227
> > name: Domain Users
> > objectGUID: d40e9068-18cf-4524-9f94-3cf5a63a030a
> > objectSid: S-1-5-21-1132727046-140625262-2935381992-513
> > sAMAccountName: Domain Users
> > sAMAccountType: 268435456
> > groupType: -2147483646
> > objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=saitel,DC=loc
> > isCriticalSystemObject: TRUE
> > memberOf: CN=Users,CN=Builtin,DC=saitel,DC=loc
> > whenChanged: 20140515073926.0Z
> > uSNChanged: 7511
> > gidNumber: 4000001
> > distinguishedName: CN=Domain Users,CN=Users,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
> >
> > and lookup of SID in idmap.ldb has entries on both DCs
> >
> > [root at kdc01:/usr/local/samba]# ldbsearch -H private/idmap.ldb -a
> > objectSid=S-1-5-21-1132727046-140625262-2935381992-513
> > # record 1
> > dn: CN=S-1-5-21-1132727046-140625262-2935381992-513
> > cn: S-1-5-21-1132727046-140625262-2935381992-513
> > objectClass: sidMap
> > objectSid: S-1-5-21-1132727046-140625262-2935381992-513
> > type: ID_TYPE_GID
> > xidNumber: 100
> > distinguishedName: CN=S-1-5-21-1132727046-140625262-2935381992-513
> >
> > # returned 1 records
> > # 1 entries
> > # 0 referrals
> >
> > [root at kdc03:/usr/local/samba/private]# ldbsearch -H idmap.ldb -a
> > objectSid=S-1-5-21-1132727046-140625262-2935381992-513
> > # record 1
> > dn: CN=S-1-5-21-1132727046-140625262-2935381992-513
> > cn: S-1-5-21-1132727046-140625262-2935381992-513
> > objectClass: sidMap
> > objectSid: S-1-5-21-1132727046-140625262-2935381992-513
> > type: ID_TYPE_GID
> > xidNumber: 100
> > distinguishedName: CN=S-1-5-21-1132727046-140625262-2935381992-513
> >
> > # returned 1 records
> > # 1 entries
> > # 0 referrals
> >
> > but as you can see, on kdc01 and kdc03 they appear different
> >
> > [root at kdc01:/usr/local/samba]# getent group Domain\ Users
> > domain users:x:4000001:
> >
> > [root at kdc03:/usr/local/samba/private]# getent group Domain\ Users
> > domain users:x:100:
> >
> > On other groups I see that SIDs are present both on AD and idmap.ldb but
> > on both DCs they are resolved as per AD content and not per idmap.ldb
> > and it seems that the problem in accessing the shares is that when
> > trying to connect the share samba uses AD while disk permissions appear
> > to be retrieved from idmap (or vice-versa).
> >
> > Any idea?
> > Daniele.
> >
> 
> Strange, running 'getent group Domain\ Users' on both my DCs gives the 
> same result '10000', which is the gidNumber set in AD.
> 
> Is /etc/nsswitch.conf the same on both DCs ?
> Have you set up the libnss_winbind links ?
> If so, have you done this on both machines ?
> 
> Have you altered smb.conf on either of the DCs ?
> 
> How was the domain initially provisioned ?
> 
> Rowland
> 

/etc/nsswitch.conf looks the same on both DCs

[root at kdc03:/usr/local/samba/private]# cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed,
try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

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*

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*

I didn't alter smb.conf and running diff on samba-tool testparm -v
--suppress-prompt I see nothing relevant

diff /tmp/testparm /tmp/testparm.kdc01 
7c7
< 	netbios name = KDC03
---
> 	netbios name = KDC01
124c124
< 	load printers = Yes
---
> 	load printers = No
126c126
< 	printcap name = /var/run/cups/printcap
---
> 	printcap name = 
289,290d288
< 	rpc_daemon:spoolssd = fork
< 	rpc_server:spoolss = external
353c351
< 	printing = cups
---
> 	printing = bsd

Domain was provisioned on kdc01 a couple of years ago with a 4.0 (can't
recall if still on an alpha or already with the 4.0.1) than updated and
upgraded to 4.1.

I always told myself that I had to demote kdc03 to a member server but
whenever I tried to set up another member server to start migration I
always found some troubles so ... still here.

Said that, I didn't have any problem before upgrading to 4.2.

How does samba decide where to get info about an account between idmap
and AD? It's strange that the other groups stored in AD (which SID is
also in idmap but with a xidNumber different from the gidNumber in AD)
are retrieved correctly from AD.
>From what I understand idmap_ldb:use rfc2307 = yes should tell samba to
pick up info of that SID from AD even if there's an entry in idmap, am I
right?

Daniele.



More information about the samba-technical mailing list