NSS and Syslog information

Question

Hi All,
Long time user of Netware and audit for Netware here. We are moving to OES 2SP2 Linux and I am evaluating Senitinel Logmanager as a upgrade to the Audit starter pack. What I would like is the same functionality in NetWare in Linux, what seems to be there now is a lot of logging but not a whole lot of usefull information.
Now part of this is the Sentinel Logmanager itself but part also seems to be the vigil interaction with the Logmanager/syslog server.
What I am finding is that NSS/vigil reports a whole lot of information for every file transaction, viewing a raw data feed for one file event there are something like 4-6 vigil log entries. What it looks like is happening is everything NSS does for verification is being reported to Vigil, including background processes that probably should not be. For instance, I created a directory as a test and it generated nss logs for opening and closing and creating a tmp file in the directory then deleting it, I assume many of these are NSS procedures to ensure the the directory was in fact created and that a file was able to be saved in it. For logging though what needs to be known is that a directory was created and who created it, so it seems to be way to much information.
The second issue I am seeing is that most of the packets being sent by Vigil are coming with a initiate user as root. I was able to find some packets in the raw data tap that mention the username but all other log entries that are in relation to that event reference root. Now I figure this is acurate if a lot of these entries are really lower level system verifications( which as I mention above should not show up) but it would be helpful to extend(if you do not have a pre-existing field) the schema of the log packets to include the original event and the originating user of that event.
Right now in log manager I see a ton of events and not one NSS event referencing a username or IP address, so I can tell you when a file was modified, opened, deleted etc., etc., etc., but I can not tell you by who or by what address. Now part of this is logmanager, obviously if I am recieving some packets with the username in the event from the raw data tap the vigil is sending but log manager is not retaining it, but the other side is that for every single event I am recieving 4-6 event packets and not one of those packets reference the initiating IP address or username, only one packet for every event is referencing a username and IP address.
Is there is roadmap to address this?
Thanks

Answer 1

What I am finding is that NSS/vigil reports a whole lot of information for every file transaction, viewing a raw data feed for one file event there are something like 4-6 vigil log entries. What it looks like is happening is everything NSS does for verification is being reported to Vigil, including background processes that probably should not be. For instance, I created a directory as a test and it generated nss logs for opening and closing and creating a tmp file in the directory then deleting it, I assume many of these are NSS procedures to ensure the the directory was in fact created and that a file was able to be saved in it. For logging though what needs to be known is that a directory was created and who created it, so it seems to be way to much information.
[DGC] From your discussion it sounds like the old Netware auditing did a better job of reporting only what is actually relevant.
To some extent, this is working as designed - we get raw records from Vigil, convert them to Sentinel events, and send them. On the other hand, we understand that ultimately you want to be able to ask the simple questions like "which directories were created by Joe?", and get a useful answer.
The Vigil auditing piece is brand new, so we're still getting a handle on the exact information that is produced and how it maps to actual user behavior. Internally, NSS is a complex beast that does shared filehandles and all sorts of fun stuff, so it's quite difficult to do this exactly right the first time. What we need is feedback like yours so that we can go in and refine how we process the inbound events.
The second issue I am seeing is that most of the packets being sent by Vigil are coming with a initiate user as root. I was able to find some packets in the raw data tap that mention the username but all other log entries that are in relation to that event reference root. Now I figure this is acurate if a lot of these entries are really lower level system verifications( which as I mention above should not show up) but it would be helpful to extend(if you do not have a pre-existing field) the schema of the log packets to include the original event and the originating user of that event.
[DGC] This problem has several root causes, but fundamentally the issue is that NSS itself rarely does anything as a user other than root/SUPERVISOR. It's the client (NCP/CIFS/AFP) that "knows" who the real end user is. There were also some bugs in the Vigil framework that prevented this information from passing through.
Some time in the next few months the OES team will be releasing some patches and a new version of the Vigil client that will address several of these issue. At the same time we'll be updating the Collector to do pretty much what you describe. Likely the solution won't be perfect quite yet, as there's still a lot to learn, but we should be a lot closer to the solution you're looking for. If you still see significant issues, simply file SRs with NTS and we will take care of them.