[Samba] getent problems with new Samba version

Rowland Penny rpenny at samba.org
Tue Jan 31 13:40:35 UTC 2017

On Tue, 31 Jan 2017 05:25:43 -0500
Mark Foley via samba <samba at lists.samba.org> wrote:

> On Fri, 27 Jan 2017 14:37:33 +0000 Rowland Penny wrote:
> > > Also, I do find samba on the 14.2 DVD in
> > > slackware64/n/samba-4.4.4-x86_64-3.txz. See PACKAGES.TXT at the
> > > root of the same DVD.
> >
> > See, you knew where to look (I was looking for a dir that started
> > with 's'), however the .txz file does contain a 'doinstall.sh' file.
> Well, that ends up being a bit obscure for me.  I don't normally look
> for or examine the doinstall.sh scripts for all packages I'm
> upgrading.  They should have put that fairly critical info in their
> UPGRADE.TXT document. I may email them about this, esp. given that
> the /var/lib/samba/private directory is referenced by named.conf.
> Likely the doinstall.sh script was not put together by someone who'd
> actually used Samaba4 as AD/DC.

If you are emailing them, you might like to point out that they should
stop Samba before copying or moving the files.

> > > How did my domain users get in idmap.ldb in the first place? If
> > > ADUC put them there when I created the account, why did ADUC not
> > > put user 'shay' in there?
> >
> > ADUC doesn't add users and groups to idmap.ldb, Samba does and it
> > only does this if the user doesn't have a uidNumber attribute.
> So, when I first provisioned Samba, I certainly did not assign
> UID:GIDs for any users.  I did not do that explicitly until after our
> email exchange on this list back in October, 2015 whereupon I changed
> the UID in sam.ldb via ldbedit.  Give what you said, that would
> explain how the old 30000xx UIDs got in idmap.ldb.  For users added
> after that time I did explicitly give a GID:UID in ADUC, which
> explains why a) they are not in idmap.ldb and b) they had no problem
> after the upgrade. 
> When I manually changed the UIDs in sam.ldb, I should have also
> changed the corresponding GID and UIDs in idmap.ldb, right?

No, not really, if a user is given a uidNumber, this will be used on
a DC instead of the xidNumber in idmap.ldb and the xidNumber is only
created when the user first contacts the DC and doesn't have a
uidNumber. The same goes for groups.

> > > Given the above, is idmap.ldb necessary? Seems redundant with the
> > > information in sam.ldb and apparently overrides sam.ldb when
> > > settings conflict.
> >
> > idmap.ldb is most definitely required, it is where the well known
> > SIDs get mapped and any others that don't have a
> > uidNumber/gidNumber. 
> > > 
> > > In the meantime, I think my problem might be solved given the
> > > results of this last experiment to change user 'mark's xidNumber
> > > in imap.ldb.
> > > 
> >
> > Well it will work but it is a workaround not a fix, if this was
> > debian I would be advising you to check the libnss_winbind links,
> > but as I don't know if slackware uses them ???
> > Also does slackware use /etc/nsswitch.conf ??
> Hmmm, so you don't buy my theory that in the absence of
> winbindd_cache.tdb, Samba will first look in idmap.ldb? I did, after
> all, manually change sam.ldb, which was an intervention on my part
> that perhaps wasn't complete (neglecting to make the corresponding
> change in idmap.ldb).
> I'm not sure I buy my theory either since these GID:UID changes
> worked initially when I made them in 2015, with idmap.ldb still
> having the old GID and UIDs, and not doubt the cache still having the
> old GID:UIDs as well.

Not entirely sure just how winbindd works internally, but
winbind_cache.tdb is what it sounds like, a cache that is rewritten
when winbindd is restarted. changing the contents of an xidNumber
attribute will work, but if a uidNumber exists, this should be used
instead, if this isn't working and winbind_cache.tdb doesn't exist,
then this needs investigating (add 'log level = 10' to smb.conf, then
restart samba). If the cache does exist, run 'net cache flush', this
should clear the cache.


More information about the samba mailing list