desimus

updated

11 years ago

D

desimus

49 Posts

0

3431

January 12th, 2016 10:00

OneFS audit log entries

Does anyone know of a document that outlines the events generated by OneFS protocol auditing?  I am trying to make sense of the events, but haven't been able to find anything that explains the various sections.  I am currently only auditing failures for create, delete, read, rename, and set_security.  Below is an example audit entry, which must be a failure because I am not auditing success entries.  It does say "DOES_NOT_EXISTS", so I would probably assume that is a failure even if I were auditing success events as well, but is there a way to tell?  How are the success vs failure audits determined, I don't see anything that says one way or another.  In theparticular event below, I see it is a create event, so according to the docs, it is either a create file/fold, open file/folder, or a share mount operation.  Is there a way to determine which of those operations were performed?    Is there a place to reference the desiredAccess, createDispo, and ntStatus values?  Any info is greatly appreciated.

audit.PNG.png

  • scott_owens

    60 Posts

    2265

    1

    Posted January 13th, 2016 14:00

    For DesiredAccess, refer to the following documentation from Microsoft

    http://msdn.microsoft.com/en-us/library/ff469915.aspx

    FILE_READ_DATA

    0x00000001

    FILE_WRITE_DATA

    0x00000002

    FILE_APPEND_DATA

    0x00000004

    FILE_READ_EA

    0x00000008

    FILE_WRITE_EA

    0x00000010

    FILE_EXECUTE

    0x00000020

    FILE_READ_ATTRIBUTES

    0x00000080

    FILE_WRITE_ATTRIBUTES

    0x00000100

    DELETE

    0x00010000

    READ_CONTROL

    0x00020000

    WRITE_DAC

    0x00040000

    WRITE_OWNER

    0x00080000

    SYNCHRONIZE

    0x00100000

    ACCESS_SYSTEM_SECURITY

    0x01000000

    MAXIMAL_ACCESS

    0x02000000

    GENERIC_ALL

    0x10000000

    GENERIC_EXECUTE

    0x20000000

    GENERIC_WRITE

    0x40000000

    GENERIC_READ

    0x80000000

    So for a DesiredAccess of 128

    which is hex 0x00000080

    So that corresponds to FILE_READ_ATTRIBUTES

  • scott_owens

    60 Posts

    2265

    2

    Posted January 13th, 2016 14:00

    Create Disposition is outlined on the following

    https://msdn.microsoft.com/en-us/library/cc246502.aspx

    CreateDisposition (4 bytes): Defines the action the server MUST take if the file that is specified in the name field already exists. For opening named pipes, this field may be set to any value by the client and MUST be ignored by the server. For other files, this field MUST contain one of the following values.

    Value

    Meaning

    FILE_SUPERSEDE

    0x00000000

    If the file already exists, supersede it. Otherwise, create the file. This value SHOULD NOT be used for a printer object.<32>

    FILE_OPEN

    0x00000001

    If the file already exists, return success; otherwise, fail the operation. MUST NOT be used for a printer object.

    FILE_CREATE

    0x00000002

    If the file already exists, fail the operation; otherwise, create the file.

    FILE_OPEN_IF

    0x00000003

    Open the file if it already exists; otherwise, create the file. This value SHOULD NOT be used for a printer object.<33>

    FILE_OVERWRITE

    0x00000004

    Overwrite the file if it already exists; otherwise, fail the operation. MUST NOT be used for a printer object.

    FILE_OVERWRITE_IF

    0x00000005

    Overwrite the file if it already exists; otherwise, create the file. This value SHOULD NOT be used for a printer object.<34>

  • scott_owens

    60 Posts

    2265

    1

    Posted January 13th, 2016 14:00

    NTSTATUS is documented in the following article from Microsoft

    https://msdn.microsoft.com/en-us/library/cc704588.aspx

  • desimus

    49 Posts

    2265

    0

    Posted January 16th, 2016 09:00

    Thank you for the information, explanation, and links Scott, much appreciated.  About a month ago we started getting calls from VDI users that they weren't getting their profile when logging in.  We store profiles on an Isilon CIFS share, and when the issue occurs, I see the following audit entry.  This is reproducible, but it can take 10-20 login attempts before it happens.  Has anyone seen this sort of behavior before, or is this error quite common and more of a red herring?  Thanks again for any assistance.

    Capture.PNG.png