Different IDMAP ranges between 11.x and 12

[Schwabix]

Hello,

[This is a translated cross-post from the German section]

Does TrueNAS core 12 allow to change the ranges in DirectoryServices -> ActiveDirectory -> Advanced -> Edit IDMap without re-joining the domain?
Are overlapping ranges allowed as in earlier releases?

Scenario:
For years I'm running two SMB-Servers on FreeNAS, currently 11.1U6 and 11.3U5. "NAS1" is the active server, while "NAS2" frequently receives replications to be ready as a fallback server. NAS2 is also used as a testbed for new releases. User accounts are queried from our pretty large Active Directory ("wbinfo -u" shows ~70'000 entries).

As NAS1 is getting to its hhardware limits, I built a new "NAS3" based on TrueNAS Core 12 (started with 11.3U5 but had to update due to issue NAS-107821). After replication finished I found differences in ID mapping, resulting in broken ACLs on the new server. While our NAS1/2 use overlapping ID ranges for LDAP [10k .. 90M] and AD [20k .. 90M] the new 12,0 separates them as

• DS_TYPE_LDAP [20k .. 90M]
• DS_TYPE_DEFAULT_DOMAIN [90M+1 .. 100M]
• DS_TYPE_ACTIVEDIRECTORY [100M+1 .. 200M]

As a result existing IDs in my replicated data sets are no longer mapped to our AD users (that's my assumption) and the ACLs don't work (that's the observation):

Unfortunately the search function did not find any documentation for Edit IDMAP.

Your help is appreciated!

 

[anodos]

Can you just adjust the range for DS_TYPE_ACTIVE_DIRECTORY to cover 20000 - 90000000?
Do you have both AD and LDAP enabled?

 

[Schwabix]

I will try. LDAP is not enabled.
Thanx!

<later> works without a re-join or restart. Excellent!

 

[anodos]

Default range for AD was bumped up somewhat to avoid possibility of having ID collision in idmap_rid backend for local account "nobody" and RID 45534 in the AD environment.

 

[pcubed]

85534

Please excuse me a slight correction, the UID for nobody is 65534. I just wanted to mention this for any future readers (like myself) who went looking for a user with this ID.

 

[anodos]

Please excuse me a slight correction, the UID for nobody is 65534. I just wanted to mention this for any future readers (like myself) who went looking for a user with this ID.

There's a difference between a RID and Unix ID. A RID is the last component of a Windows SID.

 

[pcubed]

There's a difference between a RID and Unix ID. A RID is the last component of a Windows SID.

Certainly! Perhaps I misunderstood, but I thought your response on December 7th was saying that since the local UID on the server of the AD domain users (e.g. MYDOMAIN\someuser) is obtained by taking IDs in the range specified by the idmap + the RID. Therefore, there is a possible collision between the user nobody with UID 65534.

For example, in an old existing FreeNAS install, the idmap range was 20000-20000000 and so when one runs getent passwd, the UIDs of the domain users are the RID + 20000 (for example, the domain admin is 20500). However, if we had had a ton of users in this domain, there would've been a risk that one of them has the UID 65534 and thus collides with the built-in account nobody.

I apologize if I am mistaken, but I'm hoping that my understanding is correct.

 

[anodos]

This is the structure of an ACL entry in FreeBSD's VFS:

Code:

struct acl_entry {
    acl_tag_t        ae_tag;
    uid_t            ae_id;
    acl_perm_t        ae_perm;
    /* NFSv4 entry type, "allow" or "deny".  Unused in POSIX.1e ACLs. */
    acl_entry_type_t    ae_entry_type;
    /* NFSv4 ACL inheritance.  Unused in POSIX.1e ACLs. */
    acl_flag_t        ae_flags;
};
typedef struct acl_entry    *acl_entry_t;

Note that ae_id is `uid_t` and not a string for a username. This means access is allowed based in id. If you have two users with the same uid, then they will generally have the same access to the underlying files. I did have a typo above. RID would be 45534 in this case. This is probably not an issue in your case, but overall it's good to have defaults that don't have edge-case considerations. This is probably the third or fourth time that FreeNAS has changed its defaults WRT idmap_rid range.

Our idmap settings are configurable so that users can do what is correct for their environment, and the correct action for any admin is to first determine how Unix clients /servers are configured in their environment and set FreeNAS / TrueNAS accordingly.