[Samba] idmap & migration to rfc2307

[Michael Adam]

On 2015-11-07 at 17:47 +0000, Jonathan Hunter wrote:
> On 7 November 2015 at 17:01, Michael Adam <obnox at samba.org> wrote:
> >
> > Also, for all I know, the DC always has local unix user and group
> > IDs, and does NOT use the rfc2307 attributes for this. (Unless
> > this has changed recently, but I can't imagine how.) So there is
> > nothing wrong with samba not using the rfc ids on the DC -- this is
> > how it works by design.
> 
> Thanks Michael. I will see if I can use winbind locally instead of
> sssd later this evening, now that I have fully switched to rfc2307
> rather than algorithmic mappings.
> 
> One question on this, though - how is file ownership managed on the DC
> from the samba side? I know DCs aren't "supposed" to be used as file
> servers in the samba view of things (which is another story
> altogether), but I can't understand why sometimes the ID mapping comes
> from the rfc2307 attributes and then later on not.

I don't understand that yet.
As explained in my previous mail, what can happen is that
a user first (before given a rfc unixID) gets its uid from the
idmap.ldb, but as soon as there is a unixid in the rfc
attributes in his ldap object, that should always be used.

This is a per-user thing.

It is not surpsising that an externally configured sssd
(configured to use rfc in a ad, and hence behaving more like
a domain member) possibly gives different results, and also
consistently uses the rfc attrs, since that one does not
have the fallback to idmap.ldb that samba has.

The mapping should indeed be consistent for a user on the DC,
so it should not intermittently switch between idmap.ldb and
the rfc attributes. That would be a bug that we need to
understand.

One step as written in a previous mail would be to change
the dc code to _never_ fall back to idmap.ldb when configured
with "idmap_ldb:use rfc2307 = yes".

Then you write that when you see the wrong uid,
a 'net cache flush' gets you back the correct uid.
That is interesting. That flush command flushes
winbindd's idmap cache (which is also used r/o by
smbd).

We need to understand what happens here.
Rowland has already correctly asked for higher-level
logs.

When we have those, we'll see furhter.

Cheers - Michael


> The mapping needs
> to be consistent so that any files on disk are owned by the correct
> UID (even if the local DC's Unix system doesn't necessarily know who
> that UID is - that's the job of winbindd / sssd / etc. as I understand
> it) ?

> There are a lot of people (including me) who for various reasons
> really, really want to use a single machine as both a DC and a file
> server. Having this work with any sort of consistency in UID mappings
> is proving to be a little bit problematic :)
> 
> It's frustrating for me because it works for a while (5 months until
> yesterday) but then something triggers and it doesn't work again...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba/attachments/20151107/eac824e5/signature.sig>