The EDIT IDMAP dialogue allows it to wrongfully configure the default types, but doesn’t give you a chance to fix it.

I replicated an old Freenas 11 box to a new Truenas 12 one. Additionally I set up Active Directory integration using RID mapping. Unfortunately the default ranges for RID mapping differ vastly from the old Freenas 11 installation, leaving me with mismatched users on the new box.

To fix the issue I tried to lower the DS_TYPE_ACTIVEDIRECTORY range to my previous values, which results in an error as the range overlaps with the default DS_TYPE_DEFAULT_DOMAIN (TDB) range.

Hence I tried adapt the DS_TYPE_DEFAULT_DOMAIN range for the TDB backend. Saving the changes is only possible after the DNS Domain name is filled in, although it was empty by default and isn’t necessary. But even then I couldn’t save as an error message appears:
idmap backend [TDB] is not appropriate. for the system domain type DS_TYPE_DEFAULT_DOMAIN

As I seemed to be stuck, I changed the backend from TDB to LDAP for the DS_TYPE_DEFAULT_DOMAIN, which in turn required some additional fields like URL, Base DN etc. To save the edited range I filled in “fake” values in these fields (since LDAP didn’t make any sense and wasn’t used, it seemed like a good idea).

Finally I was able to adjust the RID-Range for DS_TYPE_ACTIVEDIRECTORY. But the AD-Service obviously didn’t work correctly anymore with this configuration as it tried to use the (wrong) LDAP values (although I don’t see why they were used at all).

Unfortunately the GUI doesn’t allow me to change back to TDB for the DS_TYPE_DEFAULT_DOMAIN, as it shows the same error message mentioned above.

My only possible (short term) solution was to enable the service in the idmap.py plugin of the middlewared. I added AD to the list of services, which circumvents the wrong “validation”:

TDB = {
'description': 'Default backend used to store mapping tables for '
'BUILTIN and well-known SIDs.',
'parameters': {
'readonly': {"required": False, "default": False},
},
'services': [' AD' ,'LDAP'],
}

This way I was able to change back to TDB so that Activedirectory was working again. The only cosmetic shortcoming is the required DNS Domain Name value, which doesn’t seem to be necessary – but does no harm with a fake value either.

To sum up:

• It is confusing to have TDB as DS_TYPE_DEFAULT_DOMAIN while showing an error message that says TDB is not appropriate for this type on validation

• The default ranges can’t be changed as the DS_TYPE_DEFAUL_DOMAIN can’t be changed, leading to overlapping ranges

• It’s impossible to change back to TDB for DS_TYPE_DEFAULT_DOMAIN