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:

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