On Thu, Nov 25, 2021 at 5:17 PM Spike White <[email protected]> wrote:
> Harald, > > I was hoping someone smarter than me would respond; someone who knew the > answer. But no one else did, so let me take a crack at it. I know the > problems and I know the possible approaches to the solution, but I do not > know the solution. > > FYI – we avoid Samba (servers) like the plague at work. Because the AD > integration is so fragile. We have commercial-grade NAS heads, that talk > CIFS to Windows servers and NFS to Linux servers. If your company can > afford it, that’s definitely the way to go. > > We’re fine with SMB mounts on Linux. Other than the slight annoyance > about username/password having to be put (in clear text) in some creds > file, it’s a slam dunk. (SMB filesystem support is embedded in any recent > Linux kernel.) > > Anyway, back to Samba server with sssd & sshd. There’s two fundamental > problems: > > 1. Samba typically uses its own AD integration backend. Winbind. > Like sssd, winbindd expects its own machine account created and registered > in the back-end AD domain. That machine account will (usually) conflict > with sssd’s machine account. sssd stores its machine account password in > /etc/krb5.keytab file. Samba usually stores its machine account password > in a secrets.tdb file. > > > > 2. The particular UID mapping that is in use for sssd may not be > supported by winbind. For instance, at work we use Microsoft’s RFC 2307bis > AD schema extension, which associates UNIX attributes with each user and > group account. Not sure if winbind supports this method of UID mapping. > > Anyway, those are the two main problems. Let’s first explore the > solutions to problem #1. > > 1. You can register sssd under one machine account (maybe the > server’s FQN) and then register winbindd under another machine account. > This is conceptually the simplest approach; you have two totally different > AD integration stacks. One for ssh and login (sssd + AD backend) and then > another stack for samba server (i.e., winbindd). Thus, every 30 days sssd > will update its machine account password and store it in the > /etc/krb5.keytab file. Also, every 30 days, winbindd will also update its > (own different) machine account password and store it in its secrets.tdb > file. > > > > 2. You register to AD using adcli’s –add-samba-data flag (and > possibly –samba-data-tool*=/path/to/net*). So then every 30 days, sssd > will call adcli to update its machine account password. You have to add > to your sssd.conf file ad_update_samba_machine_account_password=true. So > that sssd every 30 days calls adcli update with the correct flags. You > also have to inform samba (or winbindd) not to update its machine account > password every 30 days. In that way, when sssd calls adcli update every > 30 days to update its machine account password, it stores the new password > in /etc/krb5.keytab file and in the samba secrets.tdb file. You are still > running two AD integration stacks, but now you have just one machine > account. > > > > You might look at https://access.redhat.com/discussions/3646491 . > Looks like they’re successfully doing a variant of this. They’re > instructing both sssd and samba to not update the machine account > password. Then they run a cron job every 30 days to call adcli update to > update both the /etc/krb5.keytab file and the secrets.tdb file. > > > > 3. Have samba use sssd for its AD integration back-end, instead of > winbindd. This is actually how we did it at work years ago, when we had > to have a samba server. (This was pre-sssd, a commercial AD integration > product.) sssd (& this commercial product) offers a “idmap” shim so that > samba thinks it’s talking to a winbindd back-end. > I'm not really an expert in this topic, but I think you mix two different things here. 'idmap_sss' only does a SID <-> local posix ID translations, so that smbd and sssd would be consistent on a given machine. It doesn't talk with AD on behalf of smbd. What you describe - "samba use sssd for its AD integration back-end, instead of winbindd" - sounds like sssd-libwbclient, and this stuff was broken for quite some time, and recently completely removed from the SSSD codebase. See: - https://github.com/SSSD/sssd/issues/5230 - https://github.com/SSSD/sssd/issues/5459 > But really it’s talking to sssd (or the commercial AD integration > product). > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/smb-sssd > discusses use of this idmap_sss module, as does > https://access.redhat.com/solutions/3802321 (you have to have a RH > subscription to read this second link). > > There are limitations of this approach. They are discussed in the first > link and also in > https://www.thegeekdiary.com/choosing-sssd-or-winbind-samba-for-active-directory-integration-in-centos-rhel/ > . > > > > Let’s next explore the solutions to problem #2. Here is where I’m weak. > We used solution #3 above, so then problem #2 disappeared. (Since sssd’s > AD backend is handling all the UID mapping, then as long as your AD UID > mapping scheme is one supported by sssd-ad, you’re golden). If you do > solution #1 or #2 above, you have to check your Samba documentation to > ensure your particular AD UID mapping scheme is accepted. > > I know I’ve set up a Samba server with an LDAP server back-end and I had > to diddle some of the "AD attributes to UNIX ID attribute" mappings in the > conf file. (the Samba server had support for RFC2307 mapping, but not > RFC2307bis. They’re very close but not identical). > > Spike White > > > > > > On Tue, Nov 23, 2021 at 9:36 AM Harald 11 <[email protected]> wrote: > >> Hello! >> >> I am using sssd 2.4 with Debian 11. >> >> I try to setup a samba server within a samba ads domain. I did several >> approches, sssd with ad and ldap configuration and samba with ad, sss and >> nss backend. >> Basic setup with sssd went good, login via ssh works. UID and GID are >> well too But I do not get samba run well. Either my user can't access >> server and see shares, nor I can access shares but UID and GID are wrong. >> >> Which way is best to get ssh and samba running with sssd? >> >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
