samba - Apr 2023 - DNS problems (still) with Linux domain members - using Samba's internal DNS backend

On 2023-04-28 13:32, Reindl Harald wrote:
>
>
> Am 28.04.23 um 19:26 schrieb Gary Dale:
>> On 2023-04-28 11:29, Reindl Harald wrote:
>>>
>>>
>>> Am 28.04.23 um 16:05 schrieb Gary Dale via samba:
>>>> On 2023-04-28 02:03, Christian Naumer via samba wrote:
>>>>> Am 28.04.23 um 06:13 schrieb Gary Dale via samba:
>>>>>> Under previous versions, my Windows account mapped to
my Unix
>>>>>> account. Without user mapping, I can only access Samba
shares
>>>>>> that Windows-only users access through my Windows
account. Unix
>>>>>> accounts can't be members of Windows groups and
Windows group
>>>>>> can't map to Unix groups either.
>>>>>
>>>>> Rowland will not like to hear this but you can still do
this.
>>>>> Although I agree with Rowland that you should not. If you
use the
>>>>> "normal" Linux tools you can add users from AD to
Linux groups.
>>>>> That only works on the machine you are doing this but it
does work.
>>>>> You can even (Rowland do not read further) add local Samba
users
>>>>> with smbpasswd when your server is running with AD (I
accidently
>>>>> did this once) and use that to access your server. But
makes
>>>>> everything even more complex and harder to understand the 
>>>>> behaviour in my opinion.
>>>>
>>>> Not quite the same as mapping. With mapping, the AD accounts
and
>>>> groups were mapped to local Unix accounts and groups. My domain
>>>> account and local accounts were linked so I could access
anything
>>>> that allowed Domain Users from Windows or users from Linux. My 
>>>> server account's password (used mainly to ssh in via a
certificate)
>>>> remained in sync with the Domain password. Any users added to 
>>>> Domain Users or users had access to the same files.
>>>>
>>>> As for other machines, Linux has a plethora of tools for
keeping
>>>> files (or parts thereof) synchronized when needed
>>>
>>> the whole point of AD is a single source
>>>
>>> what you see below are "local" unix users stored in mysql
and AD is
>>> supposed to provide exactly the same
>>>
>>> [root at sftp:~]$ cat /etc/nsswitch.conf
>>> passwd:???? files mysql systemd
>>> shadow:???? files mysql
>>> group:????? files mysql systemd
>>> hosts:????? files dns
>>
>> You are ignoring the point that AD doesn't do what you want Samba
to
>> do - maintain a single authority. AD replicates information between 
>> DCs. Samba used to do that as well, keeping accounts and groups 
>> synced through mapping. While AD propagates changes between DCs based 
>> on ids and time stamps, Samba should (and used to) propagate changes 
>> based on mapping. If I changed my Windows account password, it would 
>> change the mapped Unix account password on the server running Samba. 
>> If I used smbpasswd to change my passwd, it would do the same.
>>
>> Conflating a single domain with a single DC is the flaw in your 
>> logic. An AD account can authenticate against any DC that it can 
>> reach. There isn't a "single source". There are (or can
be) multiple
>> sources that are kept synchronized by processes running on the servers.
>
> the AD is a single source - that you have multiple DC's is a 
> implementation detail - period
By the same argument, an AD implementation that uses mapping is also 
single source. That it uses mapping is an implementation detail -
period.
>
>> Just like AD replicates changes made on one server to other servers, 
>> Samba should do the same. The issue is whether should continue to 
>> follow it's long-standing practice of mapping Windows accounts to 
>> Unix accounts or, as it apparently is doing, dropping such mapping 
>> and insisting that it will only synchronize Windows accounts.
>
> a domain user is a domain user -no matter what OS - period
>
> most people here simply don't get your problem becasue it's in your
brain
>
> "Just like AD replicates" and "Samba should do the
same" is nonsense
However, mapping allows both domain and local users while still 
preserving single source. It also doesn't require any changes to the 
clients while any use of domain-only accounts requires the client 
machines to run additional software to authenticate.

>
>> The single source argument has little to do with whether Domain Users 
>> maps to Users or whether a Windows account is linked to a Unix 
>> account on a Samba server. 
>
> hell - either you have a standalone server or AD
That's simply incorrect. There are multiple options for running single 
source authentication.
>
>> It is entirely to do with whether Samba serves as a bridge between 
>> between Windows and Unix or whether it acts only as a way to give 
>> Windows users access to Unix resources. I agree that doing the latter 
>> is simpler but since its inception, Samba had been doing the former.
>
> a samba AD simply works with no windows in the network at all
Hardly. An AD implements the Windows authentication backend. It lets you 
set up Windows accounts, not Unix accounts. You have to do extra work on 
the Unix workstations to get them to work with the Windows accounts. 
There are other single-source options that don't use Windows accounts. 
However the issue is that Windows is the prevalent desktop OS and we 
need to work with it.

>
>> Perhaps the real issue is that millennials aren't willing to put in
>> the work that the previous generations of Samba programmers were? ;) 
>> Dropping features may make the programming easier but it rarely makes 
>> the product better
>
> perhaps the real issue is that you want things which don't make sense
>
> if you want to have multiple machines with the same users use AD as 
> it#s designed - case closed
I want to continue to use Samba the way it worked for the first 
quarter-century of its existence.? I also want to continue to adhere to 
the Unix philosophy, which includes the simple account system that can 
be maintained with a text editor. AD is a Windows design that is an 
abomination. My interest in it is simply to give Windows users access to 
network resources. My Unix infrastructure works quite well and I am 
loath to completely rework it to use a Windows technology.

In my area, Linux is the primary OS and Windows is scarcely used. Samba 
as currently implemented makes Windows the primary OS with Linux as a 
secondary player. Even the ACLs used for shares have to be Windows under 
Samba,

If I want to add a workstation to AD, I have to go through purgatory. 
It's not just that I have to create a machine account, but I have to 
convert all the local accounts over to use the (new) domain accounts - 
after I install and configure the software necessary to actually work 
with the DC.

If I'm actually switching to AD (or upgrading to the current version of 
Samba which forces changes on me) then I have to rework all the shared 
resources as well because Unix accounts, groups and ACLs won't work.

Compare that to the situation with user & group mapping. I don't need a 
machine account. I don't do anything to the user accounts, and I only 
need to install CIFS (and possibly smbclient if I want to change the 
domain account's password). My machine continues to operate exactly as 
before. On the DC, I just need to create maps between the domain 
accounts and the local ones.

Not everyone does things the same way because not everyone is in the 
same situation. If you're running a Windows office with Linux/Samba 
servers, your way probably makes sense. However if you aren't 
Windows-centric, it doesn't.