CIFS ZFS ACL Active Directory not working

Status
Not open for further replies.

Ronald122

Cadet
Joined
Feb 14, 2012
Messages
1
Hello,

I searched around this forum but couldn't find something useful for my issue.

I had created a ZFS volume and a dataset. After that I activated the Active Directory Service and joined the domain without problems.

After looking for help in this forum I found an command (I forgot the name) which shows me, that FreeNAS got all domain users and all groups even with the right members so I think this part worked without any problems.

After this, I went to the dataset-permissions and set the following:
Owner = domain\administrator
group = domain\somegroup
rights=770
Windows-style-ACL

After finishing this options I re-opened the dataset-permissions. Everything was changed, but the group is still "wheel".

Now I opened SSH and set "chgrp -R domain\\somegroup dataset-name" now it seems to be ok.

When using Windows 7 and logging in as domain\administrator I can use the share and write/delete/list everything. When using an other account, who is member of the group I can't access the share (althoug the permission is set to 7 for the group) --> permission denied.

Now I did a new start and typed (SSH) find . -type f -exec setfacl -b {} \; and the same for the directories to reset the permissions. Nothing of the behavior changed.

At this state, I logged into Windows 7 and accessed the share as administrator and went to the "security"-tab of the share's-properties. It said, that the permissions are wrong ordered (???) and I saw 6 entries:
one for owner allowed
one for owner denied
one for group allowed
one for group denied
one for everybody allowed
one for everybody denied

I deleted the "denied" entries and added one windows-group (domain\somegroup) with full access.

After that I tried with an user, who is member of this group but it didn't get access to the share?

What is wrong. I just want:

full-access for domain-administrator
full-access for some groups
read-access for some-groups
no access for the rest

Thank you very much for reading this long post and some help.

Please excuse my bad english - I hope you could understand the most of my problems.
 

xbmcg

Explorer
Joined
Feb 6, 2012
Messages
79
Unix and windows permissions are handled differently. Windows ACL are sort of hidden metadata structures where you can nest groups (local user, local group, domain user, domain group)

There is always a owner and you cann add more users or groups to an object, the local groups can include local user or domain user or domain groups and they can have domain users...) Such structures does not exist in unix. each object has only 3 attributes, user, group and everyone. Group is something similar to local groups in windows, but there is only one per object. So you have to create a group and put all users in there and give that group the appropriate rights.

If you intend to use the windows way, dont set unix permissions, allos everyone and use then from windows the restrictions on the files by alowing / denying access by acl.
 

Decibel1000

Dabbler
Joined
Nov 13, 2012
Messages
16
I'm actually quite interested in this thread. I also have the same issue. I'm not mixing security types across the Datasets. What I've done (and keep trying): Create the dataset and set the owner to "Administrator" and Group Owner to "Domain Admins", both default Windows objects, and all set to 0770, and of course, type of ACL "Windows". If I access the directory as "Administrator" all is good, if I access the directory as someone inside "domain admins" and try to change any security flag, oops, no go here. As Administrator, I can change all security flags, add groups and users. Later if I access the same directory as someone inside any of the groups created, no go. The default behavior is that I, as a member of ANY group, I can always see and read any data inside but can't change/add data, no matter what the group privileges are. This has being a big pain in the last couple days :(.
Thanks for any help.
 
Status
Not open for further replies.
Top