On Thu, Nov 25, 2021 at 5:17 PM Spike White <spikewhitetx(a)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:
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/...
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?
>