samba - Jul 2024 - smbd interoperability with sssd on Kerberos no winbind

On Fri, 12 Jul 2024 22:28:27 +0000 (UTC)
Household Cang via samba <samba at lists.samba.org> wrote:
> Hello there
> 
> Seeking to serve file shares from AD-joined Debian using sssd and
> Kerberos as authentication. No Winbind.
Stop right there, I do not know what distro you are using, but if it
was Debian, I would be running the following commands:

apt remove sssd
apt install winbind

The smbd daemon cannot talk directly to AD, it requires winbind for
this, so if you want shares, then you must run winbind.

What is your problem with winbind ?

Rowland

> apt remove sssd
 > apt install winbind

I need to disable enumerate AD user and group. With tens of thousands of 
objects in the AD, this makes login very slow. Another internal team 
already set up sssd on their OS for years. Me suddenly going to winbind 
would result in different uid and gid without some hacky idmap.

 > The smbd daemon cannot talk directly to AD, it requires winbind for 
this, so if you want shares, then you must run winbind.

I don't need smbd to talk to AD. I already told it where to find the 
machine krb5 keytab. Smbd should still be able to verify the kerberos 
tickets presented to it. I already said only Kerberos, no NTLMv2. NTLMv2 
is not that secure anyways.

I am making some progress on security = ads. In adcli, there is a flag 
called --add-samba-data, so I run adcli update --add-samba-data 
--computer-password-lifetime=0 to force a password update. 
--add-samba-data from adcli would add both machine SID and password into 
the /var/lib/samba/private/secrets.tdb

But more errors there, --add-samba-data resulted in exit code 1. So did 
-v on adcli, then showed

secrets_fetch_or_update_domain_info: 
secrets_domain_info_password_create(pw) failed for <COMPANY.NET> - 
NT_STATUS_UNMAPPABLE_CHARACTER.

Then used adcli update with --show-password to print the machine 
password in plain text. Then manually run net changesecretpw -d 5. It 
complains no key for current domain. So used tdbtool secrets.tdb insert 
SECRETS/MACHINE_PASSWORD/COMPANY.NET 1

Still having the same UNMAPPABLE_CHARACTER error, then changed unix 
charset = UTF-8 (default) to CP850, and return code = 0, so wow. Let's 
see if I could carry on the troubleshooting now.

man smb.conf was correct on saying security = ads or domain would 
require the machine to be joined with net utilities. So if joined with 
adcli, then net utilities would still need to be used to "hack" it to 
make it work.