Large AD inconsistent permission issues

[eexodus]

I have FreeNAS 11.3 joined to an AD environment with over 50,000 users. At first this was too much for FreeNAS, but after checking "Disable FreeNAS Cache" most users haven't had any issues. However, a few newer users are having inconsistent permission issues. Permissions are managed by groups. Even though the new user gets added to the correct group and in FreeNAS command line I can "id username" and confirm FreeNAS is seeing them in the right group, they get permission errors when mounting the SMB/CIFS shares. The only reliable workaround I've developed is using the web UI facl editor to add that specific user to the share's permissions. This obviously isn't ideal--each share should give a group access and not individual users.

Looking at Samba logs I'm getting a lot of "pam auth crap domain" for all users, but I don't think this is the cause because most users are getting pam auth crap domain errors. I suspect this is because my organization has a split parent-child domain and FreeNAS is first trying the wrong domain and then the second correct domain. FreeNAS and computers are on the child domain--users are on the parent domain.

I'm seeing winbind and check_ntlm_password authentication for the affected users succeeding so it almost seems like its a facl issue?

 

[anodos]

Is this on 11.3 or 11.3-U1?

 

[eexodus]

Is this on 11.3 or 11.3-U1?

11.3-RELEASE unfortunately haven't had time to update to 11.3-U1 as its production--I likely can this weekend though.

 

[Patrick M. Hausen]

Does FreeNAS support paged results? If not, you may need to increase a particular limit in your AD. I don't remember from the top of my head - it's been a while.

 

[anodos]

11.3-RELEASE unfortunately haven't had time to update to 11.3-U1 as its production--I likely can this weekend though.

If it's working (mostly) on 11.3 RELEASE, then don't bother updating until U2 comes out. Try adding the following aux parameter under Services->SMB and see if it clears up the issue username map =. Note that this will cause the SMB service to restart and so should be done at an appropriate time.

 

[amp88]

11.3-RELEASE unfortunately haven't had time to update to 11.3-U1 as its production--I likely can this weekend though.

Whatever you do, NEVER update to 11.3-U1. There was a bug introduced in it where files copied over SMB have their last modified/created dates overwritten with the file copy date. On a large deployment such as yours (with 50k users) it would wreak havoc. Wait for 11.3-U2, where it's supposed to be fixed...

There's more information in this thread.

 

[Ionicdude]

I'd like to start by saying thanks for all of your hard work anodos. The recent improvements to samba in FreeNAS have been phenomenal.

I have been facing some strange permissions issues similar to what was reported by eexodus and I have been banging my head against it for a few days. Our ad domain only has 200 users but I'm seeing two specific issues:

1. Permissions sometimes only observe the ad default group even though the pool is using smb acl's. One example is my admin account would randomly not have access to the IT share at log on. I fixed this by setting the default group to 'domain admins'.
2. Same dataset shared two ways in smb sharing and users can only access one location.

We're using 11.3 release and I'm not sure if we will be able to restart smb anytime soon because reasons. I'm making an effort to be thorough in my troubleshooting before I share specifics but I just wanted to chime in because my issue sounds pretty much the same. I suspect that either I have found some permission bug or have created a heinous configuration mishap and I can serve as a cautionary tale.

 

[eexodus]

username map =

I implemented this. Its an inconsistent issue affecting random users though so only time will tell if it helped.

There's more information in this thread.

Thanks for the tip, I'll wait for 11.3-U2. Although FreeNAS is joined to a 52k user domain only ~100 users in my small area in the organization interact with it.

 

[anodos]

I'd like to start by saying thanks for all of your hard work anodos. The recent improvements to samba in FreeNAS have been phenomenal.

I have been facing some strange permissions issues similar to what was reported by eexodus and I have been banging my head against it for a few days. Our ad domain only has 200 users but I'm seeing two specific issues:

1. Permissions sometimes only observe the ad default group even though the pool is using smb acl's. One example is my admin account would randomly not have access to the IT share at log on. I fixed this by setting the default group to 'domain admins'.
2. Same dataset shared two ways in smb sharing and users can only access one location.

We're using 11.3 release and I'm not sure if we will be able to restart smb anytime soon because reasons. I'm making an effort to be thorough in my troubleshooting before I share specifics but I just wanted to chime in because my issue sounds pretty much the same. I suspect that either I have found some permission bug or have created a heinous configuration mishap and I can serve as a cautionary tale.

This is symptomatic of an issue I fixed. You can apply the workaround above with "username map=" (which will automatically restart the SMB service) or you can wait for U2.

 

[Ionicdude]

This is symptomatic of an issue I fixed. You can apply the workaround above with "username map=" (which will automatically restart the SMB service) or you can wait for U2.

Thanks anodos! I decided to implement this last night and early tests indicate that our issues are resolved. I'll be testing this more next week but I'm feeling confident.

 

[eexodus]

or you can wait for U2.

Before I upgrade to U2.1 can you confirm "username map=" is no longer needed? For what it's worth "username map=" has appeared to fix the issue I originally reported.

 

[anodos]

Before I upgrade to U2.1 can you confirm "username map=" is no longer needed? For what it's worth "username map=" has appeared to fix the issue I originally reported.

That should no longer be need. You can verify by upgrading, removing the parameter, and running the following command:
midclt call smb.getparm "username map" global
Expected return if the parameter is correct is an empty string.