On Sun, Sep 19, 2021 at 2:52 PM Rowland Penny via samba < samba at lists.samba.org> wrote:> On Sun, 2021-09-19 at 13:16 -0500, Patrick Goetz via samba wrote: > > Hi - > > > > This question is with reference to: > > https://wiki.samba.org/index.php/Idmap_config_ad > > > > I think I know how this works, but there are still points of > > confusion. > > Given the example smb.conf file provided on the page referenced > > above: > > > > [global] section of smb.conf: > > ------------------------------------- > > security = ADS > > workgroup = SAMDOM > > realm = SAMDOM.EXAMPLE.COM > > > > log file = /var/log/samba/%m.log > > log level = 1 > > > > # Default ID mapping configuration for local BUILTIN accounts > > # and groups on a domain member. The default (*) domain: > > # - must not overlap with any domain ID mapping configuration! > > # - must use a read-write-enabled back end, such as tdb. > > idmap config * : backend = tdb > > idmap config * : range = 3000-7999 > > # - You must set a DOMAIN backend configuration > > # idmap config for the SAMDOM domain > > idmap config SAMDOM:backend = ad > > idmap config SAMDOM:schema_mode = rfc2307 > > idmap config SAMDOM:range = 10000-999999 > > idmap config SAMDOM:unix_nss_info = yes > > > > vfs objects = acl_xattr > > map acl inherit = yes > > store dos attributes = yes > > ------------------------------------- > > > > I believe "Default domain" is a bit of a misnomer referring to > > accounts > > that are identified by nss before it gets to winbind or sssd; > > You cannot use sssd with Samba. >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.> I"m converting a small NT domain > > to Active Directory (by hand). The environment has several linux > > machines with local UIDs assigned in the 1001-2000 range (but with > > the > > UIDs the same across the linux hosts). Since I don't plan to bind > > most > > of the linux machines to the domain (there is a vague user-driven > > business case for this), > > I would rethink this, it is always better to join machines to the > domain. > >Not sure I would agree, but okay. Maybe for Patrick's benefit you could provide some additional detail and reasoning on this?> > I would like the authorization to work the same > > for Samba shares to AD bound Windows machines and the standalone > > linux > > workstations, > > Good luck with that, it is probably impossible to get the same numeric > ID's on unjoined machines. >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). * 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 :-). 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.> > since these systems mount the same remote filesystems via > > either SMB or NFS in the case of the linux systems. So my thought is > > to > > do something like this: > > > > portion of [global] section of smb.conf > > ------------------------------------- > > idmap config * : backend = tdb > > idmap config * : range = 2000-2999 > > # - You must set a DOMAIN backend configuration > > # idmap config for the SAMDOM domain > > idmap config SAMDOM:backend = ad > > idmap config SAMDOM:schema_mode = rfc2307 > > idmap config SAMDOM:range = 1001-1999 > > 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.> > ------------------------------------- > > > > Again, very unclear why I'm configuring a tdb database for local > > accounts, if my understanding of how this works is correct. >You aren't and, unfortunately, it appears you do not understand how it> works. > >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).> > This would > > reserve the UIDs 2000-2999 for potential local use, while creating an > > AD > > UID mapping that seamlessly works with the existing linux systems. > > Then > > if I do end up binding some of these linux machines to the domain, > > everything just works with no acl mapping, or anything like this. > > If you are using the winbind 'ad' backend, then there is no acl > mapping. > > > > > Any thoughts? Am I confused about how this works? My understanding > > of > > how the default domain works is based on this RHEL article: > > https://access.redhat.com/solutions/1984483 > > > > Try reading our documentation: > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member > https://wiki.samba.org/index.php/Idmap_config_ad > > If you still do not understand something, please ask. > > I personally would ignore what you have now and set up a new AD domain > and wouldn't use standalone servers, I would join everything to the > domain. > >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? -Nick
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