On Sun, 2021-09-19 at 16:45 -0400, Nick Couchman wrote:> > This may be a side note/topic, or some nuance, but I've seen this > stated multiple times on the list in absolute terms like this, and it > isn't strictly true, and very much depends on what you mean by "use > sssd with Samba." Do the two work together and talk to each other? > No. But can they be used side-by-side on the same system? Yes. I run > them both on the same system in my environment in a couple of places, > and it works perfectly fine. Do I recommend it? Absolutely not. I > think in the vast majority of places - 7x9s - it makes more sense to > just run winbind with Samba, and adding sssd provides nothing but > more headaches - another configuration to maintain, another set of > problems to debug, etc. But I've run into situations where I needed > sssd on the same system as Samba, and it can be done.You used to be able to use sssd with Samba, but from Samba 4.8.0 , the smbd binary must go via winbind to get to AD. This means, because sssd has its own version of the winbind libs, you cannot use sssd anymore. It may seem to work, but it will not work correctly and it isn't supported any longer.> > > > > > > Not sure I would agree, but okay. Maybe for Patrick's benefit you > could provide some additional detail and reasoning on this?The whole idea behind AD is to get centralised authentication management (amongst other things) and using standalone servers with AD means having user & group management in multiple places, with different ID's on most machines. The different ID's may not be a problem, until someone decides that the standalone server needs joining to the domain (and this will happen), this is when the tears start.> > Actually, it's definitely possible - I can think of at least two ways > this can be accomplished: > * Use sssd for NSS info instead of Winbind. Again, I'm not saying you > _should_, I'm saying you can, and sssd seems to be deterministic in > its ID mapping algorithm (similar to Winbind's idmap_autorid > backend).I think you missed that sssd is no longer supported with a Samba fileserver.> * Use sssd's LDAP backend, and have the uid, gid, and shell > attributes present for users in your AD schema. Yes, this adds > further management and complication that may be undesirable, but it > is doable, and is the most deterministic method :-).You may be able to do this, but it is totally unsupported and you may as well use nslcd (which isn't supported as well).> > Again, I know sssd comes with its own challenges, but I see all these > absolute statements of "you cannot do this" and "that is impossible" > when my real-world experience says it is possible. Whatever I'm doing > wrong is working in my environment.You are late to the party, you appear to be trying to make all the same mistakes that Debian based distro users made years ago. Forget sssd, it is no longer supported by Samba (not that it was ever really supported) and isn't needed.>That will allow you ONE local Unix user and 1998 AD Unix users I wouldn't recommended it.> Why one local UNIX user? This doesn't make any sense.Exactly. Your DOMAIN range starts at '1001' and the Unix range starts at '1000', you do the maths, I come up with '1' Linux reserves the first 999 ID's for system users & groups, normal local Unix users & groups start at '1000' (do not confuse these with users in AD), so your Domain range needs to be above this. This is all explained in the wikipage I pointed you to.> tdb is the default backend that the Samba winbind config recommends > or defaults to, but it isn't the only one. You can look at > winbind's rid or autorid backends if you prefer something more > deterministic and less random (tdb isn't really random, just first- > come, first-served on a per-system basis).The 'tdb' backend is the recommended backend for the default '*' and this domain is meant for the 'Well Known SIDs' and anything outside the 'DOMAIN' domain (not including local Unix users). You should only require a few local Unix users (users in /etc/passwd), because all AD users can be Unix users. Why? You've stated this multiple times, and you haven't really> provided any clear reasoning for the original user as to why you > think joining to the domain is the best option. Maybe it is, but > could you help him understand?There is a lot of baggage that gets dragged along with upgrading an NT4-style domain to an AD domain, amongst which is the old idea of using low ID's. This was only required when you had to have Samba users that were also Unix users in /etc/passwd, this is no longer required and should never be set up this way, just store everything in Samba AD. Of course, this is just my personal opinion, setting up a new AD domain gives you a fresh start, but you must use it to its best advantage, which to me means joining all machines to the domain. Rowland
On Sun, Sep 19, 2021 at 5:27 PM Rowland Penny via samba < samba at lists.samba.org> wrote:> On Sun, 2021-09-19 at 16:45 -0400, Nick Couchman wrote: > > > > This may be a side note/topic, or some nuance, but I've seen this > > stated multiple times on the list in absolute terms like this, and it > > isn't strictly true, and very much depends on what you mean by "use > > sssd with Samba." Do the two work together and talk to each other? > > No. But can they be used side-by-side on the same system? Yes. I run > > them both on the same system in my environment in a couple of places, > > and it works perfectly fine. Do I recommend it? Absolutely not. I > > think in the vast majority of places - 7x9s - it makes more sense to > > just run winbind with Samba, and adding sssd provides nothing but > > more headaches - another configuration to maintain, another set of > > problems to debug, etc. But I've run into situations where I needed > > sssd on the same system as Samba, and it can be done. > > You used to be able to use sssd with Samba, but from Samba 4.8.0 , the > smbd binary must go via winbind to get to AD. This means, because sssd > has its own version of the winbind libs, you cannot use sssd anymore. > It may seem to work, but it will not work correctly and it isn't > supported any longer. > >Yes, I understand that Samba now requires winbind to function correctly when interacting with Active Directory. I'm not arguing that point. I'm just saying you can run both sssd and winbind side-by-side - at least, in the distributions of Linux that I use there is no conflict and installing, running, and configuring them concurrently. And, you can still choose to use sssd for NSS and not use winbind for nss. Or you can use _both_ for nss. There are endless possibilities (okay, maybe 4 possible permutations, but, still....) Again, I'm not saying I recommend it in most cases, but you can do it - it does work, it is doable. There may even be real-world scenarios where it is _required_ or _desirable_.> > > Actually, it's definitely possible - I can think of at least two ways > > this can be accomplished: > > * Use sssd for NSS info instead of Winbind. Again, I'm not saying you > > _should_, I'm saying you can, and sssd seems to be deterministic in > > its ID mapping algorithm (similar to Winbind's idmap_autorid > > backend). > > I think you missed that sssd is no longer supported with a Samba > fileserver. > >I might be splitting hairs, but this statement isn't true. It _is_ true that Samba (smbd) now requires winbindd to function correctly, and that smbd won't talk to AD through sssd. It is not true that you cannot run sssd concurrently with smbd+winbind. Should you? Probably not. Is it impossible? No. How do I know? I have a server running in that configuration today, and it works wonderfully.> > * Use sssd's LDAP backend, and have the uid, gid, and shell > > attributes present for users in your AD schema. Yes, this adds > > further management and complication that may be undesirable, but it > > is doable, and is the most deterministic method :-). > > You may be able to do this, but it is totally unsupported and you may > as well use nslcd (which isn't supported as well). > >Unsupported, as in I'll be ridiculed on this mailing list for running it this way? Good to know.> > > > Again, I know sssd comes with its own challenges, but I see all these > > absolute statements of "you cannot do this" and "that is impossible" > > when my real-world experience says it is possible. Whatever I'm doing > > wrong is working in my environment. > > You are late to the party, you appear to be trying to make all the same > mistakes that Debian based distro users made years ago. Forget sssd, it > is no longer supported by Samba (not that it was ever really supported) > and isn't needed. > >Your opinion is noted.> > > > That will allow you ONE local Unix user and 1998 AD Unix users > I wouldn't recommended it. > > > Why one local UNIX user? This doesn't make any sense. > > Exactly. Your DOMAIN range starts at '1001' and the Unix range starts > at '1000', you do the maths, I come up with '1' > > Linux reserves the first 999 ID's for system users & groups, normal > local Unix users & groups start at '1000' (do not confuse these with > users in AD), so your Domain range needs to be above this. This is all > explained in the wikipage I pointed you to. > >This is the _default_ setting, but not the _only_ setting. I can very easily add local users with the "useradd" command that are well above the 1000-1999 range. I can also change the default settings of a Linux distribution to use a different range of user IDs, say 6000 - 6999. It's pretty easy. So, if I wanted to, I could have winbind allocate IDs 1001 - 1999, and I would still have 2000 - 65535 (actually, much higher these days, but that's the old-world UNIX maximum) to allocate in /etc/passwd and /etc/group. The math adds up to far more than 1. Even the "reservation" of IDs below 1000 for system users is encouraged as a best-practice, and a sort of recognized defacto standard, but there's nothing special about those IDs (aside from, maybe, 0).> > > > tdb is the default backend that the Samba winbind config recommends > > or defaults to, but it isn't the only one. You can look at > > winbind's rid or autorid backends if you prefer something more > > deterministic and less random (tdb isn't really random, just first- > > come, first-served on a per-system basis). > > The 'tdb' backend is the recommended backend for the default '*' and > this domain is meant for the 'Well Known SIDs' and anything outside the > 'DOMAIN' domain (not including local Unix users). > You should only require a few local Unix users (users in /etc/passwd), > because all AD users can be Unix users. > >My point is that tdb will end up with AD users that have different IDs on different Linux systems. In many scenarios, particularly ones where you have mostly Windows environments, where you don't care about what the local ID actually is, this doesn't matter at all. There are some places where it does matter - for example, when you have shared/clustered filesystems (NFSv3, GFS(2), or NFSv4 without ID mapping), or you're replicating things at a below-filesystem level (e.g. zfs send/receive, drbd, etc.). In those cases it can be extremely helpful when UID and GID numbers match up across systems, which means that they need to be generated deterministically.> > Why? You've stated this multiple times, and you haven't really > > provided any clear reasoning for the original user as to why you > > think joining to the domain is the best option. Maybe it is, but > > could you help him understand? > > There is a lot of baggage that gets dragged along with upgrading an > NT4-style domain to an AD domain, amongst which is the old idea of > using low ID's. This was only required when you had to have Samba users > that were also Unix users in /etc/passwd, this is no longer required > and should never be set up this way, just store everything in Samba AD. > > Of course, this is just my personal opinion, setting up a new AD domain > gives you a fresh start, but you must use it to its best advantage, > which to me means joining all machines to the domain. > >Thank you. Sorry to have hi-jacked the thread. Feel free to ignore me and carry on. -Nick
First of all, I really appreciate the helpful discussion and comments. Based on Rowland's comment below, which I believe I also saw verbatim in a StackExchange thread, I'm switching gears for a second to an entirely different system I maintain which is larger and more critical. On 9/19/21 4:25 PM, Rowland Penny via samba wrote:> > You used to be able to use sssd with Samba, but from Samba 4.8.0 , the > smbd binary must go via winbind to get to AD. This means, because sssd > has its own version of the winbind libs, you cannot use sssd anymore. > It may seem to work, but it will not work correctly and it isn't > supported any longer. >I'm the administrator for a structural biology lab. We did the initial SARS-CoV-2 imaging used to design both the Pfizer and Moderan mRNA vaccines. You might have noticed that is an ongoing situation, so there is some mild interest in keeping this facility operational. The system consists mostly of linux workstations and servers, but with a few Windows machines used for some computational biology packages that only run on Windows. Also, the microscope vendors supply control PCs which all run Windows, and I have to interface with these. The university we're a part of runs a Windows Active Directory domain service (AUSTIN) with some rather unfortunate design constraints (and architectural decisions) that I have no control over. This domain is itself populated dynamically from an authoritative X.500 directory. This means we can't use (or maybe the AD team can't figure out how to facilitate) RFC2307 extensions because the entire directory is rewritten every day. Furthermore, they refuse to allow any domain trusts. The reason the latter is important is when all else is lost, you can always add another layer of indirection, say by having your linux users authenticate against a FreeIPA directory which has a trust relationship with the domain (as discussed in this series of blog posts of which this is a representative post: https://www.redhat.com/en/blog/i-really-cant-rename-my-hosts (This might work with a Samba AD instead of FreeIPA, too; I'm not sure. Also, If someone looks at the blog and is confused by my comments, AFAIK idM is basically FreeIPA supported by RedHat.) Largely based on the chutzpah of naivete, we decided to use the University's AUSTIN directory for authentication and authorization anyway. So far this has worked pretty well using both sssd and Samba. All the linux hosts are bound to the domain using sssd, and the file servers also run smbd. Samba seems to be required on all the linux machines regardless of whether they serve files, I'm not exactly sure why. It took a while to get this all working, and now I just use a recipe to set up new machines. Because sssd uses a fixed algorithm for mapping SIDs to UIDs, the users UIDs are consistent across all machines. Access is controlled using AD Security Groups. A GPO is associated with each host that restricts console and/or remote access to one or more security groups. In a typically open scientific context, that would be the end, but because we have groups that have contracts for work with, say, Pfizer, I have to make sure that some data has read access restricted to a particular group, with further restrictions on who can write to the collection. The way I implemented this is to have all files owned by a local dummy user/group on the file server with very lax permissions (but no ability to log in) and then use POSIX extended ACLs for actual access restrictions; e.g. # setfacl -d -m g:cns-smithlabusers:rX smithdata # setfacl -d -m u:smith8437:rwX smithdata where cns-smithlabusers is an AD Security Group consisting of Smith Lab researchers, and smith8437 is the AD UserName of the PI, the only person authorized to edit the data in this case. For after the fact authorization control, something like # setfacl -R -m g:cns-smithlabusers:rX smithdata # setfacl -R -m u:smith8437:rwX smithdata This works remarkably well and is pretty flexible. For example, we run a distributed software stack which needs read access to all the image data and which runs as a local user. To facilitate this: setfacl -d -m u:cryosparc_user:rX EMimages setfacl -R -m u:cryosparc_user:rX EMimages cryosparc_user is a local user on the linux workstations, and is then able to access the data, which is NFS-mounted from one or more of the fileservers (using sec=sys), so authorization questions are deferred to the file server. Yes I understand that this isn't really secure against a determined attempt to access the data, it's a convenience/security trade-off the PIs are OK with. Back to Roland's comment. The linux workstations share data over NFS, which defers POSIX ACL authorization back to the file server, so no problems there. And so far, everything has worked properly on the Windows machines as well; i.e. users are able to log in to the Windows machines using their University credentials and their home directories and relevant image collections are mounted automatically from the fileservers (again, facilitated via Group Policy). However, I checked, and our main file server is running an older version of Samba: cnsit at kraken:/EM$ dpkg -l | grep " samba " ii samba 2:4.7.6+dfsg~ubuntu-0ubuntu2.11 amd64 SMB/CIFS file, print, and login server for Unix Now it looks like I'm going to have to rethink the entire system architecture if I want to upgrade the file server from Ubuntu 18.04 to anything newer? (Ubuntu 20.04 ships 4.11.6). This is going to be a problem, as all the files are related to the UIDs and GIDs generated by sssd. I'm not sure that's realistic in a very active research environment. The solution is likely going to involve virtualizing all the Windows machines and using IOMMU to provide a PCIe passthrough for whatever GPU's they need for processing. Any thoughts on this appreciated.