[Samba] smbd interoperability with sssd on Kerberos no winbind

[Cang Household]

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