Hi all,
I've been experiencing an intermittent problem where some UIDs on a member
server spontaneously change from being their AD-derived values to being
allocated from the default idmap space, even when there is no change to the AD
user information.
Specifically, I have a member server running Samba 4.4.5 on CentOS 6.8.
AD service is provided by two Samba 4.4.5 servers.
The member server's smb.conf has (in part):
[global]
netbios name = memberserver
security = ADS
workgroup = MYDOMAIN
realm = MY.AD.REALM.COM
server role = member server
interfaces = em1 127.0.0.1
bind interfaces only = yes
idmap config *:backend = tdb
idmap config *:range = 2000-9999
# idmap config for domain
idmap config MY.AD.REALM.COM:backend = ad
idmap config MY.AD.REALM.COM:schema_mode = rfc2307
idmap config MY.AD.REALM.COM:range = 10000-99999
# Use template settings for login shell and home directory
winbind nss info = template
template shell = /bin/bash
template homedir = /home/%U
winbind use default domain = yes
[...]
This generally works fine... user mappings are like:
$ wbinfo -i auser
auser:*:10028:10000:User Name:/home/auser:/bin/bash
$ id auser
uid=10028(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup)
After a while (generally a couple days, though sometimes much sooner), this
starts happening:
$ wbinfo -i auser
auser:*:2018:10000:User Name:/home/auser:/bin/bash
$ id auser
uid=2018(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup)
and this persists until I do "net cache flush" on the member!
Any thoughts on why the winbindd cache is getting corrupted? I tried running
winbindd with log level 7, but nothing jumped out at me: just normal queries
returning 10028 and then normal queries returning 2018. Other suggestions to
try?
Thanks!
-Rob
PS. At one point in the past, this member server was also a DC and this problem
never happened then.
On Mon, 3 Oct 2016 12:57:54 -0400 (EDT) Rob via samba <samba at lists.samba.org> wrote:> Hi all, > > I've been experiencing an intermittent problem where some UIDs on a > member server spontaneously change from being their AD-derived values > to being allocated from the default idmap space, even when there is > no change to the AD user information. > > Specifically, I have a member server running Samba 4.4.5 on CentOS > 6.8. AD service is provided by two Samba 4.4.5 servers. > > The member server's smb.conf has (in part): > > [global] > netbios name = memberserver > security = ADS > workgroup = MYDOMAIN > realm = MY.AD.REALM.COM > server role = member server > > interfaces = em1 127.0.0.1 > bind interfaces only = yes > > idmap config *:backend = tdb > idmap config *:range = 2000-9999 > > # idmap config for domain > idmap config MY.AD.REALM.COM:backend = ad > idmap config MY.AD.REALM.COM:schema_mode = rfc2307 > idmap config MY.AD.REALM.COM:range = 10000-99999 > > # Use template settings for login shell and home directory > winbind nss info = template > template shell = /bin/bash > template homedir = /home/%U > > winbind use default domain = yes > [...] > > This generally works fine... user mappings are like:You might think it works fine, but it will probably work better if you change 'idmap config MY.AD REALM.COM' to 'idmap config MYDOMAIN' The 'ad' backend should start working properly then. Rowland> > $ wbinfo -i auser > auser:*:10028:10000:User Name:/home/auser:/bin/bash > $ id auser > uid=10028(auser) gid=10000(agroup) > groups=10000(agroup),10007(othergroup) > > After a while (generally a couple days, though sometimes much > sooner), this starts happening: > > $ wbinfo -i auser > auser:*:2018:10000:User Name:/home/auser:/bin/bash > $ id auser > uid=2018(auser) gid=10000(agroup) > groups=10000(agroup),10007(othergroup) > > and this persists until I do "net cache flush" on the member! > > Any thoughts on why the winbindd cache is getting corrupted? I tried > running winbindd with log level 7, but nothing jumped out at me: just > normal queries returning 10028 and then normal queries returning > 2018. Other suggestions to try? > > Thanks! > -Rob > > PS. At one point in the past, this member server was also a DC and > this problem never happened then. >
Sounds possibly related to an issue I had previously (although mine was the other way round - it didn't work reliably when the machine was a DC; but has been better since I commissioned a separate DC). I had mappings working fine for ages, then all of a sudden they would jump back and I would have to run "net cache flush". Unfortunately I never got it resolved, I just worked around it.. The (long!) thread from my previous issue is here, if it's of any use: https://lists.samba.org/archive/samba/2015-November/195639.html On 3 October 2016 at 17:57, Rob via samba <samba at lists.samba.org> wrote:> Hi all, > > I've been experiencing an intermittent problem where some UIDs on a member > server spontaneously change from being their AD-derived values to being > allocated from the default idmap space, even when there is no change to the > AD user information. > > Specifically, I have a member server running Samba 4.4.5 on CentOS 6.8. > AD service is provided by two Samba 4.4.5 servers. > > The member server's smb.conf has (in part): > > [global] > netbios name = memberserver > security = ADS > workgroup = MYDOMAIN > realm = MY.AD.REALM.COM > server role = member server > > interfaces = em1 127.0.0.1 > bind interfaces only = yes > > idmap config *:backend = tdb > idmap config *:range = 2000-9999 > > # idmap config for domain > idmap config MY.AD.REALM.COM:backend = ad > idmap config MY.AD.REALM.COM:schema_mode = rfc2307 > idmap config MY.AD.REALM.COM:range = 10000-99999 > > # Use template settings for login shell and home directory > winbind nss info = template > template shell = /bin/bash > template homedir = /home/%U > > winbind use default domain = yes > [...] > > This generally works fine... user mappings are like: > > $ wbinfo -i auser > auser:*:10028:10000:User Name:/home/auser:/bin/bash > $ id auser > uid=10028(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup) > > After a while (generally a couple days, though sometimes much sooner), this > starts happening: > > $ wbinfo -i auser > auser:*:2018:10000:User Name:/home/auser:/bin/bash > $ id auser > uid=2018(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup) > > and this persists until I do "net cache flush" on the member! > > Any thoughts on why the winbindd cache is getting corrupted? I tried > running winbindd with log level 7, but nothing jumped out at me: just normal > queries returning 10028 and then normal queries returning 2018. Other > suggestions to try? > > Thanks! > -Rob > > PS. At one point in the past, this member server was also a DC and this > problem never happened then. > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba-- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein
Am 03.10.2016 um 18:57 schrieb Rob via samba:> Hi all, > > I've been experiencing an intermittent problem where some UIDs on a > member server spontaneously change from being their AD-derived values > to being allocated from the default idmap space, even when there is no > change to the AD user information. > > Specifically, I have a member server running Samba 4.4.5 on CentOS 6.8. > AD service is provided by two Samba 4.4.5 servers. > > The member server's smb.conf has (in part): > > [global] > netbios name = memberserver > security = ADS > workgroup = MYDOMAIN > realm = MY.AD.REALM.COM > server role = member server > > interfaces = em1 127.0.0.1 > bind interfaces only = yes > > idmap config *:backend = tdb > idmap config *:range = 2000-9999 > > # idmap config for domain > idmap config MY.AD.REALM.COM:backend = ad > idmap config MY.AD.REALM.COM:schema_mode = rfc2307 > idmap config MY.AD.REALM.COM:range = 10000-99999 > > # Use template settings for login shell and home directory > winbind nss info = template > template shell = /bin/bash > template homedir = /home/%U > > winbind use default domain = yes > [...] > > This generally works fine... user mappings are like: > > $ wbinfo -i auser > auser:*:10028:10000:User Name:/home/auser:/bin/bash > $ id auser > uid=10028(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup) > > After a while (generally a couple days, though sometimes much sooner), > this starts happening: > > $ wbinfo -i auser > auser:*:2018:10000:User Name:/home/auser:/bin/bash > $ id auser > uid=2018(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup) > > and this persists until I do "net cache flush" on the member! > > Any thoughts on why the winbindd cache is getting corrupted? I tried > running winbindd with log level 7, but nothing jumped out at me: just > normal queries returning 10028 and then normal queries returning 2018. > Other suggestions to try? > > Thanks! > -Rob > > PS. At one point in the past, this member server was also a DC and > this problem never happened then. >Been having this issue on an dc after i updated from 4.1 to 4.2. It turned out some users with defined uid also had mappings from winbind in idmap.tdb. At firt the uid attributre gets used but afetr a while the value fromidmap.tdb was used. The fix was to delete the mappings in idmap.tdb. On an member server you can use net idmap set/get/dump to test this.
On Tue, 4 Oct 2016 02:35:21 +0200 Achim Gottinger via samba <samba at lists.samba.org> wrote:> > > Am 03.10.2016 um 18:57 schrieb Rob via samba: > > Hi all, > > > > I've been experiencing an intermittent problem where some UIDs on a > > member server spontaneously change from being their AD-derived > > values to being allocated from the default idmap space, even when > > there is no change to the AD user information. > > > > Specifically, I have a member server running Samba 4.4.5 on CentOS > > 6.8. AD service is provided by two Samba 4.4.5 servers. > > > > The member server's smb.conf has (in part): > > > > [global] > > netbios name = memberserver > > security = ADS > > workgroup = MYDOMAIN > > realm = MY.AD.REALM.COM > > server role = member server > > > > interfaces = em1 127.0.0.1 > > bind interfaces only = yes > > > > idmap config *:backend = tdb > > idmap config *:range = 2000-9999 > > > > # idmap config for domain > > idmap config MY.AD.REALM.COM:backend = ad > > idmap config MY.AD.REALM.COM:schema_mode = rfc2307 > > idmap config MY.AD.REALM.COM:range = 10000-99999 > > > > # Use template settings for login shell and home directory > > winbind nss info = template > > template shell = /bin/bash > > template homedir = /home/%U > > > > winbind use default domain = yes > > [...] > > > > This generally works fine... user mappings are like: > > > > $ wbinfo -i auser > > auser:*:10028:10000:User Name:/home/auser:/bin/bash > > $ id auser > > uid=10028(auser) gid=10000(agroup) > > groups=10000(agroup),10007(othergroup) > > > > After a while (generally a couple days, though sometimes much > > sooner), this starts happening: > > > > $ wbinfo -i auser > > auser:*:2018:10000:User Name:/home/auser:/bin/bash > > $ id auser > > uid=2018(auser) gid=10000(agroup) > > groups=10000(agroup),10007(othergroup) > > > > and this persists until I do "net cache flush" on the member! > > > > Any thoughts on why the winbindd cache is getting corrupted? I > > tried running winbindd with log level 7, but nothing jumped out at > > me: just normal queries returning 10028 and then normal queries > > returning 2018. Other suggestions to try? > > > > Thanks! > > -Rob > > > > PS. At one point in the past, this member server was also a DC and > > this problem never happened then. > > > Been having this issue on an dc after i updated from 4.1 to 4.2. It > turned out some users with defined uid also had mappings from winbind > in idmap.tdb. At firt the uid attributre gets used but afetr a while > the value fromidmap.tdb was used. The fix was to delete the mappings > in idmap.tdb. > On an member server you can use net idmap set/get/dump to test this. >You are missing the fact that the OP is using the REALM name instead of the NETBios domain name and for some reason winbind is starting to allocate the user a UID from the '*' range. Rowland
On Mon, 3 Oct 2016, Rowland Penny wrote:> On Mon, 3 Oct 2016, Rob wrote: >> # idmap config for domain >> idmap config MY.AD.REALM.COM:backend = ad >> idmap config MY.AD.REALM.COM:schema_mode = rfc2307 >> idmap config MY.AD.REALM.COM:range = 10000-99999[...]> > You might think it works fine, but it will probably work better if you > change 'idmap config MY.AD REALM.COM' to 'idmap config MYDOMAIN' > The 'ad' backend should start working properly then.Thanks Rowland, that works! Figured it was something simple. I'm actually surprised that the realm version worked at all then. -Rob
On Tue, 4 Oct 2016, Achim Gottinger wrote:> Am 03.10.2016 um 18:57 schrieb Rob via samba: >> [...] >> >> This generally works fine... user mappings are like: >> >> $ wbinfo -i auser >> auser:*:10028:10000:User Name:/home/auser:/bin/bash >> $ id auser >> uid=10028(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup) >> >> After a while (generally a couple days, though sometimes much sooner), this >> starts happening: >> >> $ wbinfo -i auser >> auser:*:2018:10000:User Name:/home/auser:/bin/bash >> $ id auser >> uid=2018(auser) gid=10000(agroup) groups=10000(agroup),10007(othergroup) >> > Been having this issue on an dc after i updated from 4.1 to 4.2. It turned > out some users with defined uid also had mappings from winbind in idmap.tdb. > At firt the uid attributre gets used but afetr a while the value > fromidmap.tdb was used. The fix was to delete the mappings in idmap.tdb. > On an member server you can use net idmap set/get/dump to test this.As the problem was getting worse and worse on my end (UIDs resetting after a few minutes, mostly in response to SMB traffic), I did something similar: - stop Samba on the member - remove the idmap tables completely - restart Samba on the member After a week of running, this seems to be working without issue! My guess (without looking at the code) is that one of the smbd processes had a record of a UID=20xx user, and did reverse lookup to find the SID, and somehow that led winbindd to always use the idmap.tdb info instead of querying AD for that SID. _Rob