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. 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/... 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-di... . 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 <harald_11(a)gmx.net&gt; wrote:

I set up this: [sssd] config_file_version = 2 domains = DOMAIN.NET [domain/DOMAIN.NET] id_provider = ad access_provider = ad sudo_provider = none fallback_homedir = /home/%u default_shell = /bin/bash skel_dir = /etc/skel debug_level = 9 cache_credentials = false ad_enable_gc = false I got very long uid like this 1017201111. My posix uid is 4 digits. How to convert to posix?

I saw that my AD does not have Posix attributes, rather than my LDAP. I guess, I have to switch to ldap mode?

I have a new setup with ldap and posix attributes, but how to setup Samba correct? idmap config MYDOMAIN : backend = sss idmap config MYDOMAIN : range = 30000-2147483647 idmap config * : backend = tdb idmap config * : range = 1100-2000 My user posix uid is 30020. I tried nss backend too.

Answers to questions. (Notice I said up front that Samba is not my forte. I answered the question when it looked like no one else was going to. I'm glad that my limited response spurred more full and accurate responses.) Previously, we used early EMC NAS solutions. They were dicey, as they tried to maintain one single user permission stack (between CIFS and NFSv3). It tried to map between the two and as you stated, the stacks are considerably different. They mostly worked, but not 100%. Now we use a Dell Isilon NAS solution. It has two totally separate user permission stacks that the storage engineers have to set up. One for CIFS and one for NFS. But once set up, the stacks operate as expected. We're very happy with that solution. Pretty good performance too. properly with this set up? I.e., the CIFS Windows mounts will set Windows ACLs -- do your NFS mounts respect these permissions; i.e. are you using NFS ACLs on this shares and does this recognize Windows ACLs? Yes, definitely a problem on those early EMC NAS heads that were trying to maintain only one security stack and map between Windows ACLs and NFS ACLs. Didn't seem to always work that well. From our Linux engineer perspective, maintaining two separate security stacks is definitely the way to go. (The storage engineers might be less of a fan however.) We do CIFS (mainly for Windows), NFSv3 and basic NFSv4. Not significant advanced-feature NFSv4. I believe the Isilon supports most or all of the features of NFS v4.1 (but don't quote me on that.) I know we've had to use some of the mandatory file-locking features of v4.x. But that's it. This explains it. https://unofficialaciguide.com/2019/07/31/ldap-schemas-for-aci-administra... Also, a couple of the specific user attributes have slightly different names. I had to consider that when I moved autofs data from NIS to AD: https://ldapwiki.com/wiki/LDAP%20schema%20used%20by%20autofs Spike On Fri, Nov 26, 2021 at 12:01 PM Patrick Goetz <pgoetz(a)math.utexas.edu&gt; wrote: > Just mentioning that as pointed out in the subscriber-walled RHEL > article, for Samba >= version 4.8, you must run windbind. And don't have > a choice. My current Samba + sssd servers use an older version of > Samba, and this works great. I need to continue to have Samba and I also > need to retain the sssd UID mappings, so am stuck making this work myself. > > For the benefit of the OP, there are a number of people on the Samba > mailing list who are successfully using sssd and winbind at the same > time, so it is do-able. I would check in with that list to see how > they're doing it. Otherwise, I have a couple of questions for Spike -- > see below. > > On 11/25/21 10:15, Spike White 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. > > > > > properly with this set up? I.e., the CIFS Windows mounts will set > Windows ACLs -- do your NFS mounts respect these permissions; i.e. are > you using NFS ACLs on this shares and does this recognize Windows ACLs? > Definitely won't recognize DENYs -- that's not supported by NFSv4 AFAIK. > > > > 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.) > > Yes, but as far as I know CIFS mounts don't respect POSIX extended ACls, > which is a problem if you're using these for authorization control on > linux systems. Not supporting POSIX ACLs would be a deal killer for me, > unfortunately. > > > > > 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. > > This depends on your smb.conf configuration. If you set > > kerberos method = secrets and keytab > > in the [global] section then it sets both secrets.tbd and krb5-keytab > > Valid options are: > > - secrets only - use only the secrets.tdb for ticket verification > (default) > - system keytab - use only the system keytab for ticket verification > - dedicated keytab - use a dedicated keytab for ticket verification > - secrets and keytab - use the secrets.tdb first, then the system keytab > > > > > > 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. > > winbind supports RFC2307. You set something like > > idmap config SAMDOM:backend = ad > idmap config SAMDOM:schema_mode = rfc2307 > idmap config SAMDOM:range = 10000-999999 > idmap config SAMDOM:unix_nss_info = yes > > > in smb.conf. What's the difference between RFC2307 and RFC2307bis? > > > > > 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 > > <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. 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/... > > < > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/... > > > discusses use of this idmap_sss module, as does > > https://access.redhat.com/solutions/3802321 > > <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-di... > > < > https://www.thegeekdiary.com/choosing-sssd-or-winbind-samba-for-active-di... > > > . > > > > 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 <harald_11(a)gmx.net > > <mailto:harald_11@gmx.net>> 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 -- sssd-users(a)lists.fedorahosted.org > > <mailto:sssd-users@lists.fedorahosted.org> > > To unsubscribe send an email to > > sssd-users-leave(a)lists.fedorahosted.org > > <mailto:sssd-users-leave@lists.fedorahosted.org> > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > <https://fedoraproject.org/wiki/Mailing_list_guidelines> > > List Archives: > > > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste... > > < > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste... > > > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > <https://pagure.io/fedora-infrastructure> > > > > > > _______________________________________________ > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > > 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/sssd-users@lists.fedorahoste... > > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > >>> This message is from an external sender. Learn more about why this << > >>> matters at https://links.utexas.edu/rtyclf. << > _______________________________________________ > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org > 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/sssd-users@lists.fedorahoste... > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >