Currently Being Moderated

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
    • EVT files can be viewed through Event Viewer or
    • Converted into plain text XML file with NetApp Tool and viewed through any text editor


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


Filter Blog

By author:
By date:
By tag: