Uploaded image for project: 'TrueNAS'
  1. TrueNAS
  2. NAS-106906

smb4.conf misconfigured after restart when LDAP and AD services enabled



    • Bug
    • Status: Engineering Closed (View Workflow)
    • Low
    • Resolution: Not to be Fixed
    • 11.3-U4
    • N/A
    • Directory Services
    • None
    • Medium


      I am running FreeNAS 11.3-U4, and I need to use two different sources of user/group identity: an Active Directory domain, to which I serve SMB shares, and a FreeIPA domain, to which I serve NFS shares. For the AD side, I have configured "Active Directory" directory services in FreeIPA, using an RID backend. For the FreeIPA domain, I have configured LDAP directory services, using account credentials in the FreeIPA domain to do the ldap bind.

      Either one works perfectly when the other is disabled. Both also work perfectly when both are turned on PROVIDED I have LDAP initially disabled, and then manually enable it (through the GUI) after the AD service is running.

      However, if I let the FreeNAS system reboot, or restart the smb service or the AD directory service while LDAP is enabled, it corrupts the /etc/local/smb4.conf file.

      Specifically, it omits the lines that would configure the RID backend. So, instead of the desired lines:

              idmap config *: backend = tdb
              idmap config *: range = 10000-99999
              idmap config ANL: backend = rid
              idmap config ANL: range = 10000000-19999999

      I have the incorrect configuration:

              idmap config *: backend = tdb
              idmap config *: range = 10000-99999

      Ie, it uses the default tdb backend and default range for the AD service too, instead of the desired RID backend and range. This completely screws up everything, and moreover, once SIDs from the AD domain get mapped to IDs in the tdb file /var/db/system/samba4/winbindd_idmap.tdb, then they take precedence over the RID backend, even if LDAP is turned off and the samba services restarted to correct the smb4.conf file. To recover, I have to clean out the winbindd_idmap.tdb file.

      I have checked, and this is true for other backends as well, for example autorid. Having both AD and LDAP directory services enabled results in a smb4.conf file that lacks the idmap definitions belonging to the AD service.

      It seems to me there is something wrong with the middleware code that is generating smb4.conf when both LDAP and AD directory services are enabled.

      As a workaround, I believe I can insert the desired idmap definitions into the "Auxilliary Parameters" section of the smb service GUI configuration. But this is a hack.

      Can someone review the middleware code that generates smb4.conf?









                releng Triage Team
                dhp David Potterveld
                1 Vote for this issue
                3 Start watching this issue