CIFS ACLs on ZFS Problem
Recently had an issue with a CIFS share on a Solaris 11 box. Still not sure how this happened but it turned out there was a weird Idmap mapping. Active Directory Group and members were correct and group had correct members. Yet still the users in this group could not write to the folder.
How to check identities in idmap:
# idmap show -cv rrosso@domain.com winuser:rrosso@domain.com -> uid:2147483651 Source: Cache Method: Ephemeral # idmap show -cv DFS_Corp-CA-Dept-IT_rw@domain.com wingroup:DFS_Corp-CA-Dept-IT_rw@domain.com -> gid:2147483667 Source: Cache Method: Ephemeral
Lets just see how the mapping rules look:
# idmap list add winuser:*@domain.com unixuser:* add wingroup:*@domain.com unixgroup:* add winuser:administrator@domain.com unixuser:root add "wingroup:Domain Users@domain.com" unixgroup:smbusers
The Active Directory Read-Write group that is not allowing the members to write to the folder:
# idmap show -cv DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com
wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com -> gid:2147484149
Source: Cache
Method: Ephemeral
Looking at the folder called Bugzilla:
Current (broken) acl must be this one user:2147483813 if I look at the gid above. Not to mention the mapping is not for a group but for a user.
root@zfs001:/tank/dfs/engdirs/engineering/engineering# /bin/ls -v | more d---------+ 16 2147483650 smbusers 17 Oct 12 14:14 Bugzilla 0:user:2147483813:list_directory/read_data/add_file/write_data /add_subdirectory/append_data/read_xattr/write_xattr/execute /read_attributes/write_attributes/delete/read_acl/synchronize :file_inherit/dir_inherit:allow 1:group:2147483763:list_directory/read_data/add_file/write_data /add_subdirectory/append_data/read_xattr/write_xattr/execute /delete_child/read_attributes/write_attributes/delete/read_acl /synchronize:file_inherit/dir_inherit:allow 2:group:2147483660:list_directory/read_data/read_xattr/execute /read_attributes/read_acl/synchronize:file_inherit/dir_inherit :allow
Looking at above something looks odd. Looking at the windows side we expect three groups to have permission here but spot the "user" listed in the first ACL.
Lets find the three id's. Left the grep wide open to find all uid and gid matching the number. But really we are just after the gid's:
# idmap dump -n | grep 2147483813 wingroup:Guests@BUILTIN == gid:2147483813 wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com == uid:2147483813 # idmap dump -n | grep 2147483763 winuser:Homey@domain.com == uid:2147483763 wingroup:DFS_Eng-CA-Dirs-Engineering_rw@domain.com == gid:2147483763 # idmap dump -n | grep 2147483660 winuser:Stewey@domain.com == uid:2147483660 wingroup:DFS_Eng-CA-Dirs-Engineering_ro@domain.com == gid:2147483660 # idmap dump -n | grep 2147484149 wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com == gid:2147484149
After we removed and recreated the group in AD. Might take a little bit to show up:
# idmap show -cv DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com -> gid:2147484149 Source: Cache Method: Ephemeral # idmap dump -n | grep 2147483813 wingroup:Guests@BUILTIN == gid:2147483813 usid:S-1-5-21-1977730361-3076317898-4166923938-22371 == uid:2147483813 # idmap dump -n | grep 147484149 wingroup:DFS_Eng-CA-Dirs-Engineering-Bugzilla_rw@domain.com == gid:2147484149
Permissions after re-applying from Windows:
# /bin/ls -dv Bugzilla/ d---------+ 17 2147483650 smbusers 18 Nov 12 20:12 Bugzilla/ 0:group:2147483763:list_directory/read_data/add_file/write_data /add_subdirectory/append_data/read_xattr/write_xattr/execute /delete_child/read_attributes/write_attributes/delete/read_acl /synchronize:file_inherit/dir_inherit:allow 1:group:2147483660:list_directory/read_data/read_xattr/execute /read_attributes/read_acl/synchronize:file_inherit/dir_inherit :allow 2:group:2147484149:list_directory/read_data/add_file/write_data /add_subdirectory/append_data/read_xattr/write_xattr/execute /read_attributes/write_attributes/delete/read_acl/synchronize :file_inherit/dir_inherit:allow
Just checking a new file we just created for good measure:
# /bin/ls -v | grep Test d---------+ 2 2147483740 smbusers 2 Nov 12 20:12 Test
