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

On 28/04/2023 07: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.
> 
>>
>> In any mixed environment, it seems that the two systems can no longer 
>> co-exist. Instead you have two solitudes. If you want to access things 
>> available to Windows users, you need a Windows account. If you want a 
>> local Unix account, you can't access Windows shares with it. User
and
>> group mapping used to bridge that gap.
> 
> I think you are looking at this to strict. I have been using Samba for 
> some time and going to AD simplified things for me. And I have 
> absolutely no issues with Linux/Windows environment. OK I use sssd on 
> workstations but the member/file servers use Samba. I log onto my Linux 
> Computer with my AD account and can ssh, rsync or do smb file access 
> without having to use a password.
> 
> 
> Regards
> 
> Christian
> 
> 
> 
Never said you couldn't do it, I am just saying you shouldn't do it 
because there is no point to it. The whole idea of AD is to have a 
single point of maintenance and having local users & groups (except in 
exceptional cases) totally defeats that idea.

Rowland

On 2023-04-28 04:07, Rowland Penny via samba wrote:
>
>
> On 28/04/2023 07: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.
>>
>>>
>>> In any mixed environment, it seems that the two systems can no 
>>> longer co-exist. Instead you have two solitudes. If you want to 
>>> access things available to Windows users, you need a Windows 
>>> account. If you want a local Unix account, you can't access
Windows
>>> shares with it. User and group mapping used to bridge that gap.
>>
>> I think you are looking at this to strict. I have been using Samba 
>> for some time and going to AD simplified things for me. And I have 
>> absolutely no issues with Linux/Windows environment. OK I use sssd on 
>> workstations but the member/file servers use Samba. I log onto my 
>> Linux Computer with my AD account and can ssh, rsync or do smb file 
>> access without having to use a password.
>>
>>
>> Regards
>>
>> Christian
>>
>>
>>
>
> Never said you couldn't do it, I am just saying you shouldn't do it
> because there is no point to it. The whole idea of AD is to have a 
> single point of maintenance and having local users & groups (except in 
> exceptional cases) totally defeats that idea.
>
Not exactly correct. You can achieve a "single point of maintenance" 
through having only a single instance of everything or by propagating 
changes between authorities. AD actually uses the latter strategy when 
it recommends maintaining more than one DC.

What you are arguing for (and what Samba is now doing) is the former - a 
single instance of everything - instead of extending the AD strategy to 
propagate changes between domain controllers and Unix authentication. 
Given that the AD propagation strategy provides redundancy and better 
performance, this seems like a strange choice.

When you combine this with the harm it does to existing Unix 
infrastructure, the idea appears indefensible.