sep2004.tar

System Inventory Using LDAP

Kaijun Zhan

System inventory is an application with many uses ranging from hardware and software inventory data and collecting business-related information to configuration management and software distribution. Several commercial software options are available in the market. However, some of the challenges to deploying such commercial software are: compatibility with various platforms, integration complexity (heavy customization), high cost due to proprietary concept, function extensibility, lack of data security, and lack of standards. There are also homegrown solutions, such as using scripts and cron jobs to collect data that illustrate the limitations of scalability, security, and standardization.

LDAP stands for Lightweight Directory Access Protocol. In most cases, it is the core element of security applications such as authentication, authorization, policy management, and single sign-on. In the Unix system arena, LDAP is also becoming popular as a replacement for Network Information Service (NIS), not only for traditional password authentication but for other maps as well (hosts, automount, aliases, etc.). On the PC side, Active Directory is the LDAP implementation in the Windows environment. Organizations with an LDAP infrastructure can take full advantage of LDAP properties without investing in any additional software.

In this article, I propose a simple concept to standardize system inventory using LDAP as an underlying transmit protocol and data repository with the code name Softario. With this setup, we limit the definition of "system" in the context of networked devices.

The Architecture

Let's first define the scope of "System Inventory" to collecting system-related information in the following areas:

1. Hardware information, such as vendor, model, CPU, disk, platform, memory, serial number.

2. Software information, such OS, application, license information, configuration files.

3. Operation support information, such as system location, business owner, support document, systems administrator contact.

4. Business process information, such as business continuity process, cost center, asset number.

The architecture consists of the following four components:

1. An LDAP server for data repository. Some of the popular LDAP servers are OpenLDAP and Sun ONE Directory Server. Both support LDAPv3; however, neither of these has all the required attributes for our inventory purpose. Hence extending the attributes and objectclasses is necessary.

2. A data access model. Inventory data must be written to and read from LDAP server. Hence, a proper security measurement must be in place. Additionally, it is almost certain that the LDAP used for this purpose is a shared data source. In regard to data transmission, the default LDAP port (389) uses clear text, and LDAPS can be used if higher security is mandated.

3. A client for inventory data collection and updating. For devices with no client capability (e.g., network printers, switches, and firewall devices), a manual data collection process is required.

4. A Web interface for data entering and reporting.

Figure 1 illustrates various components in this architecture. The LDAP server, along with proper Access Control Instruction (ACI), attributes, and objectclasses, is used for data repository. On systems with an inventory client installed, the data is collected and updated to the server via LDAP or LDAPS.

For client-less systems, such as network switches, systems administrators can manually enter the information either via the Web or command line. The client speaks LDAP languages directly. This can be modified using Web services with a Small Object Access Protocol (SOAP)/HTTP provider under a DSML/XML framework.

LDAP Server

For this setup, we are using Sun ONE Directory Server 5.2 with latest hotfix as the directory server. Because we already used ou=hosts subtree for all host-related information as part of an NIS migration (e.g., canonical host name, host aliases, and IP address), it is natural to just extend the schema to include all system inventory attributes.

Two standard host objectclasses "device" (defined in 00core.ldif) and "ipHost" (defined in 11rfc2307.ldif) cover the following attributes:

objectClasses: ( 2.5.6.14 NAME 'device' DESC 'Standard LDAP 
 objectclass' SUP top MUST ( cn ) MAY ( description $ l $ o $ ou 
 $ owner $ seeAlso $ serialNumber ) X-ORIGIN 'RFC 2256' )
objectClasses: ( 1.3.6.1.1.1.2.6 NAME 'ipHost' DESC 'Standard LDAP 
 objectclass' SUP top AUXILIARY MUST ( ipHostNumber $ cn ) MAY 
 ( manager $ description $ l ) X-ORIGIN 'RFC 2307' )

The objectclass "ipHost" includes some attributes that are useful for inventory:

Required attributes:
     ipHostNumber: IP Address of the host
     cn:           Common name - both Canonical name and Aliases are
                   specified with this attribute.
Allowed attributes:
     manager:      Administrator who manages the machine  
     description:  Commentory field
     l:            Location information  
     o:            Organization the machine belongs to  
     ou:           Organizational Unit the machine belongs to
     owner:        Business owner of the system
     seeAlso:      Links to other data  
     serialNumber: Hardware serial number

Next, we introduce a new objectclass called "cdsHost" with OID 1.3.6.1.4.1.15925.2. This objectclass is superior to objectclass "ipHost". Some optional attributes that are relevant to inventory are:

Hardware:
    cdsCPU:            CPU architecture, speed, etc.
    cdsDiskType:       Local disk, SAN, NAS
    cdsStorageSize:    Total disk space
    cdsFSType:         File systems (VxFS, UFS, JFS...)
    cdsMemory:         RAM size
    macAddress:        MAC address. This is a standard attribute with
                       OID 1.3.6.1.1.1.1.22 defined in RFC2307
    cdsMultiHome:      If the system is multi-home, if yes then use
                       "seeAlso" to reference
    cdsPlatform:       Hardware platform family
    cdsDeviceCategory: Device category (Unix, PC, thin client, 
                       NetApp, printer)
    cdsOS:             Operating system name, version and level

Software:
    cdsAppicationName: What application(s) run on this host
    cdsLicenseName:    Licensed product name, such as Veritas 
                       Foundation Suite, including version
    cdsLicenseKey:     License number
      
Operation:
    cdsBackupBy:          Backup server name, if any
    cdsConsoleAccess:     System console access method
    cdsRootPasswordOwner: Who has the root password
    cdsSupportDocURL:     URL of support document
    cdsnisdomain:         NIS domain name
    cdsNTPserver:         NTP server configuration
    cdsDNSserver:         DNS server configuration
     
Business:
    cdsAssetTag:       Asset tag number
    cdsCriticalLevel:  Define the system criticality for support SLA
    cdsBusinessOwner:  Business point of contact
    cdsCostCenter:     Cost center
    cdsSystemType:     Workstation or server
    cdsRequestBy:      Person who requested to register this host

The attribute names should be as intuitive as possible for ease of use. Some rules for defining names can be found in this document:

http://www.iana.org/assignments/smi-numbers

Here we added "cds" as a prefix for all customized objectclasses and attributes. To establish enterprise identity, you may register a Private Enterprise Number through IANA; see:

http://www.iana.org/cgi-bin/enterprise.pl

For reporting purposes, it is best to make the values of these attributes follow a certain syntax, even though most LDAP data structures are any type of text strings.

With the above attributes, the LDIF file of a host entry in LDAP looks like this:

dn: cn=cds100.cds.com+iphostnumber=10.10.1.25,ou=hosts, ou=services,o=cds.com
cn: cds100.cds.com
cn: cds100
objectClass: top
objectClass: device
objectClass: ipHost
objectClass: cdsHost
cdscriticallevel: Desktop
l: B6 62072
owner: kzhan
description: Ultra2-kzhan
cdsapplicationname: LDAP/DNS/Sendmail sandbox
cdsplatform: Sun Ultra2
cdsos: Solaris 5.7
cdsrootpasswordowner: kzhan
ou: IT
cdsstoragesize: 20GB
cdscpu: 2 x 200 Mhz sparcv9
cdsmemory: 384 MB
cdsrequestedby: kzhan
cdsconsoleaccess: term-a, port7
cdslicensename: no licensed product
cdsdevicecategory: Unix workstation
o: CDS
cdssupportdocurl: http://localhost:8080
macaddress: 8:0:20:80:ee:de
iphostnumber: 10.10.1.25
manager: kzhan
cdsassettag: 035410
serialnumber: FW01203205
cdsbackupby: bs7
ACI

Most likely, system inventory is the responsibility of the IT support group. As such, each member of the support group should be allowed to update the record, while everyone is allowed to read only. For this, let's define an attribute "cdsSuperUserRole" and apply this attribute to all IT support personnel:

% ldapsearch -h ldaphost -b "ou=people,o=cds.com" uid=kzhan cdssuperuserrole
uid=kzhan,ou=people,o=cds.com
cdssuperuserrole=Y

Next, create a group with members dynamically generated from attribute cdssuperuserrole:

dn: cn=sysadmins,ou=Groups, o=cds.com
memberURL=ldap:///ou=people,o=cds.com??sub?(cdssuperuserrole=Y)
objectClass=top
objectClass=groupofuniquenames
objectClass=groupofurls
cn=sysadmins
description=System administrators

So, to allow only administrators to modify inventory information, the ACI is similar to this:

% ldapsearch -h ldaphost -b "o=cds.com" "(&(o=cds.com)(aci=*))" aci | grep sysadmins
aci=(target="ldap:///ou=hosts,ou=services,o=cds.com") 
  (targetattr!="cn") (targetfilter="(objectclass=cdsHost)")
  (version 3.0; acl "administrator permission"; allow (all) 
  (groupdn = "ldap:///cn=sysadmins,ou=groups,o=cds.com"); )

To help systems administrators, the owner of the system is also allowed to modify the record. Furthermore, to allow an automated inventory process (explained in next section), we need an application account. Because this account is only for LDAP data-updating purposes, it should be distinct from normal "user accounts". As such, this application account "uid=softario" is placed under a different branch, ou=groups,o=cds.com. These two access control policies can be achieved by setting the following ACI:

aci=(target = "ldap:///ou=hosts,ou=services,o=cds.com") 
  (& (targetattr!="cn")(targetattr!="owner") ) 
  (targetfilter="(objectclass=cdsHost)")(version 3.0; acl 
  "Owner Edit Permission"; allow (all) 
  (userdn = "ldap:///uid=($attr.owner),ou=people,
  o=cds.com||ldap:///uid=softario,ou=groups,o=cds.com");)

If there are other data fields that you wish to protect, modify the "targetattr" field in ACI accordingly. In the first ACI, the host name "cn" is protected, and the second ACI protects "owner".

Inventory Client

It is critical that any tools for inventory process be made available for people to use everywhere. This will maximize data accuracy and completeness. The goals of this tool are:

1. It can be run as a startup script under /etc/init.d or as a cronjob with a user-supplied configuration file. If no configuration exists, it runs to provide basic inventory data through auto-discovery.

2. Without a configuration file, it can be run interactively, accepting data from standard input.

Hence, data can be collected through three channels: auto-discovery, configuration, and interactive input. Auto-discovery means data can be collected via commands. For example, on Sun Solaris systems, we can define these attributes via shell script syntax:

cdsCPU="'/usr/sbin/psrinfo|wc -l'x'/usr/sbin/psrinfo -v \
  |grep MHz|awk '{print $6,$7,$2}'|head -1'"
cdsMemory="'/usr/sbin/prtconf|grep "^Memory"|cut -f2 -d:'"
cdsPlatform="'/usr/bin/uname -i'"

and incorporate them into the main inventory tool. Information about licensed products is not as simple as OS-related data. Depending on your organization's interests, the data may be collected through a series of commands and utilities. For example, to check whether an Oracle database is installed on a Solaris system, you could use:

% ps -ef | grep oracle |awk '{print $1}'

To check for Veritas Volume Manager, use:

% /usr/sbin/modinfo | grep vxio
 38 7801e000 116c78 156   1  vxio (VxVM 3.5s I/O driver)

Package-related commands (e.g., pkginfo on Solaris and rpm on Linux) are helpful in determining software installed on a system.

Through configuration, you can define some of the data in a pre-configured file. This is helpful when some data is not auto-discoverable or you want to overwrite some information. Let's look at the prototype of a configuration file:

% cat /etc/softario.conf
# Configuration file for software inventory / Project Softario
l: B6 62072
owner: kzhan
description: Ultra2-kzhan
cdsapplicationname: LDAP/DNS/Sendmail sandbox
cdsrootpasswordowner: kzhan
ou: IT
cdsconsoleaccess: term-a, port7
cdsdevicecategory: Unix workstation
cdsassettag: 035410
serialnumber: FW01203205

Because we want to allow the owner to update LDAP record, the mode of this file should be world-writable. Note that the configuration file does not have to include the entire list of all attributes, since some data will be automatically collected. Most likely, however, non-machinery data (e.g., asset tag, owner) must either be put into the configuration file or entered through an interactive session. This means the tool is manually executed, and data is entered interactively, either via command line or Web interface. In large organizations, interactive data entry is not as efficient as the other two methods.

The world-writable mode of this configuration file imposes some potential security risks. Some mitigation options for future improvement are: i) using sudo-type Role-Based Access Control to allow only IT and owners to modify; and ii) restricting access of this file to IT only and allowing end users to only modify LDAP records interactively since ACI can set the right permission on these data records. The second option is simpler to implement without massive changes of infrastructure.

If a data conflict occurs among these three sources, the interactive input data takes precedence, then configuration data, and finally auto-discovery data.

Inventory Requirement Changes

It is almost certain that additional inventory attributes will be added in the future. To avoid modifying utilities for each client when such changes occur, rather than hard-coding all the attributes, we first search all attributes under objectclass "cdsHost" to build an array of attributes that we need to update:

% ldapsearch -h ldaphost -b "cn=schema" objectclass="*" \
  objectclasses | grep -i cdshost
objectClasses=( 1.3.6.1.4.1.15925.2 NAME 'cdshost' SUP iphost 
  AUXILIARY MAY ( cdscpu $ cdsdisktype $ cdsstoragesize $
  cdsfstype $ cdsmemory $ cdsmultihome $ cdsplatform 
  $ cdsdevicecategory $ cdsos $ cdsapplicationname $
  cdslicensename $ cdslicensekey $ cdsbackupby $ cdsconsoleaccess 
  $ cdsrootpasswordowner $ cdssupportdocurl $ cdsassettag $ 
  cdscriticallevel $ cdsbusinessowner $ cdscostcenter $ 
  cdssystemtype $ cdsrequestby $ cdsnetworkspeed $ cdsprojectname ) 
  X-ORIGIN 'user defined' )

The above output can be parsed to obtain a complete list of attributes dynamically. Comparing this with our previous definitions, we see two additional attributes: cdsnetworkspeed and cdsprojectname. The assumption is that the first is for recording network speed of the system, and the second defines which project this system is for. However, the best way to interpret the definitions is to look for the original description (dictionary). In a comprehensive deployment of an LDAP environment, publication of such an LDAP dictionary is also a major task.

In practice, this tool can also be modified for various reasons. Hence updating all the clients with latest version is critical for the success. For that, we recommend using LDAP to store version number of this tool and every time the tool is executed, it checks LDAP server for the latest version and performs self-updating if the existing version is older than the one posted on LDAP server.

Figure 2 illustrates the data flow of the inventory client. This tool is also to be used for client-less devices, such as printers, switches, routers, etc. For these devices, inventory information can be only collected through interactive input, either through the command line or Web interface (see next section). SNMPv3 is also a potential option for automation).

Web Interface

A Web interface serves two purposes: it complements what a command-line utility can do to help non-computer-savvy users enter data, and it provides a reporting tool. The Web interface is based on a gateway concept from Sun ONE Directory Server Resource Kit (DSRK) version 5.2. This toolkit comes with an LDAP Tag Library (TL) in XML format and samples of JavaServer Page (JSP) code for phone book lookup. This gateway has another feature that can be used for LDAP application development: it provides a generic interface for applications so end-user applications do not need to operate at the LDAP protocol layer, but can operate at the HTTP layer with POST method.

By extending the functions of phone book lookup in DSRK, you can build a Web interface that allows end users, based on the roles defined in backend LDAP ACI, to query and modify any LDAP entries.

Conclusion

In any IT organization, a successful program for system inventory helps improve support SLA, control overall IT costs, and increase computing resource usage efficiency. In this article, we presented a simple concept and practical considerations for using an LDAP infrastructure to collect inventory information.

This concept is very flexible; it can be as simple as writing a short shell script using "ldapmodify" to update LDAP entries, or as complex as providing both command line and a comprehensive Web interface. The main benefit of using LDAP versus commercial software is that if you have an LDAP infrastructure already, no additional software is needed. Also, with LDAP becoming more and more a commodity tool, building the infrastructure from scratch using open source tools, such as OpenLDAP, is not as complicated as managing commercial RDBMS software.

Acknowledgements

I wish to express my sincere thanks to Hal Pomeranz for his very insightful comments and suggestions.

Kaijun Zhan has a PhD in mathematics and has been a systems administrator since 1992. He is currently IT Architect at Cadence Design Systems. His areas of interest include architecture design in DNS, NIS, Messaging, LDAP, and security. He can be reached at kzhan@cadence.com.