I am running the nightly version of Halfmoon (26.04) of Truenas and having Multiprotocol shares which are shared with both SMB and NFS.
We are seeing files created by users with a long user id which maps to Windows AD users. So, I tried to configure the IDMAP domain and specify a range of IDs to use and using the AD RFC2307 backend.
This works fine during configuration and saving. However in the UI the domain users are never cached or listed.
I can see the users with wbinfo -u. But the UI does not cache or populate the user ids even after rebuilding the cache.
I am not sure what the problem is. I tried unjoining, rebooting, rejoining etc but nothing has helped.
The only configuration that works is “Use TrueNAS Server IDMAP Defaults” which uses the RID IDMAP backend.
I also came across this using the AI search of Truenas
However, this is not present in the 26.04 (Halfmoon) version of the UI that I am using. So I cannot follow this instruction in my environment.
Can someone please help me analyze what the problem is and why that AD RFC2307 backend configuration does not work?
I am attaching a screenshot of what I am selecting when this problem surfaces.
Please ask me for any information regarding this if needed, I can provide it as long as it does not need a reboot.
Thank you for the current documentation link. I went through it and find that I have followed what the documentation says about configuring Truenas for AD use.
I have a doubt on how we set the Range Low and Range High for IDMAP configuration when not using the default.
I tried using IDMAP backend as AD and the range low as 1100 and range high as 2000000 and it gets saved/applied. However post saving this configuration and even a reboot after this, the cache that populates the domain users does not happen and if we edit the ACL in any share shared using SMB, the domain\user never resolves. It does not show up in the list of users/groups.
However in the shell wbinfo -u lists all the domain users that it can fetch from the domain.
Can I have some direction on how I find out about what I am doing wrong and correct it?
As I mentioned, I am trying to keep the Windows uid/gid as closely matched to the uid/gid we are using for mapping users in NFS.
We have many shares shared as multiprotocol shares and the uid/gid is very different when these shares get written into by Windows.
If any more information is needed from me, please let me know.
You have to fully populate the relevant attributes in AD. if you’re missing gid assignments for instance for domain users, it will obviously break idmapping. Seeing wbinfo -u or wbinfo -g output simply means that winbindd can enumerate users / groups in your domain.
It doesn’t mean that it can do anything useful with them / the attributes you’ve populated (this is where the nss getpwnan /getgrnam calls come in).
Hi, thanks for the reply
I have enabled the Advanced Attribute editing and added the uidNumber and gidNumber attributes for the AD user to match what is expected in Unix/NFS.
I can do this for all the users, but it has been done for some users which can be tested at first to see if they work.
However even these users dont show up after these changes I spoke about.
Is there some document on what attributes in the AD user need to be populated so that IDMAP does not break? I can follow that and test to be sure I am doing it correctly.
If not please give me some information on what attributes need to be populated/added. I will do that and check to see that IDMAP works correctly.
The only way rfc2307 could at this point to be implemented is to use RID schema in TrueNAS with id’s copied to Samba Users Unix attributes via ‘Active Dirrectory users and computers’ RSAT tool. Tried AD with rfc2307, plain rfc2307 and LDAP without success.
In many cases there are service and other non-shell-access type of users that make the RID schema approach uncomforting due its functionality to grant shell access to ALL users.
With servers still on AD - rfc2307 approach and the ID’s of users with login rights to those servers modified with RID ID’s (mathematically calculated from Windows user login) for uidNumber and gidNumber unnecessary login rrights can be prevented. One needs to take care of file rights on home folders and elsewhere though.
I don’t see this issue. Have successfully used powershell / AD users and computers to populate relevant attributes. The key thing to remember is that you must provide full attribute details for all groups user is member of (including its primary group) as well as populating all relevant user details. If the NSS backend can’t determine an attribute then it won’t appear in lists / getent passwd output.
That the user details according to samba are uidNumber gidNumber default shell and home directory that the Group has gidNumber per Samba Wiki. They are filled no user in list and re-run of ActiveDirecory setting met with empty value on Schema mode.
Can you let me know which attributes you populated for the user in AD and how it was visible in the command line of the truenas server?
I could try this at my end too and see if it helps.
I am assuming you have the truenas directory services configured to use the AD/SFU attributes from Active directory as the IDMap backend?
I have TrueNAS connected to Samba Version 4.19.5-Ubuntu acting AD domain controller and TrueNAS now in RID mode. Tried the AD mode with schema RFC2307 without success. The ‘Unix Primary Group’ and ‘Unix NSS Info’ tick marks do not change or interact with ‘/etc/smb4.conf’ and I presume the Schema selection is not interacting either.
Hi, thanks for this info. I was not aware that this happens. I will give this a try and see what happens. Maybe I can edit the file manually and see if that helps.
Did it work for you setting that to true manually in the file?
