[Samba] smbd interoperability with sssd on Kerberos no winbind

[Rowland Penny]

On Sat, 13 Jul 2024 12:17:17 -0400
Cang Household via samba <samba at lists.samba.org> wrote:

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

You posted:

Seeking to serve file shares from AD-joined Debian

To serve shares, you need the filesharing deamon 'smbd' and that cannot
talk directly to AD, so you MUST also use the Samba daemon that can,
'winbind', if you run winbind, there is absolutely no point in using
sssd.

If you just want authentication, then sssd is great, but if you want
shares, then you must run Samba and that means with winbind.

You also shouldn't use the freeipa tools (adcli etc) with Samba, you
should use the tools that Samba provides, 'net ads join' for instance

I cannot stop you attempting to make it work with Samba and sssd, but I
will be here when you accept it will not work as you hope it will.
I should also point out that it is likely that if you run both sssd and
winbind, then your domain will goo offline at the end of a month.

Rowland