[Samba] Moving to AD for idmap backend

[Norbert Hanke]

For the "from *linux* to windows" case rfc230 attributes are actually
helpful:
create Windows user and group objects while keeping the existing Unix
UserIDs and GroupIDs.
samba-tool group add "$groupname" --gid-number=$gid ...
and
samba-tool user create "$username" "$password" --uid=$uid ...
are your friends. Even while you need to manage the numerical IDs yourself.

 From that time on, you either need to keep the two in sync, - that's
hard - or preferreably rely on winbind in /etc/nsswitch.conf and remove
the records from /etc/passwd and /etc/group or wherever.

When it comes to ACLs on directories and files it gets more difficult.
If users need unix access for the same files as they use from Windows
then |vfs objects = acl_xattr| and the like are not very helpful: ACLs
are interpreted by samba/smbd independently of what the Unix OS thinks
the the access restrictions on the same directories and files are.

Only OS-native ACL models will help, be it Posix or something else
offered by the underlying file system.
 From personal experience I can recommend ZFS on FreeBSD, such as
offered by ixsystem's TrueNAS. Access from the Unix shell on the file
server is identical to what you get from Windows over samba.

Accessing the same files from other Unix systems via NFSv4 or cifs looks
similar, although both have some limitations on visibility from the
client side. But in general, access restrictions on the server are
enforced by the server, in both cases, and that's what ACLs are about.

I hope that helps...

Regards, Norbert


On 29.11.2022 18:24, Michael Tokarev via samba wrote:
> 28.11.2022 21:58, Rowland Penny via samba wrote:
> ..
>
>> To be clear, whoever thought up the idea of assigning the uidNumber &
>> gidNumber attributes for two domains from the same pool is, in my
>> opinion, an idiot. Not even Windows does this, every DC has its own
>> RID pool, you can look at a RID and know on which DC it was created.
>
> This and the next one are a very useful pieces of information.
> This in part explains why there should be non-overlapping ranges
> for domains, and why one or another way of auto-rid is better
> than rfc2307 attributes for that (and there are many more points
> why this is so, - basically, you can't control the uidNumber
> allocations whatsoever). Very useful.
>
> It needs to be in a WIKI somewhere, but I can't think for a
> place for it - there's no "guide" in there, just a bunch or
> random pieces of info, and actually, many issuse in there
> are due to lack of the "full picture" in some guide.
>
> The problem is that quite often, the things goes the other way
> around: not from windows and their domains and their users to
> linux, but from *linux* to windows.  In other words, first there
> were linux users, next was a question, - how can I access their
> unix home dirs from a windows machine?  But the users, together
> with their IDs, are already there, and their uids needs to be
> mapped TO domain users, not FROM.
>
> A good and right integration needs complete user remapping.
> Which sometimes seemed as a much bigger pain than dealing
> with uidNumber attributes in the AD. Especially at *first*,
> before first clashes, or before someone starts rewriting
> some other's files due to the same uid.
>
> The whole picture, the understanding of the actual reasons
> why the ranges (at least for the different domains) must not
> overlap, why some automatic idmapping is better, and all that,
> only comes with experience, usually quite good one, after a
> lot of trial and error and dealing with consequences of the
> initial bad decisions which weren't known to be bad at all.
>
> /mjt
>