Recently we came across a customer who had to audit user access to NFS exports for compliancy purpose. He was using Data ONTAP 7-Mode and was an exclusive UNIX shop. Since it was for compliancy purpose there was audit and legal team pushing for its implementation. The ask was for simple file access auditing with minimal additional expenditure on license and hardware/system configuration. The account team reached out to us and thus started an investigation into our solution space.
To start with we had two parallel technologies to rely upon
- FPolicy partner products that provided an extensive reporting and data Governance capabilities
- Native auditing based solution that logs audit trails in windows EVT format
Under the circumstances we considered native auditing solution as there was no additional expenditure on partner license or hardware configuration.
Native Auditing for UNIX User Auditing
Native auditing is an implementation on top of Microsoft NTFS (New Technology File System) hence requires configuring filter file on a NTFS volume. The filter-file acts as a place holder for ACEs (Access Control Entries). But using Filter-File has two limitations
- They have controller scope and same set of SACLs (System Access Control List) will be applied to every object in the controller
- Since the Filter File has to be NTFS object you need to have a NTFS volume to host it even when you are a pure UNIX shop
When you don't want to enable auditing at controller level and don't want to depend on NTFS volumes than using SLAG (Storage Level Access Guard) makes ideal sense. Details about the SLAG is covered under TR-3596. SLAG supports configuring NTFS ACEs on even UNIX volumes and Qtrees. This provides more granularity than auditing based on Filter File. Additionally we don't need a NTFS based volume just to configure filter file
Let us see how SLAG can be configured for auditing
Configuring SLAG for UNIX User Auditing
Configuring controller for NFS auditing is covered in TR-3595.
Enable NFS auditing with option.
options cifs.audit.nfs.enable on
NFS file access auditing can be enabled through
options cifs.audit.file_access_events.enable on
Once the controller is configured is configured for NFS auditing you need to set SLAG on UNIX Volume or Qtree.Before applying SLAG verify the current SDDL (Security Descriptor Definition Language) configured on Volume or Qtree
Checking existing Permission on UNIX Volume
snagesh-vsim-3> fsecurity show /vol/vol2 [/vol/vol2 - Directory (inum 64)] Security style: Unix Effective style: Unix DOS attributes: 0x0010 (----D---) Unix security: uid: 0 (root) gid: 0 mode: 0755 (rwxr-xr-x)
Enabling SLAG is done though the ONTAP command Fsecurity. Fsecurity command requires SDDL string in a file as input. SDDL can be written manually or through the tool Secedit.exe. It can be edited once created from the tool.
Creating SDDL from Secedit.exe
When adding SDDL selection Storage option to configure SLAG
Configured SACL as required by your organization needs
After creating SDDL I have edited to set SACL to everyone and for every operations. This will the content of the file
I can copy that to a file in ONTAP and apply the SDDL using Fsecurity apply command. After applying the SLAG this is what Fsecurity will show
snagesh-vsim-3*> fsecurity show /vol/vol2 [/vol/vol2 - Directory (inum 64)] Security style: Unix Effective style: Unix DOS attributes: 0x0010 (----D---) Unix security: uid: 0 (root) gid: 0 mode: 0755 (rwxr-xr-x) Storage-Level Access Guard security: DACL (Applies to Directories): No entries. SACL (Applies to Directories): Success - Everyone - 0x000f01ff (Full Control) DACL (Applies to Files): No entries. SACL (Applies to Files): Success - Everyone - 0x000f01ff (Full Control)
Consideration while deploying auditing solution using SLAG
UNIX User Mapping
SLAG supports only NTFS style security permissions. This mandates mapping UNIX users to Windows users. Let us understand this with an example
Two UNIX users Linux\user1 and Linux\user2 are mapped to same CIFS user Windows\user3. Say a file gets deleted by any one of the UNIX users; we can’t conclusively say who has deleted the file looking at log. The log will say Windows\user3 has deleted the file
To alleviate the problem diligent mapping of UNIX users to Windows Users is required.
User access Denials
Some UNIX user access may get denied after enabled SLAG. This will happen even though we haven’t configured DACL (Discretionary Access Control List). This will be so because of missing mapping information for those UNIX users. SLAGS consider those users as CIFS users with missing credentials and fail to evaluate; leading to denial of file access requests. This requires ensuring mapping exist for all UNIX users.
Clustered Data ONTAP Implementation
In Clustered ONTAP UNIX user auditing is based on NFS V4.x ACL and has not dependency on NTFS ACLs. Thus similar customer scenario can be supported by setting appropriate NFS V4.x ACLs