On Tue, 4 Oct 2016 12:29:19 -0400 (EDT) Rob via samba <samba at lists.samba.org> wrote:> > On Tue, 4 Oct 2016, Rob wrote: > > > 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. > > Spoke too soon... I just checked and auser has a 20xx UID again. It > was fine for a bit but no longer. > > $ wbinfo -i auser > auser:*:2018:10000:User Name:/home/auser:/bin/bash > > Oddly, this seems to only affect ~3 of my 20 users and the same ~3 > every time. > > _Rob > >This is very strange, have you tried running 'net cache flush' on the domain member ? Have you compared the users AD objects ? Rowland
On Tue, 4 Oct 2016, Rowland Penny wrote:> This is very strange, have you tried running 'net cache flush' on the > domain member ? > > Have you compared the users AD objects ?Running 'net cache flush' on the member does fix things, albeit only for a while: # wbinfo -i auser auser:*:2020:10000:User Name:/home/auser:/bin/bash # net cache flush # wbinfo -i auser auser:*:10028:10000:User Name:/home/auser:/bin/bash [...wait a few hours...] # wbinfo -i auser auser:*:2020:10000:User Name:/home/auser:/bin/bash Using ldbsearch on sam.ldb on the DC, I compared the attributes of problematic users and normal users... I couldn't find anything obvious distinguishing them. Also, on the member: # net idmap dump dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb [...] UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177 (where S-*-1177 is the SID for auser) But I'd think winbindd would prefer the mapping in AD, given smb.conf having our domain listed explicitly and 2xxx only as a default/fallback. Or maybe I misunderstand how the idmaps work... does the order in smb.conf matter at all? _Rob
Am 05.10.2016 um 22:12 schrieb Rob via samba:> On Tue, 4 Oct 2016, Rowland Penny wrote: > >> This is very strange, have you tried running 'net cache flush' on the >> domain member ? >> >> Have you compared the users AD objects ? > > Running 'net cache flush' on the member does fix things, albeit only > for a while: > > # wbinfo -i auser > auser:*:2020:10000:User Name:/home/auser:/bin/bash > # net cache flush > # wbinfo -i auser > auser:*:10028:10000:User Name:/home/auser:/bin/bash > [...wait a few hours...] > # wbinfo -i auser > auser:*:2020:10000:User Name:/home/auser:/bin/bash > > Using ldbsearch on sam.ldb on the DC, I compared the attributes of > problematic users and normal users... I couldn't find anything obvious > distinguishing them. > > Also, on the member: > > # net idmap dump > dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb > [...] > UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177 > > (where S-*-1177 is the SID for auser) > > But I'd think winbindd would prefer the mapping in AD, given smb.conf > having our domain listed explicitly and 2xxx only as a > default/fallback. Or maybe I misunderstand how the idmaps work... does > the order in smb.conf matter at all? > > _Rob > >Hi Rob, You can try to use tdbtool to delete the offending key with uid 2020. https://www.samba.org/samba/docs/man/manpages-3/tdbtool.8.html I'd stop samba make an backup of winbind_idmap.tdb and give it a try. In my case deleting the mappings from idamp.tdb fixed the issue of changing uid's. achim~
On Wed, 5 Oct 2016 16:12:41 -0400 (EDT) Rob via samba <samba at lists.samba.org> wrote:> On Tue, 4 Oct 2016, Rowland Penny wrote: > > > This is very strange, have you tried running 'net cache flush' on > > the domain member ? > > > > Have you compared the users AD objects ? > > Running 'net cache flush' on the member does fix things, albeit only > for a while: > > # wbinfo -i auser > auser:*:2020:10000:User Name:/home/auser:/bin/bash > # net cache flush > # wbinfo -i auser > auser:*:10028:10000:User Name:/home/auser:/bin/bash > [...wait a few hours...] > # wbinfo -i auser > auser:*:2020:10000:User Name:/home/auser:/bin/bash > > Using ldbsearch on sam.ldb on the DC, I compared the attributes of > problematic users and normal users... I couldn't find anything > obvious distinguishing them. > > Also, on the member: > > # net idmap dump > dumping id mapping from /usr/local/samba/var/locks/winbindd_idmap.tdb > [...] > UID 2020 S-1-5-21-2701825980-1665447529-2160704981-1177 > > (where S-*-1177 is the SID for auser) > > But I'd think winbindd would prefer the mapping in AD, given smb.conf > having our domain listed explicitly and 2xxx only as a > default/fallback. Or maybe I misunderstand how the idmaps work... > does the order in smb.conf matter at all? > > _Rob > >OK, this is basically how the winbind 'ad' works: Domain Users is checked for a gidNumber attribute and if found winbind continues, if not found, the '*' range will be used. Once pass this point, any user that has a uidNumber attribute that contains a number inside the 'idmap config DOMAIN' range will be displayed by 'getent passwd username' once a user is displayed in this way, it should always be displayed in this way, it shouldn't get an ID from the '*' range. Could the '...wait a few hours...' be about 10 hours ?? Try adding these lines to smb.conf: dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab winbind refresh tickets = Yes Leave the domain and rejoin, this should create the /etc/krb5.keytab Rowland