FreeNAS AD not accepting groups

[CMDR Sweeper]

Well I had a Freenas 8.3.0 that worked flawlessly with Active Directory, but the new ZFS features was alluring.
Back then it was running 4Gb of RAM and 4x 3 Tb drives in RAID 5, however now it is upgraded to the maximum it can support which is 8Gb of RAM.
Well after the update it has gotten wonky with the AD domain controller, what has happened is that it works fine with assigning users from the AD to the shares, but groups... Forget about it.
The domain controller is a Samba 4 virtual server, and it lives in a home environment, the FreeNAS box isn't the main storage right now, as it is still in evaluation, so while it does have data on it, it also exists on another storage medium.

The commands wbinfo -t lists the RPC call to my domain as succeeded.
wbinfo -g and wbinfo -u all post the groups and users as they would be expected to.
getent passwd posts the expected user info from the DC as well as the standard local users.
getent group however is where I notice the first failure, it lists the local users, but fails when trying to list the domain users with:
"Assertion failed: (chain != NULL), function ldap_first_entry, file getentry.c, line 36. Abort"

Any clue as to what the problem is?
This is a home based experimental domain controller setup, so the amount of groups and users is very low, but I am experimenting with it to use as a main means of controlling access, although it has been in evaluation for over a year so far (Not pushing it out until I am confident everything works as solid as my present Ubuntu 10.04 LTS server)
So anyone got any fixes for this? I am assuming PAM is the culprit here.

 

[Chris Hoefler]

No, not pam. I had the same problem. It is with nss_ldap. When you select "UNIX extensions" in the config menu, FreeNAS sets up to use pam_ldap for authentication and nss_ldap for identification. If you look in your logs you will probably see "NSS failed to connect to LDAP server" messages. For me, this is because the domain controller doesn't allow unauthenticated binds, and there is no way to specify a bind account in the current AD config panel. So I worked around it by first deselecting "UNIX extensions". This will set up FreeNAS to use pam_winbind and nss_winbind. Then configure the winbind backend as follows,

idmap config * : range = 1000-2999
idmap config * : backend = tdb
idmap config DOMAIN: range = 3000-30000000
idmap config DOMAIN: backend = ad
idmap config DOMAIN: schema_mode = rfc2307
idmap config DOMAIN: default = yes

This will enumerate all AD users/groups using their Unix attributes. However, the primary group of your accounts has to have a gidNumber attribute. So I just created a new group and gave it a gidNumber, and then changed the primarygroupid from "Domain Users" to my new group. You could also add the gidNumber attribute to "Domain Users".

There are probably other ways to handle this, but it worked for me.

 

[dlavigne]

Please create a feature request at bugs.freenas.org and post the issue number here.

 

[CMDR Sweeper]

Please create a feature request at bugs.freenas.org and post the issue number here.

I suppose I could, but I am afraid I cannot provide too much information as to what is going wrong here, unless you already have a clear idea.

Unless it is related to the classic Windows AD issue that it doesn't allow anonymous LDAP lookup requests, but I thought FreeNAS worked around that by using the Admin account provided for that purpose?

 

[dlavigne]

It looks like #3286 was created but has been deferred. Does the work-around Chris Hoefler provided fix your issue? If not, it may be a separate issue.

 

[CMDR Sweeper]

It seems to work now when put in "Aux parameters" for the Samba plugin in the web interface (Not too sure about messing too much around with the configs and having the GUI play well with it)
Preliminary tests don't let me view the share yet, but it may need a restart... But I got another issue I need to solve first, I got a dead harddrive that needs to be replaced, and sadly FreeNAS hasn't remembered its serial number so I will have to search for it.
Basically find the ones I know, and the remaining drive is then the dead one.

 

[Chris Hoefler]

Bug report created,
https://bugs.freenas.org/issues/4122

 

[l377r1ch]

@Chris Hoefler,

great to see, that someone managed to get a workaround running, while the devs get sssd running - it was driving me crazy. Can you give a hint to someone who recently switched from an ordinary linux system, how you changed your smb4.conf? Did you remove or edit any other parameters in the smb4.conf?
Obviously normal editing via command line does not work. For me, neither does "Auxiliary Parameters" in the GUI - which ends up with the following smb4.conf, containing duplicates and presumably some errors.

Help would be greatly appreciated.

Code:

[global]
    server max protocol = SMB3
    encrypt passwords = yes
    dns proxy = no
    strict locking = no
    oplocks = yes
    deadtime = 15
    max log size = 51200
    max open files = 11070
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
    getwd cache = yes
    guest account = nobody
    map to guest = Bad User
    obey pam restrictions = Yes
    directory name cache size = 0
    kernel change notify = no
    panic action = /usr/local/libexec/samba/samba-backtrace
    server string = NAS Server
    ea support = yes
    store dos attributes = yes
    map archive = no
    map readonly = no
    map hidden = no
    map system = no
    hostname lookups = yes
    unix extensions = no
    acl allow execute always = true
    server role = member server
    netbios name = NAS
    workgroup = DOMAIN
    realm = DOMAIN.HOME
    security = ADS
    client use spnego = yes
    cache directory = /var/tmp/.cache/.samba
    local master = no
    domain master = no
    preferred master = no
    acl check permissions = true
    acl map full control = true
    dos filemode = yes
    idmap uid = 10000-19999
    idmap gid = 10000-19999
    winbind cache time = 7200
    winbind offline logon = yes
    winbind enum users = yes
    winbind enum groups = yes
    winbind nested groups = yes
    winbind use default domain = no
    winbind refresh tickets = yes
    allow trusted domains = no
    template shell = /bin/sh
    template homedir = /home/%D/%U
    idmap config DOMAIN: backend = rid
    idmap config DOMAIN: range = 20000-20000000
    pid directory = /var/run/samba
    smb passwd file = /var/etc/private/smbpasswd
private dir = /var/etc/private
    create mask = 0666
    directory mask = 0777
    client ntlmv2 auth = yes
    dos charset = CP437
    unix charset = UTF-8
    log level = 2
    idmap config * : range = 1000-2999
    idmap config * : backend = tdb
    idmap config DOMAIN: range = 3000-30000000
    idmap config DOMAIN: backend = ad
    idmap config DOMAIN: schema_mode = rfc2307
    idmap config DOMAIN: default = yes

​

 

[Chris Hoefler]

So, it looks like they've switched to winbind+ad for the unix extensions setup,
https://bugs.freenas.org/issues/4122

You shouldn't have to do this any more. Do you have unix extensions in your AD?

 

[l377r1ch]

Yeah, I've also seen this - unfortunately it did not work as expected.
- 2012 R2, unix extensions enabled and added to relevant users and groups.
- FreeNAS 9.2.1.5 unix extensions switched on: uids and gids are enumerated correctly, still "NSS failed to connect to LDAP server" error message.
- when reviewing permissions on files, windows users see those users as "unixuser/<UID Number here>", and can map them to the appropriate user in AD. Also I can observe some wired behaviour when unix extensions are enabled and the dataset is set to unix acl, as suddenly completely random groups are given access to files created by clients.


I currently don't have any access to the box, but I will provide more details this evening.

 

[Chris Hoefler]

When you have access to the server, check a couple of things. What is the output from testparm? And what is in /etc/nsswitch.conf?

Also, what is the uid/gid number range of your AD users and what are the uid/gid numbers of the "random groups" on your files? I think I know the reason for this behavior, but I just want to be sure my hunch is correct.

 

[l377r1ch]

OK, so with NO unix extensions set in the active directory configuration and no further "tweaks" in the cifs auxiliary parameters, I get

Code:

#testparm
 
Load smb config files from /usr/local/etc/smb4.conf
max_open_files: increasing sysctl_max (11095) to minimum Windows limit (16384)
rlimit_max: increasing rlimit_max (11095) to minimum Windows limit (16384)
WARNING: The "acl check permissions" option is deprecated
WARNING: The "idmap uid" option is deprecated
WARNING: The "idmap gid" option is deprecated
Processing section "[homes]"
Processing section "[myShare1]"
Processing section "[myShare2]"
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

and

Code:

# less /etc/nsswitch.conf
group: files winbind
hosts: files dns wins
networks: files
passwd: files winbind
shells: files
services: files
protocols: files
rpc: files

According to /usr/local/etc/smb4.conf
idmap uid = 10000-19999
idmap gid = 10000-19999
idmap config DOMAIN: backend = rid

idmap config DOMAIN: range = 20000-20000000


in AD backend, uid and gid both start at 10000.

When I ENABLE unix extensions in the freenas ad configuration menu, I immediately get
"nss_ldap: could not search LDAP server - Server is unavailable"

uid and gid of ad users then are enumerated correctly, as set in active directory.

config changes to

# less /etc/nsswitch.conf
group: files ldap
hosts: files dns wins
networks: files
passwd: files ldap
shells: files
services: files
protocols: files

rpc: files

and /usr/local/etc/smb4.conf
idmap uid = 10000-19999

idmap gid = 10000-19999

with
idmap config DOMAIN: backend = rid

idmap config DOMAIN: range = 20000-20000000
GONE.

The output from testparam does not change in any way.

As described in the last post, everything seems fine, until you start using samba shares with unix acls.
- windows sees users as "unixuser/<UID Number here>"
- random uids and gids have permissions set
- if acls are "corrected" in windows, users can read and create/copy files, but not write/modify (unix acl 770).
- files created by windows users are sometimes mapped to the wrong uids/gids so that unix users have no access to files.

 

[Chris Hoefler]

Ok, so it appears they are still using nss_ldap for uid/gid mapping when unix extensions are enabled, which is why you are getting the error message (I'm still using the old version). Unless you have shell accounts on your FreeNAS box, this is not necessarily a problem. It works like this,

1. File is owned by FreeNAS filesystem, which assigns permissions using unix uid/gid numbers
   1. With Unix Extensions enabled, the uid number comes from the uidNumber attribute in AD
   2. Without Unix Extensions, the uid number is generated by Winbind
   3. The ACL setting only affects the set of permissions available, it does not affect the owner uid/gid number assigned
2. A Windows client will map the unix uid/gid number to an AD user via Samba (whether Winbind is in effect or not does not matter)
3. A *nix client will read the uid/gid number and map it via whichever mechanism it uses (files, ldap, sssd, whatever).

So, whether or not FreeNAS itself can map users does not really matter when FreeNAS is used as a file server. For SSH, the mapping may not work, but since everything is based on the uid/gid number (not the uid/gid itself) it doesn't affect functionality, just aesthetic. Nevertheless, if you want the error to go away, you need to use a keytab to bind to the AD,
http://doc.freenas.org/index.php/Directory_Services#Using_a_Keytab

That's the only way to do it in the GUI at the moment. You can hack the config files manually, but it is a pain and not upgrade-safe.

My workaround was for when keytab binding was not supported. You can still use it if you want, but I think the keytab binding is easier. The logic is, start with Unix Extensions disabled so that FreeNAS sets nsswitch to use winbind. Then tell winbind to use the unix attributes stored in the AD instead of mapping. When you do this, you end up with duplicate idmap xxx parameters in your smb.conf. This is ok. The latter parameters, which are the ones you set in "cifs auxiliary parameters", will override the former parameters, which are set by the FreeNAS config. It is an ugly hack, but it works and is upgrade-safe. A couple of notes,

1. idmap config DOMAIN: range has to align with the uid/gid number range in your AD. So if uidNumbers start at 10000, this range needs to start at 10000.
2. idmap config *: range cannot overlap with the DOMAIN range. So in your case, it has to end at some point less than 10000.

- windows sees users as "unixuser/<UID Number here>"

This is normal, when Unix Extensions is enabled. The attributes pulled from AD in this case are uid and uidNumber. With winbind enabled, the attributes pulled are sAMAccountName and objectSid (which gets mapped to a unique uidNumber internally).

- random uids and gids have permissions set

You didn't say which uids/gids, but this is most likely because Windows clients create files with inherited ACLs, which include ACLs for various system users. You may or may not have uidNumber attributes set for these system users. If you do, they will be used. If not, winbind will map them for you to the idmap config *: range. If you set that range to, for example 1000-10000, this will not collide with the system accounts on a typical Unix system and won't be a problem. It does mean you will see random uid/gid numbers that are unmapped when you ls -l the file from a Unix client, though.

Summary,

1. AD users with uidNumber attributes 10000-100000 will be handled by idmap config DOMAIN: backend=ad
2. System users from your Windows clients will be handled by idmap config *: backend=tdb and will be assigned numbers in the range 1000-10000
3. Unix clients will resolve these uid numbers by first talking to ldap (assuming that is the backend you have configured). If it is a >10000 user, this should resolve correctly. If it is a <10000 user, there is no entry in ldap for that uidNumber so it moves to its fallback (usually files). /etc/passwd usually doesn't have any system users with uid numbers >1000, so there will not be a collision, but it leaves the uid number unmapped to a uid.
4. Windows clients may or may not resolve the system users. It depends on how the ACL inheritance is set up. If you inherit system users from the AD, it will resolve. If you inherit system users from the local machine, it won't.
5. Unmapped uid numbers don't affect functionality or security (unless there is a collision).

- if acls are "corrected" in windows, users can read and create/copy files, but not write/modify (unix acl 770).

This is a deeper problem. Can you identify a specific case and provide the following information?

1. Is the Windows user an AD user? (I'm assuming yes)
   1. Is the Windows client joined to the domain? (I'm assuming probably, but not necessarily)
   2. Is the file sharing user the same as the logged in user? (Again, probably but not necessarily)
2. Is the Unix user the same AD user? (Also assuming yes)
3. How is the Unix client talking to AD? (ldap, sssd, ???)
   1. Is it working properly? (ie: can you enumerate users/groups with getent?)
4. How is the Unix client talking to FreeNAS (nfs, samba, sftp, ???)
5. What do you see in the permissions tab on the Windows client?
6. What is the output of the commands (ls -l, ls -n, getfacl) on the Unix client?
7. What is the output of the commands (ls -l, ls -n, getfacl) on FreeNAS?

There is a conflict somewhere with how the uid numbers are being assigned to the files and interpreted by the clients, so we just have to make sure everything is consistent.

- files created by windows users are sometimes mapped to the wrong uids/gids so that unix users have no access to files.

This is probably related to the above problem, so provide as much information as you can and we can try to figure out what is wrong.

Now, all of the above said, the absolutely easiest and pain-free setup is to not use Unix attributes in the AD. Unless you have a specific need, set up Samba to use Winbind with no modifications. Your Unix clients can do the rid mapping consistently with Samba if you are using sssd. You just need to configure it.
http://manpages.ubuntu.com/manpages/raring/man5/sssd-ad.5.html
(see the ldap_idmap_autorid_compat option under "Advanced Configuration")