[Samba] winbindd losing track of RFC2307 UIDs

[Rob]

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.