[Samba] NT_STATUS_OBJECT_NAME_NOT_FOUND randomly

[Rowland penny]

On 18/06/2021 15:38, Andrew Walker wrote:
>
>
> On Fri, Jun 18, 2021 at 8:25 AM Rowland penny via samba 
> <samba at lists.samba.org <mailto:samba at lists.samba.org>> wrote:
>
>     On 18/06/2021 13:08, Andrew Walker via samba wrote:
>     >>       idmap config * : range = 3000-7999
>     >>       idmap config CUSTOMER : backend = rid
>     >>       idmap config CUSTOMER : range = 10000-999999
>     >>
>     > Won't the idmap setting changes change IDs assigned for AD
>     users? This
>     > change can potentially require re-doing permissions on-disk once
>     you've
>     > made it. You might also want to keep a backup of your
>     winbindd_idmap.tdb
>     > file. I'm not saying it's a bad idea, but it's something you
>     will need to
>     > evaluate and keep in mind while making the changes (and do them in a
>     > maintenance window :))
>
>
>     Unfortunately, yes it will, but it is an artefact of not correctly
>     setting the 'idmap config' lines in the first place. The OP could
>     find
>     out what ID's the users and groups are using now and then use the
>     'ad'
>     backend and populate the rfc2307 attributes with the ID's
>
>     I do wish people would read our documentation before setting up a
>     Unix
>     domain member, it is easier to 'fix' something before it goes into
>     production.
>
>     Rowland
>
>
>
>     -- 
>     To unsubscribe from this list go to the following URL and read the
>     instructions: https://lists.samba.org/mailman/options/samba
>     <https://lists.samba.org/mailman/options/samba>
>
>
> Bastian, the following is not comprehensive, you should definitely 
> read / understand relevant documentation and manpages. Winbindd idmap 
> backends control how Windows SIDs are converted into Unix user and 
> group IDs. Different idmap backends have different strategies for 
> dealing with SIDs. Take, for example, the SID for DOMAIN\Administrator 
> S-1-5-21-<domain>-500.
>
> Your original smb.conf lacked an explicit idmap configuration for the 
> domain to which you are joined. This means that the configuration for 
> the default domain (idmap config * : range = 10000-40000) is used. In 
> this case, contents of winbindd_idmap.tdb will be checked for an 
> S-1-5-21-<domain>-500 entry, and if it doesn't exist a new entry will 
> be generated based on the current high-water-mark in the tdb file. 
> These get allocated on a first-come first-serve basis.
>
> Rowland's suggestion, which is a very sensible one, is to use 
> idmap_rid. The idmapping strategy here is to take the RID (the last 
> component of the SID) and add it to the configured low-range for the 
> backend. So in this case we know that DOMAIN\Administrator gets 10500.


Now you know that mapping, forget it, never use Administrator on a Unix 
domain member, always map Administrator to root (via a usermap) on a 
Unix domain member.

>
> Having a deterministic way of mapping SIDs to IDs is a very good 
> thing. Think about what will happen if you decide to add a second 
> samba server to the AD domain and rsync data between them. If you are 
> using idmap_rid with the same configuration options, then the 
> permissions on the files on the receiving side will behave identically 
> to what is configured on the source server. If you have a 
> non-deterministic strategy, then the situation is kind of hopeless.


Or to put it another way, select which winbind to use, then use it on 
all Unix domain members.

>
> Note that this does not mean that idmap_rid is always the correct 
> choice. When you are deploying a samba server in an existing AD 
> environment, the correct course of action is to figure out the 
> idmapping strategy currently in use in the domain. Often the server 
> you are deploying will not be the first Linux or FreeBSD server joined 
> to the AD domain. Many domains use RFC2307 attributes, and in this 
> case use idmap_ad. If there are samba servers already on-site, you 
> should base idmap configuration on what is deployed and in-use. There 
> are some caveats regarding SSSD that I won't get into.


I will, if you use Samba >= 4.8.0 and require shares, do not use sssd. 
If you just want authentication, you can use sssd (without Samba), but 
there are problems (sssd doesn't update tickets for instance).

>
> So, basically, you should bite the bullet and fix things (but think 
> carefully and research what the right fix is).


Try reading the Samba wiki:

https://wiki.samba.org/index.php/User_Documentation

Anything that don't understand, please ask, we rely on feedback and 
questions to try and get the wiki understandable.

Rowland