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
Am 21.10.2016 um 18:40 schrieb Rob via samba:> 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 > >Thank you for the update. By getting worse do you mean other users also got affected?
On Sat, 22 Oct 2016, Achim Gottinger wrote:> Am 21.10.2016 um 18:40 schrieb Rob via samba: >> >> 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 >> >> > Thank you for the update. By getting worse do you mean other users also got > affected? >Same set of users, but the frequency of the problem was worse. (Seemingly arbitrary SMB interactions would make the user's UID reset in a couple minutes after a "net cache flush".) _Rob