Gentle ESM Users,
3 quick questions I'd be grateful to have any responses on.
Q1: Would anyone be so kind as to share how you're doing Oracle Audit - SQL Pull monitoring? Is it working?
Q2: How do you handle multiple databases on one server (IP)? Are there issues with datasources having the same IP and differing only by Name and "Database SID?"
Q3: Is the collector essential to being able to handle the above?
Q4: Is there any useful prescriptive documentation or examples on use of the Oracle Audit - SQL Pull connector outside of the limited reach of KB74694?
At the risk of chasing anyone off of the quick conceptual questions above, here are the details of my journey thus far:
Through a lot of trial and error with a sharp DBA and capturing the Receiver's queries off the wire in packet captures for want of any useful documentation from McAfee on this connector's needs, I managed to get a couple independent data sources working using an account our Oracle DBA's weren't nervous about me having. :-) I used the Oracle Audit -SQL Pull (ASP data source model and SQL (Default) Data retrieval, specifying name, ip address, userid, password, and "Database SID" (which my Oracle guy says is a misnomer--that field should be "Database name" as SID is actually something else). The Oracle admin managed to define an oracle user for us that behaves in a least privilege read only way to the relevant fields. I got it working on 2 databases, these data sources defined at the root level of the Receiver.
The sadness came, however when I tried to make a parent object in the physical display pane of the ESM > Receiver so I could start lumping all the Oracle data sources into one place. I tried to re-define those existing working data sources underneath that parent after dutifully turning off parsing on the existing ones. That's when the wheels started coming off the bus a bit.
First, I found that client data sources under such a parent would be worthless as the "database SID" field is not among the things prompted for by the Client add.
Happily, Child data sources had the flexibility needed, but had an issue wherein if I defined a child with the same parameters of an existing working data source that I disabled parsing on, the Write would complete successfully, but on rollout, it started throwing vague errors about "Could not update policy - "Error: Could not execute command on device" Support had me manually update rules, and started talking about disabling all our custom rules with some hand wavy arguments about having seen problems with some "broken" custom rules in 9.4... but I was able to avoid that experiment by deleting the disabled-parsing datasource. Accordingly, I have a hypothesis that there's a bug wherein if you have 2 identical Oracle audit sql pull datasources defined, things may break even if one's disabled. Either that or something to do with the parent hierarchy throws a wrench in the works.
On a possibly related issue, are commas problematic characters in a data source names? Or duplicate IP's? ESM happily let me create a child data source with commas in the name, and it also let me create 2 children that had the same IP but unique database sid's, however things never worked very well beyond that write and successful rollout. The two data sources with the same ip but different "database sid" showed in the hierarchy, but I wasn't successful in retrieving any audit events. When I added a third child data source, I left some commas in the name field and suddenly had a new problem. The write and roll claimed to complete successfully, but now my display in the GUI no longer shows me those child data sources. Instead I see "Loading...." there. There should be 3 data sources there. I theorize that the commas in the name were an issue, but there wasn't any error checking on data source creation to catch em?
Given that this product seems to take a "let's keep em guessing" approach to parsing, input validation, and error reporting in the GUI, I'll probably need to engage support on how to dig out of this situation.
At any rate, I mostly am curious to know from you fellow ESM users what your recipe for success has been on Oracle database audit monitoring, and whether the Collector agent is the path to salvation.
Thanks much for any input and shared experience!