On us wacko DCs... we are advised to keep the max of our log files at 64
MB otherwise it messes with the backup:
*Cause:* An Event Log is larger than 64 MB.
*Solution:* Reduce the size of the Event Log to a maximum of 64 MB.
Note
To complete the following procedure, you must be logged on as a member
of the Domain Admins security group.
*To reduce the size of the Event Log*
1.
Click *Start*, click *Administrative Tools*, and then click *Event
Viewer*.
2.
In the console tree, click any Event Log that is larger than 64 MB.
3.
On the *Action* menu, click *Properties*.
4.
On the *General* tab, in *Maximum log size*, specify a log size of
64000 kilobytes or less.
5.
To put the new setting in effect, click *Clear Log*.
If you want to retain the information currently in the log, click
*Yes* when a message appears asking if you want to save the
original log before clearing it, and then click *OK*.
*Cause:* Directory Service Access auditing is enabled.
*Solution:* Disable Directory Service access auditing.
*To verify that Directory Service Access auditing is enabled*
1.
Click *Start*, click *Run*, and then type *rsop.msc*.
2.
In the details pane, double-click *Computer Configuration*,
double-click *Windows Settings*, double-click *Security Settings*,
double-click *Local Policies*, and then double-click *Audit Policy*.
3.
In the *Computer Setting* column, verify that it reads either
*Success* or *Failure*.
If Directory Service Access is not enabled, the entry in the
Computer Setting column will read *No auditing*.
*To disable Directory Service access auditing*
1.
Click *Start*, and then click *Server Management*.
2.
In the console tree, click *Advanced Management*, and then click
*Group Policy Management*.
3.
Navigate to /Forest/Domains/your domain/Domain Controllers, and
then right-click *Small Business Server Auditing Policy*.
4.
Click *Edit* to open Group Policy Object Editor.
5.
In Group Policy Object editor, navigate to Computer
Configuration/Windows Settings/Security Settings/Local
Policies/Audit Policy.
6.
Double-click *Audit directory service access*.
7.
Clear the *Success* and *Failure* boxes if they are checked.
8.
Click *Start*, click *Command Prompt*, and then type *gpupdate
/Force* to refresh the policy setting.
[EMAIL PROTECTED] wrote:
It can certainly hurt DCs. services.exe can consume huge amounts of
RAM at the detriment of lsass.exe.
e.g. I have seen services.exe consume ~ 2Gb of RAM thus leaving scraps
for lsass. Once a suitable monitoring solution was put in place and
event log sizes reduced, lsass grabbed more RAM and the DC performance
went thru the roof :)
neil
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Akomolafe, Deji
*Sent:* 31 August 2006 17:15
*To:* [email protected]
*Subject:* RE: [ActiveDir] Logging successful logons in AD security log
I can say that I have seen logs way bigger than the specified max
size. I can't say it's hurt the servers in any way.
Sincerely,
_____
(, / | /) /) /)
/---| (/_ ______ ___// _ // _
) / |_/(__(_) // (_(_)(/_(_(_/(__(/_
(_/ /)
(/
Microsoft MVP - Directory Services
www.akomolafe.com <x-excid://32770000/uri:http://www.akomolafe.com> -
we know IT
*-5.75, -3.23*
Do you now realize that Today is the Tomorrow you were worried about
Yesterday? -anon
------------------------------------------------------------------------
*From:* Glenn Corbett
*Sent:* Thu 8/31/2006 2:53 AM
*To:* [email protected]
*Subject:* RE: [ActiveDir] Logging successful logons in AD security log
Interesting.
from the article: "Microsoft plans to resolve these problems in the next
version of Windows by rewriting the event logging system from the ground
up." since the last update was Mar 28 2003, I wonder how this applies to
Wndows 2003 R2 and the 64 Bit versions of Windows, or if this will only be
fixed in Longhorn.
Glenn
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris
Sent: Thursday, 31 August 2006 7:20 PM
To: [email protected]; [email protected]
Subject: Re: [ActiveDir] Logging successful logons in AD security log
Does everyone know this recomendation from Microsoft?
On Windows XP, member servers, and stand-alone servers, the combined size of
the application, security, and system event logs should not exceed 300 MB.
On domain controllers, the combined size of these three logs - plus the
Directory Service, File Replication Service, and DNS Server logs - should
not exceed 300 MB.
http://technet2.microsoft.com/WindowsServer/en/library/5a86ab0f-c7eb-45ed-9e
5e-514173bf15e31033.mspx?mfr=true
Mark
________________________________
Return-Path: <[EMAIL PROTECTED]> Thu Aug 31 04:12:18 2006
Received: from smarthost1.giacom.net [194.131.240.55] by mail1.giacom.net
with SMTP;
Thu, 31 Aug 2006 04:12:18 +0100
Received: from mail.activedir.org ([12.168.66.190]) by smarthost1.giacom.net
with MailEnable ESMTP; Thu, 31 Aug 2006 04:12:15 +0100
Received: from smtp111.sbc.mail.mud.yahoo.com [68.142.198.210] by
mail.activedir.org
(SMTPD32-8.15) id A27721B0148; Wed, 30 Aug 2006 23:07:35 -0400
Received: (qmail 99368 invoked from network); 31 Aug 2006 03:07:35 -0000
Received: from unknown (HELO ?192.168.16.19?)
([EMAIL PROTECTED]@69.106.185.80 with plain)
by smtp111.sbc.mail.mud.yahoo.com with SMTP; 31 Aug 2006 03:07:35 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=s1024; d=pacbell.net;
h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Reference
s:In-Reply-To:Content-Type:Content-Transfer-Encoding;
b=PEIfvYwJhIYktsWE3wK8pnfo1RmbheeJg4LXCAQ1cS/3aIkBB+zWPBGoNL0vpHGQ7U+CwL+WPV
R6qNv7o1jr4Xp9zMxBmnzKaUuWHbmSmTn++z6CEr/Q5njP0rjFViu7J0fVz2mvIfjfh29qkHO6+P
EuYRMiJ3/EUAyhoBySfo8= ;
Message-ID: <[EMAIL PROTECTED]>
Date: Wed, 30 Aug 2006 20:07:29 -0700
From: "Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]"
<[EMAIL PROTECTED]>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: [email protected]
Subject: Re: [ActiveDir] Logging successful logons in AD security log
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: [EMAIL PROTECTED]
Reply-To: [email protected]
Received-SPF: none (smarthost1.giacom.net: mail.activedir.org does not
designate permitted sender hosts)
X-Declude-Sender: [EMAIL PROTECTED] [12.168.66.190]
X-Note: This E-mail was scanned in real-time by Giacom Anti-Spam and Giacom
Anti-Virus. Advanced Virus and Spam protection is available to subscribers
of Giacom Business Pro Plus. Visit http://www.giacom.com for more details.
X-Spam-Tests-Failed: ROUTING [-1]
X-Note: This E-mail was sent from ([12.168.66.190]).
X-Rcpt-To: <[EMAIL PROTECTED]>
Ask the PSS security guys and they want success and failure. Only
having half the story... is only half the story....
Buy bigger harddrives and archive.
Sitton Glen E wrote:
> I don't know that there is a 'general consensus' because everyone's
> business needs differ. My environment has around 100K users and you're
> right, there's a ridiculously high volume of logon events. We set the
> security log size very high on the domain controllers, and collect and
> clear the security logs several times per day using a
> commercially-available "fancy log management system." We don't allow
> the security logs to rollover. The eventlog management software gives
> us an impressive battery of audit reports, and a compressed eventlog
> repository that we archive for FISMA compliance.
>
> I'm sure our uncompressed event log archive is well above 1TB per year.
> But we realize about a 20:1 compression using the commercial software.
>
> Your options may be limited by legal requirements that may govern the
> audit logs of your business or organization.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour,
> Joseph
> Sent: Wednesday, August 30, 2006 5:32 PM
> To: [email protected]
> Subject: RE: [ActiveDir] Logging successful logons in AD security log
>
> That may work, but it sort of falls under option b. The logs will grow
> so large that they will become unmanageable. I did some calculations
> and it works out to be about 1TB a year.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Derek Harris
> Sent: Wednesday, August 30, 2006 3:06 PM
> To: [email protected]
> Subject: RE: [ActiveDir] Logging successful logons in AD security log
>
> I have a pretty small site, and this probably won't scale very well, but
> I have a script scheduled to run every day at midnight that backs up the
> security log to a compressed folder & clears it. I have the log size set
> ridiculously high, so it doesn't rollover unexpectedly.
>
> dtmThisDay = Day(Date)
> dtmThisMonth = Month(Date)
> dtmThisYear = Year(Date)
> strBackupName = dtmThisYear & "_" & dtmThisMonth & "_" & dtmThisDay &
> "_" & Hour(Time) & Minute(Time) strComputer = "."
> Set objWMIService = GetObject("winmgmts:" _
> & "{impersonationLevel=impersonate, (Backup, Security)}!\\" & _
> strComputer & "\root\cimv2")
> Set colLogFiles = objWMIService.ExecQuery _
> ("Select * from Win32_NTEventLogFile where LogFileName='Security'")
> For Each objLogfile in colLogFiles
> objLogFile.BackupEventLog("c:\seclogs\" & strBackupName & _
> "_security.evt")
> objLogFile.ClearEventLog()
> Next
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour,
> Joseph
> Sent: Wednesday, August 30, 2006 3:10 PM
> To: [email protected]
> Subject: [ActiveDir] Logging successful logons in AD security log
>
> What is the general consensus on logging successful logon events?
>
> For example if you have a domain with 100K users or so and you use AD as
> your primary authentication service for: application, file, email, and
> web access then it is plausible that you will end up with up to 100 log
> entries per second. That kind of volume will no doubt cause the logs to
> roll over frequently thus making them somewhat useless.
>
> The only alternatives I see are:
>
> a) Don't log success logon.
> b) Set your event log size to a very large (and possibly unmanageable)
> size.
> c) Invest in a fancy log management system that will collect, index, and
> retain all of your logs.
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and
delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of
communication and
Nomura International plc ('NIplc') will not, to the extent permitted
by law,
accept responsibility or liability for (a) the accuracy or
completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely
those of
the author and do not necessarily represent those of NIplc; (3) is
intended
for informational purposes only and is not a recommendation,
solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St
Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
If you are a SBSer and you don't subscribe to the SBS Blog... man ... I will
hunt you down...
http://blogs.technet.com/sbs
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
