[Samba] idmap & migration to rfc2307

[Jonathan Hunter]

On 7 November 2015 at 10:11, Rowland Penny <rowlandpenny241155 at gmail.com> wrote:
>
> Is it possible that sssd is failing?
> What do you have in /etc/nsswitch?

# cat /etc/nsswitch.conf | egrep "(passwd|group)"
passwd:     files sss
group:      files sss

But I don't think this is anything to do with sssd. As I understand it:

Local machine UNIX use (i.e. logging in via ssh; looking at files on
disk via "ls"; etc.) uses sssd, because this is what I have set in
nsswitch.conf. This all works fine, I have no problems with this.

"SMB file access" (i.e. a Windows client machine elsewhere on the
network, accessing resources via \\server\share\path) does not use
sssd, but uses smbd + winbind/winbindd for UID resolution? This is the
part that is failing intermittently.

> It could be that sssd isn't running or running correctly, so it cannot get
> the required info from AD, so winbind is returning the info from idmap.ldb,
> hence the '3000000' numbers.

Does winbind/wbinfo ever query what is defined in /etc/nsswitch.conf,
or does it always use the samba internal UID resolution? I thought it
would bypass nsswitch.conf entirely - hence my suspicion that this is
nothing to do with sssd.

It's hard to reproduce this at will - right now "wbinfo -i myuser" is
returning correct UID information. The problem (as far as i can tell)
is that, every so often, despite me having "idmap_ldb:use rfc2307 =
yes" in smb.conf, this same wbinfo command returns incorrect UID
information (as also shown in "net cache list") and therefore this is
why I cannot access files via smbd until I clear the idmap cache via
"net cache flush".

I'm trying to narrow it down to a particular set of circumstances but
it's so intermittent, I'm really struggling.

I would raise a bug on bugzilla but I'm not sure there's enough
information here for someone familiar with the code to resolve it,
yet.

It is of course possible that I'm doing something wrong - but the
thing that makes me convinced it's a bug is that I have /not/ changed
my configuration in any way since June (when I last saw this issue).
After my recent upgrade to 4.3 the problem came back - I saw it again
last night - but has not reoccurred since then until now.. I really do
think there is a subtle bug here.

Is it worth me putting all this into a bugzilla entry, even though I
haven't yet narrowed down the full circumstances under which it
happens?

Thanks

Jonathan

-- 
"If we knew what it was we were doing, it would not be called
research, would it?"
      - Albert Einstein