[Samba] How to join RHEL 7 Linux Server to Active Directory Domain

[Rowland Penny]

On 26/09/2022 03:08, Nico Kadel-Garcia via samba wrote:
> On Sun, Sep 25, 2022 at 1:15 PM Eddie Rowe via samba
> <samba at lists.samba.org> wrote:
>>
>> As Rowland indicated this isn't the Samba way that is documented in https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member which I found VERY helpful, but I have not fully worked out how RHEL setup in Chapter 16. File and Print Servers Red Hat Enterprise Linux 7 | Red Hat Customer Portal<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-file_and_print_servers#setting_up_samba_as_a_domain_member> is configured for Kerberos.  Specifically I am not sure how Winbind would use Kerberos in client mode since RHEL does not have steps to configure the /etc/krb5.conf.  RHEL 7's default /etc/krb5.conf does use the include line for /etc/krb5.conf.d/ which is empty.  I find this curious...does Winbind have AI to work out the Kerberos server? 8-)
>>
>> Samba Server Mode:  My understanding of Kerberos is there is no interaction between the Samba server and the Kerberos server.  The client system that wants to talk to the Samba server interacts with the Kerberos (Active Directory) server and the presents its service ticket to the Samba server that uses its secret key to verify the client is authenticated.
>>
>> Samba Client Mode:  Since my understanding is there is interaction between the client and the Kerberos server, my question is how does the RHEL Winbind setup know who to contact to get a Kerberos ticket?  I am led to guess that Winbind must somehow be able to ask the REALM defined in smb.conf for which server provides this functionality?
> 
> sssd is.... well, I'm going to restrain my tendency for colorful
> metaphors. sssd is entirely reliant on the underlying Samba provided
> libraries. And it has a *lot* of problems when you push it hard. One
> is that the "authocnfig", used to tune or enable it from the command
> line, wipes out any locally edited or tunded settings in
> /etc/sssd/sssd.conf, and there is no way to recover them except to set
> up your own, entirely distinct configuration and management tools.
> This is a waste of the time of Red Hat sys-admins.
> 
> Another issue is that sssd starts up, answers queries for a while, but
> attempts to pre-cache the entire LDAP setup. You can pick and choose
> relevant LDAP, but can only do so effective if the LDAP provided OU's
> are in one substructure, not if they scattered. And very, very few
> large environments organize their LDAP well enough to optimize this.
> They leave user groups scattered around different parts of their
> chart, and you wind up needing the whole thing. But if the LDAP is too
> big, sssd times out and shoots itself through the head, and restarts
> start over reloading the same bulky LDAP environment from scratch, and
> fail again. It's been more than a decade, and there is no solution to
> this problem except to set up another LDAP server closer to the
> clients, which gets expensive and makes AD admins throw a hissy, even
> if you offer to set up a Samba host for them to avoid expensive
> Windows server icenses.
> 
> The Samba clients don't have this rat's nest of clients, but RHEL
> documentation does not support using just Samba as a client anymore.
> And the Samba built into RHEL has the domain controller features
> disabled, so switching to a pure Samba setup becomes..... more
> difficult, though there are many published Samba releases with those
> features, including mine over at https://github.com/nkadel/samba4repo/
> or built into most modern network storage applicances. Red Hat instead
> encourages the use of FreeIPA as the server, and sssd as the client,
> which in my observation don't buy you anything useful except the
> simplified "authconfig" command settings, which in fact destabilize
> Samba or AD clients.
> 
> Nico Kadel-Garcia
> 

I am glad that I am not the only one who has seen through the use of 
Samba with sssd. I personally have nothing against sssd etc, I just 
cannot see the point in using it on a Samba domain member, you get the 
same result (with all the downsides) if you point sssd at an AD DC, you 
just get authentication. You can get authentication on Debian using 
kerberos by installing libpam-krb5, but you cannot do this on red-hat 
any more, they have remove pam-krb5, you have to use sssd.

To get the fullest benefit of AD on a Unix client, in my opinion, you 
have to use Samba with winbindd and set it up correctly.

Rowland