Audit failures in security event log

[jlloyd]

Let me first say how pleased I am with this product. I looked through a lot of other tools before coming across Zoom Search, and it's definitely one of the easiest, full-featured and flexible products I've seen (for my search need, ymmv).

In preparing to deploy this on our sites, I've set up tasks to update or fully reindex the different sites on a nightly basis. Since creating those tasks, I've seen a lot of security audit failures showing up in the event log. They're all event ID 560, related to the SC_MANAGER object and generated under the account running the task (a user account solely for running tasks). Oddly though, there seems to be no affect to the output of the program; the indexing/updating seems to go just fine, except for 3 (when updating) to many (when fully indexing -- approximately 1 notice every 2-3 seconds) failure notices being written to the log.

This isn't a high priority concern since the output is OK, but I'm bothered by so many failure entries in the event log. Googling for this particular problem doesn't yield a great solution (most related messages just suggest turning off the notifications -- voila! problem solved!), and while I can get rid of the issue by adding the process user to the Administrators group, I'd prefer to have a better notion of what's going on before I take either action.

I know audit failures are normal during Windows functioning, and if that's the case here, fine, but it would be nice to know for certain. If anyone has any notions or experience with this issue, please let me know. I'd be most appreciative.

[David]

We haven't noticed this ourselves. But we haven't gone looking in event manager either. Zoom itself doesn't dircetly write to the Windows event log.

You didn't post your particular mesage, but I looked up the 560 messages. And at least some of these just seem to be logging access to various windows services.
i.e. they aren't errors, nor security issues. They are just an audit trial.

[jlloyd]

No, the 560 event isn't the issue; it is the object requests generating the failure 560s that have me somewhat concerned. When Zoom Indexer is running as a scheduled job, it's asking for and failing to get (thus generating the audit entries):
Accesses: READ_CONTROL
Connect to service controller
Enumerate services
Query service database lock state

This is something specific to running the Indexer as a scheduled task using the task user account; other combinations -- running the task as an administrator, running the job command line as the task user in a command window -- generate no audit entries. None of the the other scheduled tasks on the system (non-Zoom), running as the task user, generate such notices. And, as noted in my initial post, this access issue doesn't prevent the job from completing successfully.

So, the Read Control access doesn't appear to be needed by Zoom, but it's still being requested. I'd rather it not be; with the failure notices coming every 2-3 seconds when the job is running, it can generate a lot of log entries when the site it being fully spidered.

[Ray]

Can you tell us what version of Windows you are using? We tried to reproduce this behaviour but were unable to do so using Vista.

Also, take a look at this Microsoft Fix for a bug in XP and Server 2003 regarding this issue:
http://support.microsoft.com/kb/908473

[jlloyd]

I appreciate your interest in this matter. I'm running on Server 2003 Standard Edition SP 2 (which, theoretically, incorporates the hotfix in the KB article you linked).

I've done some additional testing, and watching the process via RegMon, I saw that access was being denied to a registry key: HKCR\CLSID\{D41235E9-B209-4106-05A3-1B1A1A302311}. On this server, the entries indicate this key is related to MS SAX XML Reader; however, the same key on my local machine (XP Pro SP2) shows this as an Outlook control.

Additionally, under this key, the Zoom Indexer program appears to create a number of "garbage" subkeys and entries, 7 or 8 in all. Subkey names appear to be random characters (although they differ between the server and my local machine, so probably machine-specific) of varying length. If I delete the subkeys, the next time Zoom Indexer runs they are recreated. This doesn't happen if I delete them and remove permissions for the task user account, or only give the account Read permission. No matter what the key permissions, the audit failures are still occurring. (The count of failures roughly corresponds to the ACCDENIED responses RegMon shows for the key.)

So now I've got another curiosity to explore. Please let me know if you have any insights as to what I'm seeing.
Thanks.

[Ray]

We couldn't reproduce this on our Server 2003 machine either. I do not believe there is any extraneous registry accesses that isn't necessary, so given that, there might not be much we can do about this.

You might want to investigate the following things:

1) Do you see the same behaviour on your aforementioned XP machine (the logged Audit Failures in Event Viewer)

2) It might be a consequence of the security policies and account setup that is in place on your server. Perhaps you have policies in place for scheduled tasks/batch job accounts which are different. Or do you have any other security applications installed?

3) Have you noticed any difference with various configurations, eg. Spider mode indexing vs Offline mode indexing. When does the Audit Failure occur? During indexing or upon start up?

4) It wouldn't be the first time we've seen a Microsoft bug re-surfacing in later versions of Windows after they have released a hotfix/SP which is supposed to fix it. It is quite possible that a more recent update has re-broken a previously fixed problem. Making sure you have the latest updates might find you a newer fix for this (or it could be the latest update that is actually re-introducing the bug... but at least then you would think we would see it as well).

[jlloyd]

1) No, but it's a wildly different configuration (my development desktop) than the 2003 server. I created a non-priviledged user, ran the scheduled task as it, and did not receive any log entries, but I would be hesitant to call that definitive.

2) There are security applications installed, but those are primarily outward facing (e.g., a firewall). There may be a policy setting at play -- when the task runs as an administrator, there is no issue -- but cursory examination hasn't raised any flags or found obvious problems. (If it were a security app interferring, I would expect that the audit entries would be created no matter the executing user, but again, that's not definitive.)

3) I haven't tried offline (there are pages that shouldn't be indexed), but I could try running that as a test. Occurence is throughout the run of the application, approximately every 2-3 seconds on a larger run (full indexing). Updating is faster, but there are usually still 3 event entries at job completion.

4) I really hope it's not this, but Microsoft being Microsoft... it's a definite possibility. The server shows it's current on all patches and fixes, which makes this seems less likely, but not impossible.

I'll try installing zoom this week on a virtual 2003 machine and see if I can get more consistent results to those on the public facing server. If not, I can probably just live with this. As I've said, it's annoying, but there doesn't seem to be any impact to the actual functioning of the application or to the results.