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> 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
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