[Samba] getent problems with new Samba version

[Mark Foley]

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.

> > 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?

> > 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.

In any case, I'm hoping that syncing the GID, UIDs between sam.ldb and idmap.ldb *does* fix my
problem. I guess only time will tell.

Slackware definitely uses /etc/nsswitch.conf.

Here is my libnss_winbind link:

$ smbd -b | grep LIBDIR
LIBDIR: /usr/lib64

$ find / -mount -name libnss_winbind.so\* -exec ls -l \{\} \;
-rwxr-xr-x 1 root root 18208 Dec 28 14:25 /usr/lib64/libnss_winbind.so.2
lrwxrwxrwx 1 root root 19 Jan 14 15:45 /usr/lib64/libnss_winbind.so -> libnss_winbind.so.2
   
Looks OK to me. Agree?

--Mark