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

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.

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.

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

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.

On 28/04/2023 18:26, Gary Dale via samba wrote:
> 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.
> 
> 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.
> 
> 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. 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.
> 
> 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.
> 
Can I ask, how old are you and how old do you think I am ?

Rowland

Hi Gary.

Am 28. April 2023 19:26:00 MESZ schrieb Gary Dale via samba <samba at
lists.samba.org>:
>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.
Did this really work even if you had more than one samba server??? 

Regards

Christian