samba - Jul 2021 - NT_STATUS_OBJECT_NAME_NOT_FOUND randomly

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

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

Hello Andrew, hello Rowland and hello list,

thanks again very much for the clarification of the user ID mapping process.

On Thursday I will change the configuration to an own mapping range for 
the CUSTOMER domain as proposed.

To be honest I still don't understand why this change should fix my 
problem with the "NT_STATUS_OBJECT_PATH_NOT_FOUND" and 
"NT_STATUS_OBJECT_NAME_NOT_FOUND". Though the mappings in the current 
configuration are not deterministic, it should still always be the same 
in the mapping file while not altered and Samba is running, or not?

I will change the IDs on Thursday and will report on Friday if the 
problems has been resolved through this or not.

As you mentioned the documentation: Maybe it is possible to log which 
"OBJECT_PATH"/"OBJECT_NAME" was not found. The would
probably clarify a lot.

Regards
Bastian

Am 18.06.2021 um 16:38 schrieb Andrew Walker via samba:
> 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).
-- 
Bastian Sebode
Fachinformatiker Systemintegration

LINET Services GmbH | Cyriaksring 10a | 38118 Braunschweig
Tel. 0531-180508-0 | Fax 0531-180508-29 | http://www.linet-services.de

LINET in den sozialen Netzwerken:
www.twitter.com/linetservices | www.facebook.com/linetservices
Wissenswertes aus der IT-Welt: www.linet-services.de/blog/

Gesch?ftsf?hrung: Timo Springmann, Mirko Savic und Moritz Bunkus
HR B 9170 Amtsgericht Braunschweig

USt-IdNr. DE 259 526 516