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

On 2023-04-27 02:36, Rowland Penny via samba wrote:
>
>
> On 27/04/2023 01:37, Gary Dale via samba wrote:
>
>>
>> Neither actually addresses the question I raised. Apart from the 
>> administrative policy of using AD for account maintenance, why not 
>> use, for example, 100 as the <gid> or 1000 as a <uid>? If I
have to
>> set the ids manually, I should be able to keep track of them more 
>> easily when they are smaller numbers....? Or do you need to use large 
>> enough numbers so that all the ideas you may ever create will be the 
>> same length?
>
> If you have read the first page I pointed you to, you would have found 
> this:
>
> As you can see from the above, if you are creating a new domain, you 
> shouldn't set either the default domain '*' or the
'SAMDOM' ranges to
> start at 999 or less, as they would interfere with the local system 
> users & groups.
>
> It then goes on to say:
>
> You also should leave a space for any local Unix users & groups, so 
> starting the 'idmap config' ranges at 3000 seems to be a good
compromise.
>
> Local Linux users & groups are just that, LOCAL and shouldn't take 
> part in AD.
Those ideas suggest a complex mixed environment with a lot of Unix and a 
lot of Windows users that need to be managed separately. 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?

I will note that there is already an exception to the rule for 
Administrator, which maps to root.
>
>>
>> Or why not use autorid?
>
> You can use autorid, but it is really meant for multiple domains, you 
> cannot use 'winbind use default domain = yes' with it and you will
get
> different Linux ID's on every Unix domain member you run it on.
> If you do not wish to add anything extra to AD, then I suggest you use 
> the 'rid' backend, you can use 'winbind use default domain =
yes' and,
> provided you use the same basic smb.conf on all Unix domain members, 
> you will get the same ID's.
Still thinking about this. Thanks.
>
>>
>> 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.

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

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.

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

Rowland