Do you create POSIX attributes in AD for EVERY user??

Posted by electrowiz64@reddit | linuxadmin | View on Reddit | 11 comments

Long story short we have a few servers operating as Samba in an AD (education) environment (education Linux Servers) so we're using WinBind for THOSE servers and SSSD for ALL OTHER RHEL/Ubuntu servers.

We're migrating from a POS OpenLDAP server (synced from AD) that gave constant auth headaches to DIRECT Active Directory auth using SSSD & Winbind so we settled on storing POSIX attributes in AD, pulling the UIDs/GIDs from the old OpenLDAP server and storing into AD and mapping on all servers so nothing breaks.

My fear is we've got a handful of Linux Desktops and so naturally what do we do about users who want access to those? I can do SSSD but now we gotta store UIDs/GIDs for all those users. Students come and go, so I'm assuming we need an automated way of creating UIDs/GIDs for new users. Curious if you guys have an automated way of creating UIDs/GIDs when new users get entered into AD? Or do you just create an entry/task on demand for new users who want to get setup into Linux??

My last resort is leave LDAP mapping off on some linux shared desktops so users can log in freely, but im leaning towards a full 100% lockdown and tracking uids/gids in a spreadsheet

[-]

hortimech@reddit

Samba actually uses the SID and maps that to whatever Unix ID backend you set in the smb.conf file. The question you should be asking is, is Samba going to be used a fileserver ? If it is then you must use winbind and the only way to get the same IDs on all Unix machines is to use the 'ad' idmap backend, but you do not really need the rfc2307 attributes as the mapping is done locally, so you could use the 'rid' idmap backend if there is only one domain, or the 'autorid' idmap backend for multiple domains.

[-]

electrowiz64@reddit (OP)

the problem is I want to use SSSD for literally EVERYTHING else as recommended by redhat and Ubuntu and I read that SSSD & Winbind compute their SIDs differently.

SO my fear was god forbid if users are trying to communicate between the 2 different servers, their IDs will NOT be the same and there would be permission issues. I could be overthinking it but I'm not trying to brick anything, even though id would LOVE to not use rfc2307

[-]

hortimech@reddit

Well redhat would recommend sssd, it is their product, written by the same person that wrote most of winbind and it is based on winbind. You shouldn't matter if your users don't have the same Unix ID, but you never know. Yes, sssd and winbind do compute Unix IDs differently (unless you use rfc2307 everywhere in Unix), that is where the ID backends come in.

What is wrong with using winbind instead of sssd ? winbind is just as easy to set up as sssd, once you know the correct method.

[-]

dodexahedron@reddit

I'm pretty sure sssd-ad has a dependency on winbind anyway, doesn't it?

You shouldn't have to touch it once set up, though. Join it with adcli and it'll do everything it needs to from that point on, including rotating keys in the keytab (or keytabs if you have multiple for gMSAs or something).

A domain joined system can use NFS4 with kerberos and ditch samba all together, too.

[-]

hortimech@reddit

No, while sssd does have dependencies on some Samba files (samba-common for instance) it doesn't have a dependency on winbind, this is because sssd is really just a wrapper around the original winbind code.

A Samba domain joined system can use NFS and also provide SMB shares, no need for sssd.

[-]

dodexahedron@reddit

sssd itself is likely already there and already hooked into pam. If these are rhel, ubuntu, or derivatives, it definitely is if it wasn't removed manually. The ad module is also there if they're already joined. So it's done already. No need to switch that up.

Why bother with samba if you dont need it? NFS is so much easier to support and secure on Linux, is in-tree, the driver itself is usually baked in, it doesn't use and never had NTLM, doesn't have the IO burden that samba places on the system due to heavy xattr use, doesn't have kerberos problems with windows reaulting from being Heimdal Kerberos for forever, and is a lot easier to configure (and do so safely) on top of it all. And it doesn't come with the inherent danger created by windows assuming mandatory locking being respected end to end, over SMB, which Linux can't provide and Samba itself can only fake.

[-]

hortimech@reddit

There is nothing wrong with sssd that 'apt purge sssd*' will not cure and if you are relying on sssd, you are relying on AD, so why not use it.

There is nothing wrong with NFS, provided you do not have Windows in the mix. Also the 'heavy xattr use' as you call it, is one of Samba strenghts, not a weakness.

I feel we will never agree on this.

[-]

dodexahedron@reddit

If you put nfs on the workstations, you don't need samba on the servers for file access.

NFSv4 can do things by name mapping rather than raw IDs, which makes the uidNumber/gidNumber unimportant for remote file access regardless of what id the user has on each system. Just be sure to set it up for kerberos.

But yes - our user create script creates the user, grabs the last part of the new account's SID, and sets uidNumber to that. Group create script does the same but for gidNumber.

It's generally not an issue or even particularly necessary, though, unless PAM isn't set up to use sssd instead of local passwd/group/shadow files, because authenticated sessions will use whatever sssd handed to the system.

More of an issue is making sure selinux is set up to more faithfully enforce windows-style access control over things, aince POSIX ACLs arent capable of it, and making sure that group memberships are being evaluated correctly since nested groups aren't a thing in Linux (sssd-ad should be handling this for you, but make sure).