[Samba] Domain join with realm

Fri Feb 10 19:28:54 UTC 2023

On 10/02/2023 19:02, Andreas Schneider wrote:
> 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 never said it was doing anything incorrect, I just said it is using, 
in my opinion, strange ranges.

  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.

Does that mean that it no longer works for Samba versions before the 
'-k' change ?

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

My problem now is, after reading the realmd code, I realise I had a bash 
script for Debian that did what realmd, but better, it actually asked 
what idmap backend to use, what range to use etc. I abandoned this when 
Andrew didn't like my samba-tool changes because he didn't like the 
ranges being sort of set in the python code, something that realmd does.

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

Never said it was, but that doesn't really matter if the basic code is 
doing things it shouldn't without asking.

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

Those changes are very welcome, but it doesn't help when A) Users never 
read the smb.conf manpage and B) have never heard of testparm (not 
through any fault of Samba).

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

I am not saying that the ranges in the realmd code are wrong per se, it 
is just that I think they are stupid, but that is probably just me.

> 
> In the meantime we suggest to
> 
> a) Join with 'realm join' (It creates a valid id mapping for the domain)

Valid to who ?

> b) Always run testparm
>     * When you change the config, run testparm.
>     * When you update Samba to a newer version, run testparm.

I can heartily agree with all that.

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

As far as I can see, most of the RHEL documentation is behind a wall, so 
I have given up looking.

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

I am not pointing fingers, I just trying to get my point of view across.

> 
> I've also changed sosreport to collect `testparm -s`:
> 
> https://github.com/sosreport/sos/blob/
> d4f56eeebb277a0c9eb0ef246121edcccb64a8ba/sos/report/plugins/samba.py

You see, there you go, what is 'sosreport', never heard of it before ?

Rowland