[Samba] several offices: home dirs, local resources, ...

[Kees van Vloten]

On 22-11-2022 17:07, Michael Tokarev via samba wrote:
> 22.11.2022 17:52, Rowland Penny via samba wrote:
>>
>>
>> On 22/11/2022 14:20, Michael Tokarev wrote:
>>>>>>
>>>>
>>>> In another post, you mentioned 'unbound', are you aware that your 
>>>> choices for a dns server in relation to a Samba AD DC are just two 
>>>> ? Samba's internal dns server or the Bind9 dns server. Yes you can 
>>>> use a different dns server, but only as a forwarder, anything for 
>>>> the AD dns domain must be forwarded to an AD DC, any AD DC, they 
>>>> are all authoritative for the AD dns domain.
>>>
>>> This is a bit too broad. Samba does not require its nameservers to 
>>> be autoritative
>>> for the zone.
>>
>> Sorry, but yes they do.
>
> Even microsoft does not have this requiriment, - that dns must be hosted
> by the AD.  And they allow static DNS configuration too (without dynamic
> DNS updates), as far as I can see.
>
> Where this requirement comes from?
>
>>>   It requires (actually AD requires as you correctly
>>> mentioned) certain
>>> DNS records to be present and maintained.  The list of records samba 
>>> register in
>>> DNS is available in /var/lib/samba/private/dns_update_cache 
>>> ((re)generated by
>>> samba_dnsupdate from ../dns_update_list).  These names don't change 
>>> with time, -
>>> once put into DNS they can stay there, there's no need to update them.
>>>
>>> All the names listed in there are registered in our DNS.
>>
>> There have been numerous others that have thought like yourself, they 
>> have all had problems.
>
> I don't know that. And I'm asking for particular reasons, just like with
> using DC as a file server, -- only after countless attempts to ask why
> this is so, Kees van Vloten finally gave some light there: the fileserver
> operations in source4 is not implemented completely.  But it took several
> dozens of emails and questions, before such a simple answer has been 
> given.
>
>> Why do you think Samba went to all the trouble of writing their own 
>> dns server and also writing the code (along with Bind) to connect the 
>> Bind9 server to Samba AD ?
>
> Because for many people adding dns records required for AD is difficult,
> it is much better for small setups if things can work out of the box.
>
>>> Samba only support 2 nameservers (named and samba internal) for 
>>> registering names
>>> *automatically*. But it is not mandatory to *use* one of these 2 
>>> nameservers,
>>> provided all the names are in the DNS.
>>
>> Yes it is and you can use multiple nameservers in bind9
>
> Yes it is what?
>
> Once data is in Bind or in Samba internal DNS, it can be fetched from 
> there
> and managed by other nameservers. Or is this data so specific to samba
> that no other standard DNS servers can handle it? If so, what is the 
> problem,
> what is so non-standard in that data which makes it unsuitable for other
> nameservers?

The DNS records live in AD, to be more exact in LDAP and hence they are 
replicated to the other DCs.

There are just to frontend interfaces for that Samba-internal and Bind 
with DLZ.

You can manage it with the MS-tools for AD or with samba-tool dns, both 
will push the records into LDAP

>
>>>> You also mention above 'maybe samba should not do that', well you 
>>>> could write that as 'maybe Active Directory should not do that'.
>>>
>>> I was referring to Kees's statement.  Samba registers itself as a 
>>> FILE server for
>>> a domain (with sysvol).  If the file server is non-functional, samba 
>>> should not do
>>> that, instead, another samba server (which *is* able to work as a 
>>> file server)
>>> should take these functions.
>>
>> You can use a Samba DC as a fileserver, you just have to be aware of 
>> the limitations, one of which is that you must set the permissions 
>> from Windows.
>
> Which permissions I have to set for a read-only DFS-root share which 
> serves
> only 2 folder referrals?  Why it works out of the box without setting any
> permissions, what I'm doing wrong?
>
>>>> Active directory is built on three things, DNS, Kerberos and LDAP. 
>>>> The last two depend on the first.
>>>
>>> Yes. Working DNS is a must.  Here I'm 100% sure DNS works correctly. 
>>
>> Not from my perspective, but you do it your way and I will stick to 
>> mine.
>
> What do you think I'm missing?  I even dumped the content of the internal
> samba dns server, - it matches exactly the stuff which I've added 
> manually.
> Which other magic non-standard entries are there which I don't see and
> which cause other nameservers to be unable to serve this zone? Please
> tell me, I'm confused, I really am.
>
>>> Unlike with all
>>> the issues people reporting all around the globe, - I do know how 
>>> things work and
>>> that there's no hidden movement behind my back which breaks stuff.
>>>
>>>> I have never used systemd containers, do they allow 'root' to 
>>>> operate exactly as if it was a full blown computer ? If they don't, 
>>>> then that could be your problem.
>>>
>>> "Exactly" is again a too broad term. For example, root user in a 
>>> container usually is
>>> not allowed to change host clock or reboot host.
>>>
>>> Which problem you're talking about, exactly? 
>>
>> The ability for root to have the same capabilities as if it was a 
>> totally separate OS.
>
> This is never the case in any container, including lxc and anything 
> else. Root in
> a container can have a set of necessary privileges (eg, full control 
> over container-
> specific network stack) but not all which is available on the host. I 
> highly doubt
> samba uses every capability a regular root on the host has, - it does 
> not use lots
> of syscalls for which their own special capabilities are needed.
>
> But still, which _problem_ you're talking about?  You said:
>
>  I have never used systemd containers, do they allow 'root' to operate 
> exactly
>  as if it was a full blown computer ? If they don't, then that could 
> be your problem.
>
> I don't see any problem with running samba in a container.  All 
> problems I see is
> due to lack of information about samba which I ask again and again and 
> again from
> different angles but still unable to get.
>
>>> Inability to register the same SPN for
>>> another server? 
>>
>> That is an Active directory thing, all SPN's must be unique.
>>
>>> Or samba DC not working as a file server?
>>
>> As I said, you can use A Samba AD DC as a fileserver, it just isn't a 
>> good idea.
>
> In this case why samba4 uses iself as a file server? Where is the 
> logic, if it
> is not a good idea, it should delegate its sysvol thing to something 
> which
> *is* good as a fileserver, no?
>
>>>> Have you investigated using a GPO for your profiles problem ?
>>>
>>> Yes. It doesn't work either, at least I can't find a way to do that.
>>>
>>> There are 2 problems: a) having the same "fs" name for a *local* 
>>> fileserver, its own
>>> in every site/office.  and b) having user profiles stored in a 
>>> site-specific (not
>>> user-specific) file server. Solving a) will automatically solve b).
>>>
>>> I can't find a way to solve a) with GPO.
>>>
>>> Attempt to solve at least b): I can set GPO for a client machine to 
>>> always require
>>> user profiles to be stored on a certain server. But this breaks 
>>> local adminsitrator
>>> account (in case of emergency needs) - since it can't find this 
>>> profile on the
>>> "forced" server.  Or I can configure profile path per-user - but it 
>>> must be per-site.
>>
>> Your problem isn't a Samba problem per se, it is an Active Directory 
>> problem, you would have the same problem if you were using Windows DC's.
>
> Sure. And I'm trying to solve it somehow.  If it were samba's internal
> DNS (or windows dns for that matter) it were unsolvable.  Now I do have
> a working solution finally, it seems, - with site-specific CNAME records
> overriding commonly-used names like "fs", - it finally appears to work.
>
> But I still really wish to understand:
>
> 1. which magic invisible DNS records are there which are required by 
> Samba which
>   I can't see in its internal DNS, and
>
> 2. why samba4 offers SYSVOL *file* share when using it as a file 
> server is not
>  a good idea, why not use reglar non-dc samba server for it?
>
> 3. what problem we're talking about?
>
> Thanks,
>
> /mjt
>