Solved!
Go to SolutionISILON Users Audit
Hello,
we have a requirement to record the users who use each share for past 30 days. is there any way we can trap that info ?
its like xxx:/ifs/share1 is used by 5 users we need their AD account info. i hope someone out there have a this requirement for audit purpose
thanks,
Raj
4342
0
Posted May 14th, 2013 01:00
Yes, share logon is an auditable event, however I believe it is a global SMB setting and not set per share...
isi smb settings global modify --audit-logon all|success|failure|none
You cam see more in the admin guideL
4342
0
Posted May 14th, 2013 10:00
Look in /var/log/audit
You should see a file smb.log, which has the info you want. It has a log rotate setup to move them at 50gb (I think) and compress them inside that same path.
4342
0
Posted May 14th, 2013 10:00
this is my current setting.does it means my nas is setup right ? also where to look at the users log in/off list for each share ?
nas4# isi smb settings global view | grep Audit
Audit Fileshare: none
Audit Global SACL Failure:
Audit Global SACL Success:
Audit Logon: all
4356
0
Posted May 14th, 2013 11:00
i seen all logon & logoff events at this point. just now i deleted one folder which is not logged a msg here also is there any additional setting for this audit to change to view the share name like /ifs/serverfolder/file1 is access by user1 / deleted by user1 like that.. all your help is really appreciated
nas4# tail -5 /var/log/audit/smb.log
2013-05-14T10:52:45-07:00 <33.6> nas4(id6) lwiod[6163]: S-1-5-21-11087255-880572229-1831341646-55053|0x5B4F800|LOGOFF|STATUS_SUCCESS
2013-05-14T10:54:29-07:00 <33.6> nas4(id6) lwiod[6163]: S-1-5-21-11087255-880572229-1831341646-55053|0x5B4F800|LOGON|STATUS_SUCCESS|172.22.188.23|172.22.166.61|chicagouser1@dlt.com
2013-05-14T10:54:45-07:00 <33.6> nas4(id6) lwiod[6163]: S-1-5-21-11087255-880572229-1831341646-55053|0x5B4F800|LOGOFF|STATUS_SUCCESS
2013-05-14T10:56:17-07:00 <33.6> nas4(id6) lwiod[6163]: S-1-5-21-11087255-880572229-1831341646-55053|0x5B4F800|LOGON|STATUS_SUCCESS|172.22.188.18|172.22.166.212|chicagouser1@dlt.com
2013-05-14T10:56:29-07:00 <33.6> nas4(id6) lwiod[6163]: S-1-5-21-11087255-880572229-1831341646-55053|0x5B4F800|LOGOFF|STATUS_SUCCESS
4356
0
Posted May 15th, 2013 14:00
You may also want to look at audit logs on all the nodes that are accessible over the network. Audit logs are individual for each nodes. So you may not find all the activity in one node audit logs as there may be a Round-Robin policy enabled for cifs connection.
4356
0
Posted May 15th, 2013 15:00
thank you Mark & Narahari for your valuable inputs.
4356
0
Posted May 15th, 2013 21:00
You can actually force them to go to /ifs by deleting /var/log/audit and making it a symbolic link to a path on /ifs...
4356
0
Posted May 15th, 2013 21:00
I found this document, it's pretty comprehensive..
553
0
Posted November 13th, 2013 10:00
Hey does anyone know where I can find all the different syntax combinations for the:
Audit Global SACL Failure:
Audit Global SACL Success:
cincystorage
2 Intern
•
467 Posts
4356
1
Posted May 14th, 2013 11:00
By default all that is enabled is LOGON and LOGOFF events, which does not track the share name or anything like that... You have a whole slew of options, but (and I can't stress this enough) USE CAUTION. Excess logging can and will cause performance issues with the entire cluster. That being said, here are some examples:
To log share a which share a user accesses: isi smb config global modify --audit-fileshare=success
To log file deleted: isi smb config global modify --audit-global-sacl-success=std_delete
To log file opens: isi smb config global modify --audit-global-sacl-success=generic_exec
To log creation, edits, and renames: isi smb config global modify --audit-global-sacl-success=generic_write
To log opens, deleted, creates, edits, renames: isi smb config global modify --audit-global-sacl-success=generic_all
Also the logs will fill up very, very, very quickly if you have a lot of activity...
There are a bunch more, but that is the basic idea... again BE CAREFUL.... don't kill your cluster... when in doubt, engage support.