AuditLogin Frequently Asked Questions
Why should I worry about auditing?
Administering a NDS LAN is a mostly thankless job that your superiors probably don't understand well. They don't know that you don't have adequate auditing data but you can bet that they expect you to have it, especially when they need this information to give to someone else.
At some point, I guarantee your director will walk into your office and say something like this: "The FBI wants to know if Joe Schmoe logged in using this IP address on July 15th. I told them that we would be able to help them out. They are waiting on the phone in my office. Would you get that answer for me?" This is the reason that AuditLogin exists today.
How does AuditLogin work?
The AUDITLGN NLM runs on each server that you want to audit and hooks the NetWare OS for any login and logout activity. For each login or logout a record is sent to a designated server running the CONSLDAT NLM, where it is consolidated with records from all other servers into a single set of easy to manipulate log files.
Can AuditLogin handle auditing on many servers on a busy network?
AuditLogin can audit connections on hundreds of servers simultaneously. Many customers run with auditing enabled on many dozens of servers. AuditLogin runs at Clemson University and records in excess of 500,000 logins and authentications per day.
How is the data sent in to the consolidator server?
As soon as each login or logout event occurs, the record is sent to the consolidator using a single NetWare Core Protocol (NCP) transaction. This protocol is independent of the underlying protocol used for NetWare server communication (IPX or IP). The server-to-server connection is an authenticated non-licensed connection.
Isn't that a big load on the network?
No. A typical Client32 connection does many NCP requests per minute. On even a busy network with thousands of logins and logouts per day, AuditLogin will introduce less traffic than a single moderately used workstation.
How much load will AuditLogin add to my servers?
The load introduced by either the system monitoring NLM or the consolidation NLM will not be perceptible. The software is multithreaded to handle any number of simultaneous events, but has been written to sleep except when a real event is taking place. Even then the software is extremely liberal in giving up the processor.
There has been major improvement from V2 of AuditLogin in this area. AuditLogin V3 was developed and tested on Pentium 100mhz machines running NW4 and NW5 such that CPU utilization was unaffected. The new architecture of V3 especially dictates far less I/O and computation required by the consolidation NLM.What if the data cannot be sent in immediately because the network or the consolidator server is down?
Good question. If for any reason the system monitoring NLM cannot send data immediately to the consolidation NLM via NCP. The data will be staged locally until the link and/or the consolidation NLM is available again.
Why does AuditLogin not record unlicensed connections?
The mission of AuditLogin is to record the fact that an NDS object is using resources on a particular server. Clients can make unlicensed connections to a server for many reasons such as indirect NDS object referral and NDS object attribute retrieval. Client32 can make several concurrent non-licensed connections to the same server for a single workstation.
Many of these unlicensed connections are short lived and if reported would result in a great deal of superfluous auditing data that most administrators simply would not want.
So, we are worried about tracking what Novell is worried about licensing, those users that are using real resources on the server.What types of login/logout connections does AuditLogin record?
AuditLogin contains code to differentiate between connections using the following protocols: (CLIB, IPX, NLM, AFP, FTAM, ANCP, ACP, SMB, WINSOCK, HTTP, IP)