Directory Server Monitoring MIB
obsoletes
- rfc-1567 — X.500 Directory Monitoring MIB
Extracted elements (23)
Static information about Directory Servers is referenced via Distinguished Name pointers into the Directory itself rather than replicated into the MIB. Directory management applications are expected to use those DNs to retrieve further detail, keeping the MIB focused on dynamic operational data.
The MIB is divided into three tables reflecting different monitoring concerns: dsTable for summary/entry statistics, dsApplIfOpsTable for per-protocol-interface operation metrics, and dsIntTable for peer interaction history. The basic principle was to keep the MIB as simple as possible.
This MIB generalizes RFC 1567 (X.500 DSA-only) to support Directory Servers that simultaneously speak multiple protocols (DAP, DSP, LDAP, CLDAP, etc.). The multi-protocol model requires per-interface statistics rather than a single set of counters.
A CLDAP or LDAP frontend to an X.500 Directory will not have MasterEntries or CopyEntries; the counters dsMasterEntries, dsCopyEntries, and dsSlaveHits are inaccessible for such frontends.
CLDAP and LDAP implement Read and List operations indirectly via Search; dsApplIfReadOps and dsApplIfListOps are inaccessible for LDAP and CLDAP interfaces. CLDAP additionally does not implement Compare, Add, Remove, Modify, or ModifyRDN, making those counters inaccessible.
CLDAP does not use binds; bind-related counters (dsApplIfUnauthBinds, dsApplIfSimpleAuthBinds, dsApplIfStrongAuthBinds, dsApplIfBindSecurityErrors) are inaccessible for CLDAP interfaces. CLDAP also does not return referrals, so dsApplIfReferrals is inaccessible.
The MIB is specified in SMIv2. A conforming SMIv1 translation can be produced, but Counter64 objects cannot be translated and will be omitted; machine-readable SMIv2 information becomes textual descriptions. This loss does not change semantics.
Four compliance levels are defined: dsEntryCompliance (dsEntryGroup only), dsOpsCompliance (dsEntryGroup + dsOpsGroup), dsIntCompliance (dsEntryGroup + dsIntGroup), and dsOpsIntCompliance (all three groups). Implementors choose the level matching their monitoring scope.
Bind authentication counters in dsApplIfOpsEntry: dsApplIfUnauthBinds (anonymous binds), dsApplIfSimpleAuthBinds (password/SASL CRAM-MD5), dsApplIfStrongAuthBinds (TLS and X.500 strong auth), and dsApplIfBindSecurityErrors (rejected binds due to bad credentials).
dsApplIfOpsTable provides per-protocol-interface operation statistics for a Directory Server, indexed by applIndex and dsApplIfProtocolIndex. It covers bind types, operation counts, error counts, replication updates, and traffic byte counts.
dsApplIfProtocol identifies the application-layer protocol via OBJECT IDENTIFIER. For Internet protocols not in the IANA registry, OIDs of the form {applTCPProtoID port} or {applUDPProtoID port} are used, where 'port' is the primary port number.
dsApplIfReferrals counts referrals returned to requestors; dsApplIfChainings counts operations forwarded by this server to other Directory Servers. These distinguish the two modes of distributed directory request handling.
dsIntEntry fields: dsIntEntDirectoryName (DN of peer), dsIntEntTimeOfCreation, dsIntEntTimeOfLastAttempt, dsIntEntTimeOfLastSuccess (all TimeStamp, zero if before SNMP init), dsIntEntFailuresSinceLastSuccess (Gauge32), dsIntEntFailures and dsIntEntSuccesses (ZeroBasedCounter32, cumulative), dsIntEntURL.
dsIntTable records interaction history with peer Directory Servers, tracking the last N (locally-defined) peers per monitored server per protocol. Indexed by applIndex, dsIntEntIndex, and dsApplIfProtocolIndex.
dsServerType is a BITS object with two flags: frontEndDirectoryServer(0) and backEndDirectoryServer(1). Both bits may be set simultaneously if a server acts as both frontend and backend.
dsTable holds per-Directory-Server summary information indexed by applIndex from NETWORK-SERVICES-MIB. It contains server type, description, and entry/cache statistics (dsMasterEntries, dsCopyEntries, dsCacheEntries, dsCacheHits, dsSlaveHits).
Error counters: dsApplIfSecurityErrors counts requests failing security requirements; dsApplIfErrors counts all other non-security, non-referral failures including naming, update, attribute, and service errors. Partially serviced operations are not counted as errors.
Operation counters per protocol interface: dsApplIfInOps (total incoming), dsApplIfReadOps, dsApplIfCompareOps, dsApplIfAddEntryOps, dsApplIfRemoveEntryOps, dsApplIfModifyEntryOps, dsApplIfModifyRDNOps, dsApplIfListOps, dsApplIfSearchOps, dsApplIfOneLevelSearchOps, dsApplIfWholeSubtreeSearchOps.
Replication counters dsApplIfReplicationUpdatesIn and dsApplIfReplicationUpdatesOut track updates received from supplier servers and sent to consumer servers respectively. Traffic volume is tracked via dsApplIfInBytes and dsApplIfOutBytes.
Defines the DIRECTORY-SERVER-MIB module, assigned OID { mib-2 66 }, obsoleting RFC 1567 (dsaMIB renamed to dsMIB). The MIB is structured into three tables: dsTable, dsApplIfOpsTable, and dsIntTable.
All MIB objects are read-only (no MAX-ACCESS read-write or read-create). A correct implementation therefore has no risk of an intruder altering or creating management objects via SNMP SET operations.
SNMPv1 provides no security controls; even on an IPsec-secured network, SNMPv1 cannot restrict which principals can GET MIB objects. SNMPv3 is recommended as the management protocol for this MIB.
The MIB data can reveal directory system configuration and enable traffic pattern analysis, passively increasing vulnerability. It is recommended to control read access and consider encrypting object values in transit using SNMPv3 with the User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575).