[Samba] NT_STATUS_OBJECT_NAME_NOT_FOUND randomly

[Andrew Walker]

On Fri, Jun 18, 2021 at 8:25 AM Rowland penny via samba <
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


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.

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.

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.

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