Upon receiving the UDP packet, TED reads the indicated service table from the database. [Note 4] Then TED sends a UDP packet to each subscriber host it finds in the service table records. The UDP packet signals the host(s) to start UFRD. The host's UFRD makes a TCP connection to TED and reads its information updates. When a change is successfully processed, UFRD sends TED an acknowledgement and the matching service table record for that host is removed. A TED service table record is kept until an acknowledgement is received so failures with UFRD can be retried.

To handle subscriber hosts that do not request their information updates, TED periodically reads all service tables' unprocessed data records. For each system with pending updates, TED sends another UDP notification since the subscriber host may have been down or unreachable. To summarize, information change notifications are sent to subscriber systems in near real-time and resent until successfully processed and acknowledged.

Because the information is stored in the database, state is maintained even if TED or the UFRD clients should terminate for unexpected reasons. TED will send an e-mail notification to the administrator listed in the TED's hosts table if a subscriber has unprocessed requests over two hours old.

Update Fields Real-time Daemon

A UDP packet from TED starts a UFRD on a subscriber host; on UNIX systems UFRD is started by inetd. The packet contains a port number to connect back to on the TED system. UFRD first reads its configuration file to find the encryption key to use with the TED system that sent the UDP packet. UFRD then makes a TCP connection to the TED server and sets up DES3 encryption using the key it found. UFRD receives the pending information updates and, based on the table name field, executes the appropriate command to process the data. The information update line(s) are passed to the command as standard input under UNIX and message passing under Windows NT. If the command exits successfully, UFRD indicates to TED to remove the corresponding record(s) from the TED service table.

The commands called by UFRD to update information may be written in the most convenient method: C, C++, Perl, Python, shell script, or some specialized interface for the service. The Perl code to process e-mail forwarding address changes is in Figure 7.

#!/usr/bin/perl
use Net::LDAPapi;
use Sys::Syslog;
# Update inetMailRecipient object.
# Changes read from stdin look like:
#   table|action|name|fwd_address
$local_domain = "lanl.gov"
$sep=chr(255);  # Separate fields with char 255
$ROOTDN = "cn=root, o=Los Alamos National Laboratory, c=US";
$ROOTPW = "oob";
$ldap_server = "ldap.lanl.gov";
&openlog("ufrd.LDAPmailRecipient",'pid','daemon');
&Sys::Syslog::setlogsock('unix');
$ld = new Net::LDAPapi($ldap_server);
if ($ld == -1){
   &syslog("err","Connection to $ldap_server failed");
   exit 1;
}
if ($ld->bind_s($ROOTDN,$ROOTPW) != LDAP_SUCCESS){
   &syslog("err","LDAP bind error: $ld->errstring");
   exit 1;
}
while (<>){
  chomp;
  ($table,$action,$name,$fwd_addr)=split($sep);
  $ENTRYDN="cn=$name, objectClass=inetLocalMailRecipient";
  # Treat update add/deletes same as regular add/deletes
  if ($action =~ "DELETE" || $action =~ "UPDEL"){
    if ($ld->delete_s($ENTRYDN) != LDAP_SUCCESS){
      &syslog("err","LDAP delete error: $ld->errstring");
      exit 1;
    }
  } elsif ($action =~ "ADD" || $action =~ "UPADD"){
    %ldapdata = ("cn" => $name,
                 "objectClass" => "inetLocalMailRecipient",
                 "mailLocalAddress" => "$name==[@]==$local_domain",
                 "mailRoutingAddress" => $fwd_addr);
                 "
    if ($ld->add_s($ENTRYDN,%ldapdata) != LDAP_SUCCESS){
      &syslog("err","LDAP add error: $ld->errstring");
      exit 1;
    }
  }
}
$ld->unbind;
exit 0;

UFRD has been ported to several operating systems including Linux, Solaris, UNICOS, Irix, and Windows NT. Its simple functionality relying on running native commands to update local data allows quick porting to new platforms.

Future Plans

The group has several future improvements planned for the ARTIMUS system.

Extending ARTIMUS to other network information systems is foremost. Generating dynamic DNS updates is a goal for the next year. Our host information is already maintained through a web interface and kept in a Sybase database but does not use ARTIMUS. The difficult part will be reconciling the names' owners.

Offering the service to other Laboratory organizations has begun and will be expanded. Given the flexible and secure ARTIMUS framework, it is easy to provide central account management services to network servers throughout the Laboratory. Adding a Network Registry module, a few database tables, constraints, and triggers, as well as writing an update command for UFRD service to call, is not difficult.

The Network Registry continues to grow. Currently, we are redesigning much of the look and feel in attempt to make it easier and more intuitive for the end-users; user interface design is non-trivial. Various business and integrity checks continue to be added, both within the Network Registry and the database.

ARTIMUS needs additional rules to prevent inappropriate bulk changes from happening. Occasionally, we receive a large, but bogus, data feed from the corporate data warehouse that must be detected and rejected.

We would like to get real-time updates propagated from the Lab's corporate sources to pass along to end customers. Such real-time linkage would allow new employees to request accounts upon arrival (and have them created in real-time as well, thanks to ARTIMUS), plus automatically disable authentication and authorization accounts the moment they are terminated in the human resource system.

We would like to examine the use of individual user accounts within the database and direct authentication to the database. The tradeoffs of security benefits versus complexity may or may not make this practical. For various security issues we are considering moving from Sybase to Oracle and using Oracle's Kerberos and RADIUS authentication. Oracle's DBMS ALERT package may also be superior to the current UDP-based database notification mechanism for TED.

Additional issues, ideas, and plans will come up as we add new services and think up new methods to use the system.

Conclusions

The ARTIMUS design, including its web interface, relational database with built in data integrity, real-time update service, and data protection provides a solid base for eventually managing nearly all of the Laboratory's account and network information data. We are optimistic the implementation will meet or exceed the requirements listed in the Motivation section and discussed below. Ultimately, we will measure the system's success by the number of subscribers it supports.

User Interface Requirements

Users can manage their own network information through the Network Registry. Web based applications with authentication are commonplace at Los Alamos. Most customers will be able to easily maintain their own network profiles. Keeping the navigation simple, intuitive and consistent as features are added will be a challenge.

Subscriber System Requirements

Adding subscriber systems to ARTIMUS requires new entries in the TED tables, a UFRD daemon, a UFRD service application, a configuration file, and a shared DES key. The total installation time is usually under an hour.

Currently, 99 percent of the changes to the database are propagated to the subscriber systems in under two seconds via TED-UFRD. We expect the mean response time and standard deviation to both shrink when we retire some frequently run ad hoc database query applications.

System Administrator Requirements

There are a few system administrator features in ARTIMUS that are outside the main theme of this paper. We will briefly mention them here. Common system names like ``root'' are reserved, as are UNIX UIDs and GIDs under 1000. OS, third party, and local software that define users and groups can coexist with ARTIMUS. System administrators can define their subscriber systems as open or closed. Users can add accounts to open systems but only system administrators or their designees may add accounts to closed systems. Finally, we have defined organization administrators who can manage most information for anyone in an organization, and name administrators who, in addition to the owner, can change any of a name's attributes.

ARTIMUS Requirements

ARTIMUS already supports UFRD on a variety of operating systems (Figure 8) and services (Figure 9) but not all services are supported on all OSs. The first UFRD for a UNIX system took about a month to write and debug. The first UFRD for Windows NT also took about a month. Bringing up subsequent UNIX UFRDs is proportional to the time it takes to locate the necessary system include files and libraries.

UFRD agent scripts as seen in the LDAP e-mail address example (Figure 7) are usually simple and straightforward to write. The approach is: read standard input; split the line into an array (or list); and execute some existing application to add, delete, or modify some local data file. A Perl program to manage Linux user accounts by calling adduser, deluser, and moduser is 36 lines long.

The current ARTIMUS implementation is reliable. We do health checks on our services every few minutes throughout the day. When a service is down for five minutes or more, an on-call person is paged. The last six months of web, database, and TED error logs show only four transient failures. Connecting to the web server failed twice and connecting to the database also failed twice. There were no prolonged failures resulting in an alarm page.

Since subscriber systems depend on ARTIMUS for updates, downtime is only noticeable to users wanting to make changes. Clearly, the main thing to avoid is losing the database. Backups and mirroring are both done.

Oddly, overall network service availability can actually be improved by adding a central database. LDAP and RADIUS are important services to the Laboratory. ARTIMUS makes replicating these servers as easy as deploying a system and adding a hostname to the TED host and service tables.

Data integrity is a key feature of ARTIMUS. It is also the most complex to implement. But, when done correctly, it promises the biggest rewards from the system. Our most difficult and time consuming problems are usually caused by incorrect, incomplete, or inconsistent data on one or more server systems. ARTIMUS prevents these problems by simply rejecting bad information before it goes into the database.

Finally, security is an essential part of the ARTIMUS design. This system would not be deployed at Los Alamos if it did not protect users' network information.

Availability

Due to U. S. encryption export regulations, release of the source for the TED-UFRD propagation system must be controlled. Those interested in obtaining the source code may contact the authors directly to determine the necessary arrangements. Licensing restrictions beyond the export issue are otherwise liberal.

The web pages and database currently include many LANL idiosyncrasies. They would probably require significant changes to work elsewhere and therefore are not available at this time.

Acknowledgements

The authors would like to thank Los Alamos' Network Services Team. ARTIMUS is a product of the entire team's hard work and expertise. Particular recognition goes to Mary Gentry for her extensive work on the database design and implementation and her extraordinary commitment to detail. Susan Buchroeder was responsible for the Network Registry design. Amy Meilander provided the excellent database figures and lent us the use of her name(s) in the examples throughout the paper. Thanks to Jerome Heckenkamp, Elise Lee, and Giridhar Raichur for their constructive criticisms and thoughtful editorial comments. Finally, we are grateful to our supportive manager, Kyran Kemper.

Author Information

Alexander (Alex) Kent is a Systems Software Engineer for the Network Engineering Group at Los Alamos National Laboratory. His primary development projects include Laboratory-wide authentication and user account systems, network information propagation, and the Los Alamos firewall system. In addition, he is a full time graduate student at the University of New Mexico nearing completion of an MBA. Alex has a BS and MS in CS from New Mexico Tech. He may be reached via e-mail: alex@lanl.gov or snail mail: MS B255, Los Alamos, NM 87545.

James (Jim) Clifford is the Network Services Team Leader and a Systems Software Engineer for the Network Engineering Group at Los Alamos National Laboratory. His interests include Internet technology, Linux, and practical computer security. Jim has a BS from the University of Michigan. He may be reached via e-mail: jrc@lanl.gov or snail mail: MS B255, Los Alamos, NM 87545.

References