Anonymous_User Absent Member.
Absent Member.
244 views

parsing of Novell Access manager 6.1r4 collector


I want to edit the parsing of Novell Access manager 6.1r4 collector. I
want only a sub-string in ExtendedInformation attribute instead of whole
value which is coming. I read the documentation for customizing existing
collectors. There it is written that, you will edit custom.js and add as
an auxiliary file in that connector and execution mode will be change to
custom.

For eg : Extended information -> Value2=0; Value3=0; JCC Device
ID=ag-3994412863167286; MIMEtype=unknown; Event Identifier=3906;
Target=Branding_URLs;

and i want to show only this part Target=Branding_URLs

But to change existing parsing for ExtendedInformation attribute, i
need to know the existing code of this collector. Only then i can
understand the changes i need to make. How can i get more information
about this ?


--
nikhilchawla
------------------------------------------------------------------------
nikhilchawla's Profile: https://forums.netiq.com/member.php?userid=125
View this thread: https://forums.netiq.com/showthread.php?t=3021

0 Likes
1 Reply
Anonymous_User Absent Member.
Absent Member.

Re: parsing of Novell Access manager 6.1r4 collector


Hi nikhilchawla,

So a couple quick things:

1) The data in ExtendedInformation is presented in JSON format, a
widely recognized method for encoding data (see http://www.json.org). As
a general rule, if you don't need to do anything in real-time (like
correlate on) that data, you may not need to extract it and put it in a
custom field. For example, you could simply add the ExtendedInformation
field to the Lucene query, and then use a little Java method to extract
the field you want for display on a report.
That said, it certainly is more convenient at times to pull data out of
ExtendedInformation and put it into a separate variable - it makes for
easier report processing, and as mentioned then allows you to
search/group/correlate more easily on those events.

2) All data that is in ExtendedInformation was parsed out of the
inbound event record and placed in ExtendedInformation using the
'add2EI()' method:
http://tinyurl.com/9gj5w4g
This means that at some point, the data you are looking for was in
(likely) some rec.RXMap.something variable, and the Collector decided to
put it in ExtendedInformation because it didn't know where else to put
it. So all you really have to do (probably) is figure out where the data
is stored (temporarily) in the Record object, and then add a line to
Rec2Evt.map to push that into the output event.
(The way this works is that the parsing logic takes the input and
parses values out into member attributes/objects attached to the 'rec'
object. Then that Record is converted into the output Event using the
Rec2Evt.map file as a guide).

Now, I took a quick look at the Access Manager Collector, and from what
I can tell the only events that will produce anything at all like what
you show are events 002e001a, 001b, and 001c (see VendorEventCode). Does
this sound correct? In which case I think actually you meant "Target
URL": "Branding URLs".... yes?

If that's the case, there's an argument to be made that the Collector
should in fact be *already* putting the URL into the TargetData* fields,
but to confirm we'd need a bit more info. And of course that doesn't
necessarily help you much.

Let's do this: confirm for me that we're talking about the same thing,
and if possible grab a CSV dump of one such event and copy it here (you
can obfuscate the IP addresses and whatnot to make them generic for
privacy reasons). If I agree that the Collector should be putting the
URL in TargetData*, then we'll create a bug to track this against the
Collector, and in that context we can capture some live data to test
against and make sure we get this right. But in the meantime I'll be
able to suggest a quick fix for you that will get you going in the
meantime.

Incidentally, the Sentinel schema breaks up pathed data objects so that
correlation is possible, so a string like:
http://myhost.com:8080/path/to/resource.html
will become:
{ "Protocol":"http", "TargetHostName":"myhost", "TargetHostDomain":
"com", "TargetServicePortNum": "8080", "TargetDataContainer":
"/path/to", "TargetDataName": "resource.html" }

This may seem somewhat complicated, but the rationale is that you can
easily correlate on things like "all events that target port 8080" or
"all attempts to access any file named resource.html"¸that sort of
thing. And if you ever need the full URL back, you can just do something
like (in Jasper):
$F{Protocol} + "://" + $F{TargetHostName} + "." + ${TargetHostDomain}
+ ":" + ${TargetPortNum} + ${TargetDataContainer} + "/" +
"${TargetDataName}
(the field names can really be anything, and are mapped to the Lucene
fields in the report query - I've used the display names for clarity).


--
DCorlette
------------------------------------------------------------------------
DCorlette's Profile: https://forums.netiq.com/member.php?userid=323
View this thread: https://forums.netiq.com/showthread.php?t=3021

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.