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

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

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

>
>>
>> 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.
>
Let the multiplication of entities begin - to hell with William of 
Ockham. ;)

While sssd appears to do some of what I want, it's not quite the same as 
user & group mapping. The local accounts aren't really - sssd just 
maintains a cache for authentication when the DC isn't available. I 
still need to hook all my Linux computers up to an external "identity &
authentication provider". However, you are correct that this is looks 
like a better solution than installing Samba on all the computers.

With user & group mapping, I don't need to touch any of the non-server 
computers. But with any system requiring me to use AD accounts and 
groups, I need to change all my file permissions everywhere in addition 
to installing and configuring more software on every client.