eDirectory and NetWare Auditing
DSMETER for NetWare - Technical Overview
DSMETER is an NDS/eDirectory security engine platform that plugs in and completes your NDS/eDirectory security access management infrastructure. Utilizing NLMs developed in 100% pure C and a user interface developed with our DSRAZOR product, DSMETER dynamically captures and consolidates data from your NDS/eDirectory to produce a comprehensive view of your security operations. DSMETER's data collection is on a NDS/eDirectory Tree-by-Tree basis.
The DSMETER NLM technology is based on development experience ranging back to Novell's NetWare 386 (released in 1989). Our core NLM technology has been designed to be transparent to your users. For complete coverage, DSMETER requires our two NLMs, which, together use approximately 50 MB of RAM at each NetWare server in your NDS/eDirectory Tree. This requirement is true whether or not there are any NDS/eDirectory replicas stored on that server.
The technology employed by the DSMETER NLM is Multi-Processor safe (i.e. aware and compatible).
DSMETER Administrator Interface and Schema Extensions
The DSMETER Administrator interface is a Windows 32bit application. Its interface was designed and built using our DSRAZOR product. Usage of this interface requires appropriate NDS/eDirectory and/or NetWare File System privileges.
The DSMETER Administrator interface includes the ability to automate the delivery and loading of its NLMs at each server in your Tree. Also included is the ability to modify the AUTOEXEC.NCF at each server to automatically load DSMETER. Lastly, the DSMETER Administrator interface can also automate the unloading of these NLMs and removal of AUTOEXEC.NCF modifications.
DSMETER integrates itself into your NDS/eDirectory Tree to allow auditing and control of your NDS/eDirectory and NetWare File Systems. The DSMETER Administrator interface is used to provide reporting and can be used from any workstation with proper administrative privileges. This integration is facilitated by adding new Object Classes and new Attribute Definitions to your NDS/eDirectory schema. To allow DSMETER to be managed from any location requires certain assumptions. The most important being that the core global parameters are available and secure at all times. To simplify this requirement DSMETER extends the NDS Partition Object Class with DSMETER NDS/eDirectory Attribute Definitions. Due to the current design of NDS/eDirectory, once the Partition Object Class is extended, these DSMETER Attributes cannot ever be removed. This might be important if you later need to merge NDS Trees or if you need to account for the use of the VCLICK01:DSM:* NDS Attributes. In fact, all DSMETER Schema Extensions (i.e. Object Classes or Attributes) have the same prefix VCLICK01:DSM. The presence of these extensions will not harm your network or NDS/eDirectory in any way. And only DSMETER will make use of them.
DSMETER Data Collection and Reporting
DSMETER collects NDS/eDirectory and NetWare File System activity that has been defined by you or your administrators. Each definition is stored in a "Profile" that DSMETER automatically detects and acts upon. Data collected by DSMETER is stored in Activity Log Files at each server. Here is how the logging works:
- Each server gathers activity as defined by DSMETER Profiles.
- Every 30 minutes, these servers will transmit their log files to the Repository Server (a server you select to house all log files).
- Transfer takes place using Novell's standard NetWare Core Protocol (NCP). This means your underlying network could be IPX or IP or anything else.
- After a successful transfer, the transmitting server will erase the transmitted Activity Log file from their local drive. Therefore, non-respository servers should never use much disk space for DSMETER Activity Log files, unless, of course, there is no Repository Server or it cannot be reached.
- As log files arrive at the Repository Server, they are accumulated into master log files of approximately 1MB each. As soon as a log file reaches 1MB, a new one is created.
- Filenames for log files are formed by using the DSMETER Profile ID (which is generated when the profile is created) plus the extension "LCL" (= LoCaL). At the Repository Server, the log filename extensions become .000, 001, etc. Each will be grown up to about 1MB before using the next extension.
- DSMETER provides a visual, rules-based reporting engine that allows you to zero in on the Security Activity that is important to you. Based upon our DSRAZOR product, DSMETER's reporting engine is a visual, drag-and-drop interface that lets you customize reports to any level of detail you need.