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?
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/htm... 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-direc... .
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@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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Nov 25, 2021 at 5:17 PM Spike White spikewhitetx@gmail.com 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:
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.
The particular UID mapping that is in use for sssd may not besupported 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.
You can register sssd under one machine account (maybe theserver’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.
You register to AD using adcli’s –add-samba-data flag (andpossibly –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.
Have samba use sssd for its AD integration back-end, instead ofwinbindd. 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/htm... 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-direc... .
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@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?
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?
On Tue, Nov 30, 2021 at 12:43 PM Harald 11 harald_11@gmx.net 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?
Do you mean you have POSIX attributes defined in Active Directory and want to use those? Then please add `ldap_id_mapping = False` to `[domain/DOMAIN.NET]`
See `man sssd-ad::ID MAPPING` for details.
I saw that my AD does not have Posix attributes, rather than my LDAP. I guess, I have to switch to ldap mode?
If your AD DC isn't storing POSIX attributes, you can't use these and are stuck using the UIDs generated by sssd from the user's SID.
On 11/30/21 09:19, Harald 11 wrote:
I saw that my AD does not have Posix attributes, rather than my LDAP. I guess, I have to switch to ldap mode? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o... 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. <<
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.
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.
Might I ask what commercial grade NAS solutions you're using?
Also, how are you able to get permissions on shared filesystems to work 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/htm... 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 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-direc... 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 <harald_11@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@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave@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.fedorahosted.org <https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org> 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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o... 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. <<
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.)
Might I ask what commercial grade NAS solutions you're using?
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.
Also, how are you able to get permissions on shared filesystems to work
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.)
Definitely won't recognize DENYs -- that's not supported by NFSv4 AFAIK.
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.
What's the difference between RFC2307 and RFC2307bis?
This explains it.
https://unofficialaciguide.com/2019/07/31/ldap-schemas-for-aci-administrator...
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@math.utexas.edu 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.
Might I ask what commercial grade NAS solutions you're using?
Also, how are you able to get permissions on shared filesystems to work 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/htm...
<
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
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-direc...
<
https://www.thegeekdiary.com/choosing-sssd-or-winbind-samba-for-active-direc...
.
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@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@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
<https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
sssd-users@lists.fedorahosted.org
-
Alexey Tikhonov -
Harald 11 -
Patrick Goetz -
Spike White