On 28/11/2022 18:40, Vaughan, Robert J via samba wrote:>> Hello Samba listers >> >> We're looking at moving to idmap backend AD for our Samba domain member servers >> >> One concern I had is our corporation assigns uid for users in one corp sub-domain (A.X.com) interspersed with users from our other corp sub-domain (B.X.com) so that the range must be overlapping >> >> Some testing by a colleague shows Samba notes the overlap in the log but seems to work fine >> >> Can someone say if this should be fine, allowing that corp makes sure the uid are all unique in AD? > >>> Are you going to be using more of the rfc2307 attributes than >>> 'uidNumber' and 'gidNumber' ? > >>> If not, then I suggest you totally ignore them, use one of the domains >>> as your main domain and add a trust for the other, then use either the >>> 'autorid' or 'rid' idmap backend. > > Yes, we will need to use shell and homedir too (to support unix and linux shell logins for some users)Oh well.> > So to be clear, corp assigns uid and we must have Samba use these assignmentsTo 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.> > Some of these uid are even, unfortunately, below 1000 currentlyA really BIG idiot, didn't they have any idea about Unix ? The problem is that you shouldn't overlap domain ranges, which you are going to have to and this will lead to a collision somewhere down the line when a user or group is created at the same time as another and they both get the same ID number (yes it will happen, it is not case of if, it is when). I cannot recommend your set up, but it may be the only way, unless you can change the way that the rfc2307 attributes are allocated and, from the sound of it, it isn't going to happen. Rowland
> The problem is that you shouldn't overlap domain ranges, which you are > going to have to and this will lead to a collision somewhere down the > line when a user or group is created at the same time as another and > they both get the same ID number (yes it will happen, it is not case of > if, it is when).Rowland, can you please expand on that? You must be talking about a Windows user or group (at the same time?) Is this because winbind must create a mapping for every user it sees in AD? Even those users who are not Samba users and do not have uid specified? Robert Vaughan ---------------------------------------------------------------------- This is an e-mail from General Dynamics Land Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
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
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 >