gid numbers changed after upgrading from 4.1.14 to 4.2.1
Daniele Dario
d.dario76 at gmail.com
Wed Apr 22 05:55:44 MDT 2015
On mer, 2015-04-22 at 13:12 +0200, Daniele Dario wrote:
>
> 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.
Just to add some (strange) info.
I just run samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
and after that, also from kdc01 "ufficio tecnico" changed its gid to the
one in idmap.ldb
Now, looking on kdc01, my account appears as
[root at kdc01:/usr/local/samba/private]# id daniele
uid=4001101(daniele) gid=4000001(domain users) groups=4000001(domain
users),4000112(ufficio produzione),3000022(ufficio
tecnico),4000114(saitel
staff),4000107(remote_users),4000102(collaudi),4000105(officina),3000001(BUILTIN\users)
note that the only one group with a different gid is "ufficio tecnico"
in kdc03 I see this
[root at kdc03:/usr/local/samba/private]# id daniele
uid=4001101(daniele) gid=100(users)
groups=100(users),4000105(officina),4000102(collaudi),4000107(remote_users),4000112(ufficio produzione),3000022(ufficio tecnico),3000010(enterprise admins),3000008(denied rodc password replication group),3000011(domain admins),4000114(saitel staff),3000008(denied rodc password replication group),3000001(BUILTIN\users),3000000(BUILTIN\administrators)
Note that here gid is 100 instead of 4000001 and it seems that I'm still
in the domain admins and enterprise admins groups while I removed myself
from them yesterday as AD states below
[root at kdc03:/usr/local/samba/private]# ldbsearch -H sam.ldb -a
name=Daniele\ Dario
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
# record 1
dn: CN=Daniele Dario,OU=users,OU=saitel,DC=saitel,DC=loc
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Daniele Dario
sn: Dario
description: System Engineer
physicalDeliveryOfficeName: Technical Department
telephoneNumber: +39 339 4471060
givenName: Daniele
initials: DD
instanceType: 4
whenCreated: 20120924144348.0Z
displayName: Daniele Dario
uSNCreated: 3484
name: Daniele Dario
objectGUID: 7f5d98bd-e399-4620-9a13-78d1cd37fc7d
userAccountControl: 66048
codePage: 0
countryCode: 0
pwdLastSet: 129929714290000000
primaryGroupID: 513
objectSid: S-1-5-21-1132727046-140625262-2935381992-1104
accountExpires: 9223372036854775807
sAMAccountName: daniele
sAMAccountType: 805306368
userPrincipalName: daniele at saitel.loc
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=saitel,DC=loc
mail: daniele.dario at saitelitalia.com
unixHomeDirectory: /home/SAITEL/daniele
loginShell: /bin/bash
memberOf: CN=Officina,OU=groups,OU=saitel,DC=saitel,DC=loc
memberOf: CN=remote_users,OU=groups,OU=saitel,DC=saitel,DC=loc
memberOf: CN=Ufficio Produzione,OU=groups,OU=saitel,DC=saitel,DC=loc
memberOf: CN=Ufficio Tecnico,OU=groups,OU=saitel,DC=saitel,DC=loc
memberOf: CN=Collaudi,OU=groups,OU=saitel,DC=saitel,DC=loc
memberOf: CN=Saitel Staff,OU=groups,OU=saitel,DC=saitel,DC=loc
uidNumber: 4001101
whenChanged: 20140515073926.0Z
uSNChanged: 7509
gidNumber: 4000001
distinguishedName: CN=Daniele Dario,OU=users,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
Please help me,
Daniele.
More information about the samba-technical
mailing list