[Samba] Moving to AD for idmap backend

Michael Tokarev mjt at tls.msk.ru
Tue Nov 29 17:24:06 UTC 2022

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.


More information about the samba mailing list