I’ve been asked by a customer to take a look at their level of Directory Services Auditing.  I’m not able to share their screen shots but can scrub an email that I sent to them and post it here.

When it comes to Directory Services Auditing I always tell people less is more, if you already understand what the other audit policies give you then you can get 85% to 90% of what you need from those.  There are somethings that you will have to get via Directory Services Auditing there’s just no getting around it.  But just as with the case of Object Access be very carefull what you turn on or you will flood yourself with junk noise events.  The major pain is that all events generated by Directory Services use the same event id no matter what action you are doing and are very cryptic.

Here is the email:

“ As we talked about on the phone today there is a lot of auditing turned on where Microsoft hasn’t given very much information about what it generates and even some that are currently not used.  Example: Intellimirror-Group is used by remote boot legacy for managing groups of server machines and is currently not used.   Based on the screen shot you sent me I can see that the objects are currently being monitored which are generating a lot of noise events for you.  You might be better suited to audit the properties instead of the objects.  Example, if you want to know when a user has been given access to someone else’s inbox you need to monitor for changes to the property: msExchMailboxSecurityDescriptor; or if you want to know who made a GPO change then you need to monitor for changes to the properties: gpLink and gPOptions.  Most of the information that you can find via MSDN in regards to these audit objects is related to developers and not what the audit trail will give you.  Keep in mind that Microsoft considers the Directory Services auditing a low level audit, so the events that are generated are pretty cryptic in nature and all use the same event id. 

 There are a few of the objects that you would want to monitor to help get a more full picture of what is happening such as: Computer, User, OU, Shares, Group objects.  Monitoring these will give you things such as what OU a user was created in, where the Account Mgmt auditing does not give you this.  Also Account Mgmt auditing does not give you OU auditing (as again Microsoft considers this to be a low level object).

 In most companies it’s easy to turn on Auditing but very difficult to get it turned off and this is where Admins get themselves and others into a painful spot.  How to prove what is not needed when Microsoft doesn’t document what the auditing does or doesn’t do.

 Other examples:

msSFU30MailAliases – represents UNIX mail file data

nisMap – contains the generic abstraction of an NIS map

oncRpc – represents an abstraction of the Open Network Computing (ONC) Remote Procedure Call (RPC) binding

msRTCSIP-EdgeProxy – this attribute is reserved for future use

msRTCSIP-TrustedWebComponentsServerData – this attribute is reserved for future use”

Here are a few of the links where I pulled this data from:

http://msdn.microsoft.com/en-us/library/ms680938(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms985886(EXCHG.65).aspx

http://technet.microsoft.com/en-us/library/bb663647.aspx

Over the past several years I’ve been explaining the diffence between these two audit polices.  One is for logon/logoff events the other (Account Logon) is for authentication events.  In the past few months I have had several people ask me to put together a blog entry covering these 2 audit polices.  But I’ve found it rather painfull to put into a blog.   Then a few weeks ago I found out that my employeer (Prism Microsystems) was hosting a webinar with Randy F. Smith and I was going to also be presenting.   Well the webinar went smoothly today and so I have decided that instead of me doing a long lengthly blog entry I would just post a link to the recorded webinar.  Enjoy and I hope you are able to gain more insight into these 2 Audit Policies.

I was watching a Randy F. Smith webinar today and he showed a section of his website that he uses to track the Microsoft patches.  So I thought this would be good information to share.

Quite awhile ago I wrote a blog entry on Tracking Down File Deletes, it continues to be one of my most read blogs.  I came across another blog entry that does a good job of explaining the same thing.  The author is Ned Pyle, in his post he covers not only the Windows 2003 but also the Windows 2008 auditing so I thought I would share it with you.

Randy F. Smith has a good resource for the Windows 2008 Audit Policy.

Here is a link to some good information about the IIS status / sub-status codes for IIS 5 and 6.

Chris Crowe’s blog on IIS.

I had a discussion today with a customer who was trying to monitor when their users tried to access network shares and failed.  He had all the correct accesses setup, removed “Everyone” and gave access to only those groups that needed access.  He even turned on the correct Object Access auditing, but his problem was that when anyone outside the correct groups tried to access the folder they got the message that ”  \\<server name>\<share> was not accessable.  You might not have permission … ” but the Audit Failure 560 events (his server is W2k3) were not being generated. 

This is something that I’ve seen quite often, the issue comes from the  Share Permissions that have been set.  Because he removed the Everyone group from the Share Permission the Audit Failure events for 560 (Object Access Auditing) were not being generated. 

So if you need to be able to track when unauthorized users are attempting to access shares for which they do not have access, leave the Everyone group with Read permission under the Share Permissions tab on the folder (as seen in the screen shot below). 

Now on the Security tab make sure that you turn on the correct Object Access auditing  (stay away from FULL CONTROL; you will flood yourself with noise events).  Now since in this example we want to track when people fail to open the network share, goto the Security tab, then click on the Advanced button, then the Auditing tab.  Click the add button and set this auditing for Everyone and check Traverse Folder and List Folder boxes under the Failed column.

Now when users attempt to open this network share event id 560 Audit Failure event will be generated telling you who, what, when.  Now the from where is not going to be listed in the 560 event but can be tracked down by looking at the Client Logon ID hex code listed in the event description.

Looking at the Object Name will tell you what file/folder the user was trying to access.  If the Image File Name is blank then you know they were attempting to access the resource from the network, if this field has a value then they used the program listed to access the resource locally.  Client User Name will tell you who the user was if they accessed remotely (if they are accessesing locally then look at the Primary User Name).  The Client Logon ID (or Primary Logon ID) will help you link back to the logon event (528 or 540 in the case of W2k3 and older OS).  Looking at the Accesses list we can see the ReadData/ListDirectory which is what we are auditing for.

Over the last few weeks I have been putting together a whitepaper on detecting insider threats (on a Windows network).  The paper is finished and is available here.  In the next few days I will be setting up a webinar that will cover this topic watch www.prismmicrosys.com for a link to the webinar.

On Tuesday March 17, 2009 I conducted a webinar for Prism Microsystems on how Log Management can help you track down a hack attempt.  Now I know there are multiple ways to hack a network, the purpose of this webinar was to show that if you are collecting the log data from ALL your sources, network equipment/Unix/Linux/Windows that you can track down these attempts very quickly.  Log Management can also help you become more proactive vs always being reactive.  Here is a link to the recorded version of the webinar, here is a link for the slides used in the webinar.

Good article at darkreading.com about the ‘Tigger’/Syzor Trojan written by Tim Wilson.  In this article he points to a blog by Michael Kassner with more info on ‘Tigger’/Syzor trojan.