I have been able to reproduce the behavior in both our test and production forests on several DCs. GPO has been applied a while ago, boxes have been rebooted more than once and RSoP shows the right settings. More than that, when I look at c:\windows\security\templates\policies\gpt00001.inf (which contains the settings pulled from DC's GPO, I see line like this: MACHINE\System\CurrentControlSet\Control\LSA\CrashOnAuditFail=4,0 and the registry has CrashOnAuditFail set to 0 (disabled).
void *Guy; (you guys are contagious ;) ) On Tue, 2004-08-24 at 00:05, Mulnick, Al wrote: > Sounds like the feature isn't working as expected if the box continues to > work until reboot. It's also possible it was triggered prior to the GPO > being applied, but you'd have to repro to know IMHO. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky > Sent: Monday, August 23, 2004 5:01 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] By design or configurable ? > > Right, but this feature was turned off in GPO, so the box was not supposed > to crash. > And how would you explain the working replication (with full security > logs) till the box is rebooted manually and only then enters the "crashed" > state ? > > We indeed have a policy for keeping 3 months of security logs and meanwhile > it takes between one to two weeks to fill the logs, but this is a new forest > and users keep arriving, so eventually we will need to implement a more > serious approach. > > Guy > > On Mon, 2004-08-23 at 23:37, Mulnick, Al wrote: > > > > http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/ > > deploy > > guide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/ > > all/de > > ployguide/en-us/46686.asp?frame=true > > > > This link is the documented behavior. Sounds like that is what you're > > getting. I think there may be some misnaming involved in that it > > should actually restart if it says "crashondump" but whatever. > > > > As for your situation, I know in some environments, 128mb wouldn't > > last two hours. A process to collect the data at the end of the day > > would be too late. That's what makes me suggest other methods. IMHO, > > there's a balance between collecting the data and self-configured > > denial of service. The key is to figure out how important that logging > > data is. If it's important, such as in regulatory environments, then > > that indicates you really should have a process of collecting that > > data whenever it's written to the logs or very soon after. If for > > security reasons, you have to stop service if unable to log security > > events, then so be it. Just make sure you never run into that > > situation, right? If you have that requirement, but don't prevent > > your systems from ever running into that situation, then it is by default > acceptable to have occasional DoS events. > > > > Your system did crash when it was full. Normal operations failed to > > continue and the LSA stopped for that particular DC. It's a testament > > to your architecture if the users never noticed :) > > > > Al > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Guy > > Teverovsky > > Sent: Monday, August 23, 2004 4:24 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [ActiveDir] By design or configurable ? > > > > > > Interesting... > > > > I have "Audit: Shutdown system immediately if unable to log security > audits" > > set to disabled and security log size configured to 128Mb (DCs > > GPO) > > > > We are keeping 3 months back of security logs, hence the GPO is > > configured not to override the security logs. DCs have a scheduled > > task that pops up once a day and archives/clears the security logs - > > not the state of the art solution, but does the work without > > purchasing any additional software. I would love to give MOM a try, > > but we already have OpenView in place, so I'll be checking with OvO people > if the security logs can be handled by OvO. > > > > So in this configuration, if booted with full security logs, I > > experience the same behavior as CrashOnAuditFail set to 2 (box in > > crashed mode) - verified that by adding peer DC to builtin > > Administrators group and the replication resumed. > > > > Am I missing something or this is not the desired behavior when the DC > > is configured not to crash on audit ? > > > > Thanks, > > Guy > > > > > > On Mon, 2004-08-23 at 16:10, Mulnick, Al wrote: > > > I suppose in theory, setting it to crash on full is also a security > > > risk since it could be used to cause a denial of service. > > > > > > I'd guess that if you have something that siphons off the logs on > > > submit event, then it could be a workable solution. I'd have to say > > > I'm not impressed with a lot of the tools currently out there that > > > do this due to the overhead they place on the machine, but it could > > > be done. MOM Server is a good way to get this done IIRC. > > > > > > I'm guessing that's what you had in mind, Rick? Something that > > > clears it as it is written, vs a timed deal? > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Gasper, > > > Rick > > > Sent: Monday, August 23, 2004 9:02 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] By design or configurable ? > > > > > > I have had the same problem, but setting the logs to overwrite is > > > bad system administration. IF a person attempt to break passwords, > > > thy can just flood the server with requests and eventually the log will > clear. > > > The best solution is to have the logs cleared by a script or third > > > party utility to clear and archive the logs every night. > > > > > > > > > > > > Rick Gasper > > > Manager, Network Services > > > King's College > > > 133 N. River St > > > Wilkes-Barre PA 18711 > > > PH: 570-208-5845 > > > Fax: 570-208-6072 > > > Cell: 570-760-0335 > > > [EMAIL PROTECTED] > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Depp, Dennis M. > > > Sent: Monday, August 23, 2004 6:48 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [ActiveDir] By design or configurable ? > > > > > > Guy, > > > > > > One way to avoid the problems of a full security log is to set the > > > logs to overwrite as needed. You can set this via group policy. > > > > > > I don't know if the kerberos ticket is cached or not. (I suspect > > > not.) When a machine reconnects to the network and you attempt to > > > access a network resource, the resource will ask for you ticket. If > > > you don't have one, or if it is out of date, the client will request > > > a new kerberos ticket and then be authenticated to the resource. > > > > > > Denny > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Guy > > > > Teverovsky > > > > Sent: Friday, August 20, 2004 8:48 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [ActiveDir] By design or configurable ? > > > > > > > > > > > > In my environment, when W2K3 DC boots with security logs full, the > > > > replication from that DC stops till the security log is cleared > > > > and the box is rebooted. > > > > The interesting thing is that after the security logs become full > > > > (while the box is online) the replication continues to work till > > > > the box is rebooted with full log. > > > > > > > > So the question is whether this can be prevented (we do have a > > > > routine which takes care of security logs archiving, but it failed > > > > on one of the DCs and I would like to prevent the replication from > > > > breaking again). > > > > > > > > And another OT question: > > > > When logging on to XP with cached credentials, is the Kerberos > > > > ticket cached too ? And if yes, what happens when the ticket > > > > expires and the box is reconnected to the network: will it > > > > seamlessly try to renew the ticked ? > > > > > > > > Thanks, > > > > Guy > > > > > > > > -- > > > > Smith & Wesson - the original point and click interface > > > > > > > > List info : http://www.activedir.org/mail_list.htm > > > > List FAQ : http://www.activedir.org/list_faq.htm > > > > List archive: > > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > > List info : http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > > > List FAQ : http://www.activedir.org/list_faq.htm > > > List archive: > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > -- > > Smith & Wesson - the original point and click interface > > > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > -- > Smith & Wesson - the original point and click interface > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ -- Smith & Wesson - the original point and click interface List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
