[Samba] DNS problems (still) with Linux domain members - using Samba's internal DNS backend

Gary Dale gary at extremeground.com
Fri Apr 28 17:26:00 UTC 2023


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.



More information about the samba mailing list