[Samba] Domain join with realm

Fri Feb 10 19:02:48 UTC 2023

On Friday, 10 February 2023 19:00:29 CET Rowland Penny via samba wrote:
> On 10/02/2023 17:36, Jeremy Allison wrote:
> > On Fri, Feb 10, 2023 at 08:33:10AM +0000, Rowland Penny via samba wrote:
> >> The problem with all this is, Samba does not write or provide realmd
> >> or sssd, so how can it fully provide support for them ?
> > 
> > It's not a matter of providing support, we can (and should) IMHO
> > provide basic help on interop with these tools. At the very least,
> > point people at the web pages where people can get deeper information.
> > 
> >> I know some of the Samba team work for red-hat (and have possibly
> >> worked on them), but they should be (in my opinion) supporting Samba
> >> by saying something like:
> >> 
> >> Well, yes they will work with Samba, but Samba provides 'net ads join'
> >> and winbind and that is what is supported here, if you want support
> >> for realmd and sssd, you should contact red-hat'.
> >> 
> >> Or, do you not have faith in the code that is written for Samba ?
> > 
> > Well as you know, Samba is *always* broken :-). Has been in the
> > 30+ years I've worked on it, will be for the next 30+ years I
> > work on it too :-) :-) :-).
> > 
> > Of course, that's the same for all code, open source or proprietary :-).
> > 
> >> I personally will never support realmd or sssd, they appear to be
> >> problematical when used with Samba.
> > 
> > That's fine, just don't answer realmd or sssd-related questions.
> > 
> > Let the Red Hat Samba Team members pick up the slack. You don't
> > need to answer all questions or tell people why you're not responding
> > to a question. I ignore people on the list all the time :-).
> > 
> > How about just ignoring realmd or sssd questions and only answer
> > net  and winbind ones ?
> > 
> >> The other question that has to be asked is, why do people want to use
> >> them over the Samba tools ?
> > 
> > Sometimes it's not a question of "want". It can come down to corporate
> > policy etc. etc.
> 
> I had already decided that was what I was going to do, just ignore any
> post that says realmd or sssd.
> 
> However, It interested me, just what is realmd doing on top of 'net ads
> join' ?
> So I found the source and I now have a question for Andrew Bartlett.
> 
> A few years ago, I tried to add the ability to samba-tool user to store
> the next Unix ID's in AD, Andrew shot this down in flames, amongst the
> reasons was the fact that I wanted to specify the domain range to use in
> AD and hence in smb.conf
> 
> So Andrew, why do seem to be able to accept realmd, when it does exactly
> the same thing, it dictates the ranges that are set in smb.conf ?
> 
> Having seen the code, I now understand where all those strange smb.conf
> ranges are coming from and I think someone should tell red-hat that
> 'idmap uid' and 'idmap gid' were deprecated at 3.6.0 , over 10 years ago.

I don't see that realmd is doing anything incorrect, I've just checked the 
smb.conf it creates. The maintainer and I work in the same team and we adjust 
realmd to changes in Samba when needed. The last change was to switch from -k 
to --use-kerberos for the net command.

I use 'realm join' every time when I join a machine. It simply saves a lot of 
time as it does not only join with 'net ads join' but also sets up PAM, NSS, 
and KRB5.

However realmd is not only used on Red Hat systems but also other 
distributions and if they don't keep it up to date, it isn't our 
responsibility.

Our documentation also states that whatever you do changes you should run 
testparm [1] and I added a lot of checks to testparm that people don't mess up 
their idmap configurations.

I had so many bug reports in the past with incorrect idmapping ranges. The 
incorrect ranges didn't come from realmd but customers who did not read the 
idmap manpages and messed up their configuration.

In the meantime we suggest to

a) Join with 'realm join' (It creates a valid id mapping for the domain)
b) Always run testparm
   * When you change the config, run testparm.
   * When you update Samba to a newer version, run testparm.

If you look through the documentation for RHEL you will find testparm very 
very often. So since we suggest realm join and running testparm, customer 
cases with incorrect idmapping dropped significantly.

It doesn't help if we point fingers, it helps if we improve tools like 
testparm to detect invalid configurations.

I've also changed sosreport to collect `testparm -s`:

https://github.com/sosreport/sos/blob/
d4f56eeebb277a0c9eb0ef246121edcccb64a8ba/sos/report/plugins/samba.py

	Andreas

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/
html/configuring_and_using_network_file_services/assembly_using-samba-as-a-
server_configuring-and-using-network-file-services#proc_verifying-the-smb-
conf-file-by-using-the-testparm-utility_assembly_using-samba-as-a-server

-- 
Andreas Schneider                      asn at samba.org
Samba Team                             www.samba.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D