samba - Feb 2023 - Domain join with realm

On 10/02/2023 01:13, Andrew Bartlett via samba wrote:
> On Thu, 2023-02-09 at 09:38 -0800, Jeremy Allison via samba wrote:
>> On Thu, Feb 09, 2023 at 09:55:02AM +0100, Ralph Boehme via samba
>> wrote:
>>> Again, as a community we always have and will try to help folks
>>> with
>>> everything Samba related, including stuff "we do not
write". It's
>>> of
>>> course each individual's choice on which stuff he is able and
>>> willing
>>> to help. In doubt, I personally just don't reply to the list,
but
>>> instead just stay in read only mode and see if there's anything
I
>>> can
>>> learn.
>>
>> Indeed - well said Ralph. I personally see this lists as kind
>> of a grab-bag of "All Things SMB" :-).
>>
>> There isn't really a forum for SMB 1/2/3 protocol users and
>> implementors (although samba-technical is probably a better
>> list for implementors) and this list is the closest thing
>> we have.
>>
>> We're all in this crazy protocol world together, and we
>> all do better when we help each other, even if Samba
>> isn't directly involved. We all know sooner or later
>> it will be as we are the universal glue between Windows
>> and non-Windows systems :-) :-).
> 
> I strongly agree, but from the AD DC perspective. Many things integrate
> with Active Directory, and integrating with Samba is often
> straightforward and so 'just works'. However some things are a
little
> different with Samba (like how to generate a keytab), and we should do our
best to help because users who can integrate Samba well with their network
become happy long-term users and supporters.
> 
> Andrew Bartlett
> 
> 
The problem with all this is, Samba does not write or provide realmd or 
sssd, so how can it fully provide support for them ?
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 ?

I personally will never support realmd or sssd, they appear to be 
problematical when used with Samba.

The other question that has to be asked is, why do people want to use 
them over the Samba tools ?

Rowland

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.