SMB Windows Domain Users Access Denied after 11.3 Update

[geoff.jukes]

@anodos For my part, I have:

1. Reset all the SMB shares to the new defaults (ixnas,streams_xattr)
2. Removed all share aux parameters (except `follow symlinks=yes` and `wide links=yes`)
3. Removed all Samba aux parameters (except `unix extensions=no`)
4. Enabled SMB1 support (for legacy clients)
5. Removed and re-joined the Domain
6. Removed ALL Tunables

I keep going to the CentOS client, because it's easy to script and monitor, and I can open/close connections at will. But I do want to make it clear that we are now having issues with BOTH servers, and ALL clients.

On the CentOS client, I have confirmed that there is no client-side difference for a mount instance that works, and a mount instance that throws "Permission Denied".

The only setting I can see that is currently unset on SMB, is the `Administrator Group` which I'm going to set now.

Aside from that, the only pattern that I think I have seen is that it would appear to relate to sessions. It is most certainly not an ACL issue (in-so-far as the ACL itself, but I wouldn't rule out a SAMBA issue realted to reading the ACLs).

I'll keep watching the logs, and see if I can find anything useful - but at this point I am convinced that there is a bug in 11.3.

For now, the "fix" is to restart SMB, and toss a coin.

 

[thomisus]

If this is an issue post upgrade, you might have a caching issue in winbind (stale entries for CREATOR-OWNER and GROUP). Try running "midclt call idmap.clear_idmap_cache"

I have replicated the access denied error in my home lab environment. I have setup everything from scratch ( AD 2016 vm, win10 vm, freenas vm with ad integration )
My test user is member of Domain Users ( built-in ) and Production group ( this is a new group )
If I set ACL on the share to allow access to Domain Users I can connect to \\freenas\test , \\ipaddress\test or \\freenas.home.lan\test
If I set ACL on the share to allow access to Production group I can connect to \\ipaddress\ test but not \\freenas\test and viceversa.

 

[anodos]

I have replicated the access denied error in my home lab environment. I have setup everything from scratch ( AD 2016 vm, win10 vm, freenas vm with ad integration )
My test user is member of Domain Users ( built-in ) and Production group ( this is a new group )
If I set ACL on the share to allow access to Domain Users I can connect to \\freenas\test , \\ipaddress\test or \\freenas.home.lan\test
If I set ACL on the share to allow access to Production group I can connect to \\ipaddress\ test but not \\freenas\test and viceversa.

I identified the issue. It's related to support for "Microsoft Accounts". Try setting the following auxiliary parameter under Services->SMB and restarting the SMB service:

username map =

 

[thomisus]

I identified the issue. It's related to support for "Microsoft Accounts". Try setting the following auxiliary parameter under Services->SMB and restarting the SMB service:

username map =

Unfortunately does'nt fix my problem.
I tried to understand why using 'Domain Users' in ACL works and using 'Production' group ( custom AD group) sometimes doesn't work. Looking at debug info seems that samba checks only the primary group. If i set in Windows Server 2016 'Production' as primary group instead of 'Domain Users' I have no errors. This is a little step in the right direction.

 

[thomisus]

Ok, i was wrong because I put this in the SHARE aux parameters. Setting this in Services -> SMB did fix the problem!!

username map =

Is it possible in the next update make it default when using active directory? Or maybe write it in the troubleshooting section of the docs? I think it could help many users.

Thank You so much!

 

[geoff.jukes]

Is it possible in the next update make it default when using active directory? Or maybe write it in the troubleshooting section of the docs? I think it could help many users.

Thank You so much!

@anodos sent me an updated smb4.conf, which fixed all my issues. I didn’t want to post here until they had. The only change in the file is (in essence) is the usermap. So I’m assuming that it will be in the next update.

 

[Eniqmatic]

Can confirm that:

Code:

username map =

Also resolved the issue we were seeing on 2 machines we upgraded. Thanks guys!

 

[Jedi940]

This also fixed my issue. What exactly is this command doing?

 

[anodos]

This also fixed my issue. What exactly is this command doing?

It's restoring a parameter to its default value. There's an old hack in the FreeNAS to "Microsoft accounts" to access SMB shares without being prompted for passwords. Basically, if a user authenticates to their home windows box using their credentials for "bob@outlook.com", then Windows 10 will try to use these credentials "bob@outlook.com" to authenticate to the FreeNAS server. If a user creates a local account "bob", inputs an email address of "bob@outlook.com", and checks the "Microsoft Account" checkbox, then a username map entry is generated "bob = bob@outlook.com". This causes samba to map their credentials to the local Unix "bob" account, and authentication seamlessly-ish works.

In some situations, it appears that the presence of the username map file (even if it's empty) and smb4.conf parameter pointing to it, will trigger a race condition and cause authentication attempts to intermittently fail.

 

[brian5678]

A quick summary. I have been USING a Freenas 9.x for years. I built a new server with Freenas 11.3 about a month ago. Over the last week, I have been using the server regularly from multiple windows10 and windows8 clients into a zfs directory set to 777 privs. Yesterday, at the end of the day, my "map network drive" location just stop out of blue in allowing me to make changes to it. I have spend all morning trying to come up with a fix.

I have attempted the "username map = " fix by adding it to the "Aux Parm" in Services->SMB in Freenas web gui. BUT it does not appear the running smb server is getting the change, because it is not listed by testparm tool.

from smb4.conf

Code:

]# more smb4.conf
#
# SMB.CONF(5)           The configuration file for the Samba suite
# $FreeBSD$
#


[global]
        dns proxy = No
        aio max threads = 2
        max log size = 51200
        allocation roundup size = 0
        load printers = No
        printing = bsd
        disable spoolss = Yes
        dos filemode = Yes
        kernel change notify = No
        directory name cache size = 0
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        unix charset = UTF-8
        log level = 1
        obey pam restrictions = False
        enable web service discovery = True
        logging = file
        server min protocol = SMB2_02
        unix extensions = No
        map to guest = Bad User
        server string = FreeNAS2 Server
        bind interfaces only = Yes
        netbios name = freenas2
        netbios aliases =
        server role = standalone
        workgroup = WORKGROUP
        idmap config *: backend = tdb
        idmap config *: range = 89999984-100000000
        username map =

        include = /usr/local/etc/smb4_share.conf

from testparm

Code:

# testparm
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
        aio max threads = 2
        bind interfaces only = Yes
        disable spoolss = Yes
        dns proxy = No
        enable web service discovery = Yes
        kernel change notify = No
        load printers = No
        logging = file
        map to guest = Bad User
        max log size = 51200
        netbios name = FREENAS2
        nsupdate command = /usr/local/bin/samba-nsupdate -g
        server min protocol = SMB2_02
        server role = standalone server
        server string = FreeNAS2 Server
        unix extensions = No
        idmap config *: range = 89999984-100000000
        idmap config * : backend = tdb
        allocation roundup size = 0
        directory name cache size = 0
        dos filemode = Yes
        include = /usr/local/etc/smb4_share.conf


[Media]
        aio write size = 0
        ea support = No
        guest ok = Yes
        mangled names = illegal
        ...

 

[brian5678]

Other additional information is that I can still create new directories and new files; but I can no longer edit file content or filenames, or delete files or directories.