Re: Excessive 560 events logged when turning on Object Access Audi

The specific higher volume failure events you mention that one
gets when enabling logging for global objects have been around
for a very long time. I once was on a campaign to find info about
the Crypt32LogoffEvent failures back when Window 2000 was
the current server version, and ended up with zilch for info.
So, I can only say that seeing these is apparently normal in W2k
(ditto the less often seen RasPbFile), that these started when on
of the service packs came out (don't recall exactly but leaning
toward saying these started with SP 3) and that back then I was
not able to find anyone in MS that would/could clarify. Back
then there were zero hits in searchs on Crypt32LogoffEvent,
are there any now ? ?

Roger

"Gilbert" <Gilbert@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:64B002C9-90A3-4081-AE05-8F6993893BC6@xxxxxxxxxxxxxxxx
Hi John, thanks for helping out. I have looked at this article before,
but
it does us no good. It is hard for us to just inform our management that
we
can just turn the feature off to avoid these errors... We need to get to
the
root cause of these errors, which we know is due to ACL. Question is, how
do
we identify the object when is just states RasPbFile or Crypt32LogoffEvent
or
{some other network ID}...? My boss would ask me "what does
Crypt32LogoffEvent refer to in Windows..." and I would got "Duhhhhh...".


"John John" wrote:

Did you read or try here?:

Event IDs 560 and 562 appear many times in the security event log
http://support.microsoft.com/kb/841001

John

Gilbert wrote:

Help! Due to security regulations, I have to use object auditing. As
a
result, I get a TON of event 560 failures. Sometimes to the tune of 30
or
more per minute. Is there any way to fix this without disabling
auditing?

The errors usually appear for RasPbFile, and Crypt32LogoffEvent. What
are
these events? How can I prevent them from appearing? And does
enabling
Auditing of Global Objects actually provide useful information at all?

A million Thanks!
Gilbert




.