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

[Gary Dale]

On 2023-04-27 08:25, Rowland Penny via samba wrote:
>
>
> On 27/04/2023 12:45, Gary Dale via samba wrote:
>
>>
>> Those ideas suggest a complex mixed environment with a lot of Unix 
>> and a lot of Windows users that need to be managed separately. 
>
> No, you do not have separate Unix and Windows users, you just have AD 
> users, which can be mapped to Unix users.

If you don't have Unix users then the UIDs and GIDs can't interfere. The 
idea of interference requires the existence of both sets.


>
> Moreover, it
>> doesn't actually say what goes wrong if a Windows group "interferes" 
>> with a Unix group. What would happen if, as once was standard 
>> practice, Domain Users had the same GID as Users - why is "mapping" 
>> now forbidden?
>
> First mapping isn't forbidden, it just isn't used in the way that it 
> once was.
> You do not need a user 'fred' in /etc/passwd that the Windows user 
> 'fred' is mapped to, you just have a user 'fred' in AD and winbind 
> maps this to a Unix user called 'fred'.
> I am fairly sure that I have shown you this once, but I will do it again:
>
> rowland at devstation:~$ grep 'rowland' /etc/passwd
> rowland at devstation:~$
> rowland at devstation:~$ getent passwd rowland
> rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash
>
> As you can see, 'grep' cannot find my name in /etc/passwd, but 
> 'getent' says that I am a Unix user.

However the old idea of mapping required nothing on the Unix end. Domain 
Users mapped to Users so any Windows logon could access files belonging 
to the Users group. When viewing files in a shared folder, the group 
showed as the Window group but when viewed on the local machine, it 
showed as the Unix group. If it wasn't sharing files, no need for any 
extra infrastructure.

The new mapping now requires the Samba infrastructure to preserve the 
login. Even if I have server (and I do) that only does NFS, I still need 
to install Samba on it. Other methods of keeping passwords synced don't 
work.

Moreover, I need to revise my entire ecosystem to use the AD users and 
groups. Apart from anything else, this seems ripe for unintended 
consequences.


>
>>
>> I will note that there is already an exception to the rule for 
>> Administrator, which maps to root.
> And that is the only exception and is done to ensure that from Samba's 
> point of view, Administrator has the ID '0', otherwise if you use the 
> 'rid' idmap backend (as I do), you get this:
>
> rowland at devstation:~$ getent passwd administrator
> administrator:*:10500:10513::/home/administrator:/bin/bash
>
> Which makes Administrator just another Unix user, never log in as 
> Administrator on a Unix machine.

Which begs the question, why make this special? Why not allow all users 
to be mapped?

If you change the Administrator password on Windows, does that change 
the root user's password on Unix? If yes, then doesn't that mean you 
have essentially all the programming you need to allow any user to be 
mapped? If no, then doesn't that make AD a poor way to authenticate on a 
Unix machine?

 From a strategic standpoint, I also object to the registry-like nature 
of AD. I hate putting a collection of simple things into a complex 
database then pretending it's an improvement. It's easy fix things when 
there is a problem with /etc/passwd or /etc/group but what happens when 
the AD database becomes corrupt and that corruption propagates through 
all your DCs?

That's why even a beast like systemd uses simple, plain text 
configuration files.

I understand that we're not going to change how Windows operates, but 
why would we ever want to emulate them?

>
>>
>>>>
>>>> Another issue that isn't addressed with instructions and an example 
>>>> is the adding of a GID to the standard domain groups. It seems to 
>>>> be necessary but the only example doesn't seem to deal with it. An 
>>>> example showing adding a GID to Domain Users, for example would be 
>>>> helpful.
>>>>
>>>
>>> samba-tool comes with help, try running 'samba-tool user create 
>>> --help' or 'samba-tool user addunixattrs --help'
>>>
>> Wrong issue. According to the AD backend wiki "If you use the winbind 
>> 'ad' backend, you *must* add a gidNumber attribute to the |Domain 
>> Users| group in AD". However when you go to 
>> https://wiki.samba.org/index.php/Administer_Unix_Attributes_in_AD_using_samba-tool_and_ldb-tools, 
>> there are examples for creating a new Unix group and for adding Unix 
>> attributes to an existing group, but not for the specific and 
>> essential task of adding a GID to Domain Users.
>
> I have added such an example, but Domain Users is just another AD group.

Except you need to know how to handle spaces in group names (i.e. quote 
the name, escape the space or take as just another character). Plus, an 
example should be generally useful and something that is essential 
certainly fits.

Thanks.


>
>>
>> The example they do give is not really explained. You need to dig a 
>> lot deeper to discover that "msSFU30NisDomain" is an Active Directory 
>> attribute. And the option of doing this from the Windows side is 
>> similarly hard since currently-supported versions of Windows don't 
>> have "Server for NIS Tools".
>
> If you had dug deeper still, you would have found that most of the 
> 'Server for NIS tools' attributes were never really used and are not 
> required, perhaps they should be removed from the wiki.
>
> I am sure that I have said this before, but I will say it again, AD is 
> very different from the old NT4-style domains and you need to forget a 
> lot of what you know about the nt4-style domains, otherwise it will 
> just confuse you.
>
NT4 style domains haven't been used for a long time. The issue I've been 
complaining about has to do with mangling Unix to accommodate Windows. I 
have an existing Unix infrastructure that needs to occasionally handle 
Windows users. I apparently now, despite using AD successfully for the 
past decade, upend that because the Samba developers have apparently 
decided that it's better to just go all-in on Windows.

As for the NIS tools, GUIs are useful because they can hide the magic 
values and present a simple interface. While full-time AD administrators 
may not use them, the same can not be said for people who only dabble in 
AD once in blue moon. I live by the command line (and even use sed 
sometimes to work on Scribus documents) but I still use Thunderbird for 
e-mail (although I've had occasion to resort to manually editing some of 
its configuration when it screwed up).