02
Sat, Nov
2 New Articles

Resource Management the Directory Way

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Long, long ago (at least in Web years), in a place far, far away, a guardian of the counting beans assumed a new position. The guardian’s new task was the administration of supplies for the director of manufacturing, a mission sought by all junior-grade members in the bean-counting community.

After initializing her personal cyber-terminal, the guardian supplied the appropriate inputs necessary to access the supply-management system, to which the terminal responded, “Access Denied!”

“How can that be?” the guardian cried. “I’ve made an appropriate application for access to the director of the binary wires. How could it deny me so?”

The guardian immediately picked up her vocal communication portal and punched in the numeric address of the assistance pod. After a short routing period filled with musical sounds of the season, a helpful assistance technician connected to the vocal channel. After describing her difficulty to the technician, the guardian asked what the issue might be.

“Well,” the technician responded, “let me take a look. According to my records, access to that particular functional complex requires 22 separate management definitions, all of which are under the control of different directors. If you would like to remain on the line, I can begin investigating which definition may be in error.”

After some grumbling from the guardian, the technician went on to say, “One option may be to use the access coding assigned to your immediate predecessor. It may then work properly, since it often takes months to remove someone from the system and seldom is that person ever removed completely.”

“Is there a better way?” The guardian asked the technician. “Absolutely,” was the reply, “We could have a directory!”

Is this a common situation in your own environment? Virtually every system, server, application, network device, workstation, and even the voice-mail system, has its own way of defining users and what they are able do. In my own very small shop, we maintain separate user directories in a production Microsoft Windows NT server domain, a test NT domain, four iSeries systems, a separate email system, a remote access server, and several software applications. Adding and removing users is a significant task and often requires a lot of calendar time to get all of the nuances and interrelationships right.


This is, however, not a new issue, and there was a realization in the IT community long ago that a common management point for users, applications, and resources is a good idea. Just think how simple things would be if a departing staff member could be disabled from all company resources, right down to the voice-mail system, with a single entry, in a single location. Such a capability is called a directory. In this article, I will discuss a bit of the directory’s history, outline the current state of the directory, and mention some of the things you might want to be thinking about as you make system and application decisions.

X.500 Gets Things Started

In 1984, a study group that became the International Telecommunication Union proposed the concept of a standardized directory. One of the key reasons for creating a directory was to allow users within an organization and among organizations to easily locate the email address of another individual—and to do so in a standard fashion. It was a dream for worldwide electronic white pages.

The final definition of the X.500 directory standard was published in 1988 and extended in 1992. It defined the databases and protocols that would allow applications and users to communicate within a directory. Another key aspect of X.500 was the ability of directories to connect to each other, which would allow an organization to recognize the authority established by another.

X.500 was a good thing, but it was also a complicated thing. It required specific

databases and was based on the Open Systems Interconnection protocol model (remember that?), and therefore it was not widely used. Although there was still a need for directories, few organizations were willing to take on the challenges of implementing the X.500 standard.

So the Internet standards community, still wanting a set of directory services, yet realizing the complexity of X.500, set out to define an all-IP implementation, known as
X.500 Lite. The result was RFC 1487, which defined the Lightweight Directory Access

Protocol (LDAP). Accepted in 1993, LDAP, unlike X.500, did not define a specific database and the elements within that database; it defined a way of communicating with a directory database and the protocols to be used in such communications. Vendors could now implement directories as they wished, and there could be a common means of accessing those directories. This was a noble concept that created its own set of issues, which I’ll discuss a bit later.

Following quickly on the heels of RFC 1487, in 1995, was RFC 1777, which defined LDAP 2.0. The 2.0 version of LDAP addressed some shortcomings in the original specification, particularly some significant performance bottlenecks.

Despite the improvements in 2.0 LDAP is not static. RFC 2251, which defines LDAP 3.0, was published as a proposed standard. It adds some functionality in the way LDAP addresses security, provides support for Unicode characters, and allows for more extensibility than that which is available in LDAP 2.0.

Then in 1994, Novell rocked the IT community with the announcement of its Netware Directory Services (NDS). Those who understood what NDS meant for a network of servers were ecstatic about the announcement, although many in the community were still wondering what a directory was. With NDS, you could manage all of your organization’s Novell users and resources from a single place. Users were no longer defined individually to each server. Define them to NDS, associate them with the resources they are allowed to access, and all was good. The primary alternatives in the file- and print- sharing segment of the industry at the time were the IBM OS/2 LAN Manager and the Windows NT Server, both of which used a domain management model, not a true directory.

NDS was, and still is, a good thing, but it primarily finds its home in managing a network of shared files and printers. Not many application programs use its services, and Novell only recently made an LDAP-compatible interface available.


The Microsoft Factor

As I have noted, Microsoft used a domain-based user-management system with its NT server product line. The concept was developed for the OS/2 LAN server and was a directory of sorts. The domain directory was not LDAP-compliant and had difficulty operating whenever communication was lost between the server and the domain server (an issue specifically addressed in the LDAP specification). Applications could not use domain services for resource management, so things like email accounts and database authorities had to be defined elsewhere.

Microsoft was taking over a huge share of the server market with Windows, but Novell was still hanging in there, due in part to NDS. I suspect that in the interest of gaining even more market share, Microsoft made the release of Active Directory Services (ADS) a large part of its original Windows NT 5.0 (eventually renamed Windows 2000) server announcement. ADS would now provide the sort of services that were previously available only in NDS, and it would also support standards like LDAP.

But Microsoft needed to address the directory issue in order to compete with Novell, even though one of the positive effects of the ADS announcement was a renewed interest in directories and in the services they could provide an organization.

What’s in There?

A directory is simply a well-defined place to put information about users, applications, and resources. This information is then associated in a way that manages a user’s authority to resources and to the components of an application.

The database of a directory needs to be flexible. It must be able to adapt to the specific needs of the resource as well as the organization. LDAP makes this happen through schemas. A schema is defined and loaded into a directory. Management records are then loaded into the directory using the defined schema. An application or resource can query a directory, using a common API, and determine whether a user is authentic and whether the association (or lack thereof) between a user and a resource is authentic.

LDAP directories are organized hierarchically like an inverted tree. There is a root node, followed by nodes that may represent organizations or applications. The next layer could contain departments or application components, under which another layer could contain users and application functions. The depth of the hierarchy depends on the implementation of a vendor’s schema.

LDAP queries can search up through the hierarchy and back down again in order to locate the appropriate resource information. Through this query mechanism, users associated with one part of an organization can either have access to resources in another part of the organization or have his access limited to only specific parts of the tree.

Variable schemas make LDAP very flexible but can also cause problems. Vendors are free to define their own schemas, and, in fact, Microsoft took some freedom with its definitions within ADS. There was a sort of de facto schema used within many LDAP implementations, including the OS/400’s, that made it possible to at least guess where information might be located, but Microsoft chose to add another unique layer in its hierarchy. Current applications that work with LDAP servers likely will need some modification to operate with ADS.

The Java community recognized the necessity of directories within its standard. A set of classes under the title of Java Naming and Directory Interface (JNDI) supplies a means, from within a Java program, of accessing LDAP directories, as well as other naming services, such as Domain Name System (DNS). JNDI is technically directory- independent, although most implementations rely on LDAP.


LDAP in OS/400

Since V4R3, LDAP has been included free in OS/400 as part of Directory Services for OS/400. Check to see if you have Option 32 of 5769-SS1 installed. If you do, there is an LDAP server available, along with a complete set of LDAP clients and utilities.

The LDAP server uses DB2/400 for storing the directory information and is configured using Operations Navigator. OS/400 commands are not available for managing the server, other than the ones for starting and stopping it. The server is started and stopped either through Operations Navigator or by using the *DIRSRV option of the Start TCP/IP Server (STRTCPSVR) and End TCP/IP Server (ENDTCPSVR) commands, respectively.

The OS/400 LDAP client supports the accessing of any LDAP server from all of the OS/400 ILE programming languages: C, COBOL, and RPG. The standard API set is implemented, so LDAP skills developed in an ILE application will transfer to other platforms. An LDAP client for Windows is included with OS/400 Client Access, and a Java client is included in OS/400’s support of JNDI.

Also included is a set of command line utilities for accessing an LDAP server from Windows and OS/400. These utilities are compatible with the LDAP utilities provided for other operating systems, and they allow you to search, add, modify, and delete directory information.

The OS/400 LDAP server and database are separate from the traditional OS/400 directory, although a replication mechanism is available for keeping either the local LDAP directory or any other LDAP directory in sync with OS/400. The Operations Navigator server properties dialog box contains a Directory Update tab. On that tab is a list of resources that can be synchronized into the directory, one of which is Users. With this option configured, users are added to and removed from the LDAP directory, as the traditional directory changes, by using the Work with User Profiles (WRKUSRPRF) command.

Unfortunately, there is not yet a way—except in a completely custom environment—to use the LDAP directory exclusively within OS/400. I expect this will change at some time in the future as OS/400 moves away from the green-screen. Such a move would also be consistent with IBM’s commitment to Internet standards.

Where ADS Fits

Because of the extreme proliferation of Microsoft servers, many shops will have an ADS server installed at some point in the near future. Doing so places another LDAP server in the environment and replaces the clunky domain-based management system of the NT Server.

The LDAP client in OS/400 could certainly use the ADS server for application security. New applications for the Windows environment will likely use ADS for their security needs, and there may be some opportunity to share a user definition between a Windows application and an iSeries application.

The OS/400 directory also could synchronize with the ADS directory, although I don’t know anyone who’s tried it yet. That could allow user definitions on the iSeries to propagate to ADS for use in other applications. Given Microsoft’s rather unique schema definition, however, I’m not sure it will work.

Another option might be to lobby IBM to include OS/400 support for ADS as the primary directory. Somehow, I don’t believe that will happen soon, but I may be wrong.

A Possible Strategy

LDAP looks like the directory protocol of choice for the foreseeable future. This means that application and platform support for the protocol will expand over time, making it realistic to expect that the use of a single, common directory is an achievable goal.


The first step would be to get comfortable working with LDAP. There are a variety of good resources available on the Web, like Network World Fusion’s Research page for directories (www.nwfusion.com/research/ directories.html). There are also a couple of good books, such as Implementing Directory Services and Understanding and Deploying LDAP Directory Services.

Another step would be to start the server on OS/400, replicate the OS/400 directory into the LDAP database, and start poking around with Operations Navigator or some of the command line tools. That should give you a feel for the structure of a directory and what its possible uses are. There are also a number of directory exploration tools available on the Internet that can supplement the standard ones.

Consider using LDAP for resource management when developing your next application. If you’re using Java, the standard JNDI interface will allow access to an LDAP directory with little or no pain. If your application is in an ILE language, take a look at the LDAP API set. See if it is practical to use the LDAP directory instead of creating your own security mechanism to control access within the application. This could be the fastest way to get a directory into production on your network. Such a strategy may seem difficult initially, but it could pay off in the future.

The addition of LDAP support to many existing directories is making another option practical, that being the concept of a metadirectory. A metadirectory exists as a layer over other directories, typically providing a single user interface that will update the back- end directories based on a set of update rules. This sort of mechanism could keep a series of directories up to date without having to get all applications and platforms talking to a single directory.

Consider asking your application providers what their directory integration plans are. Many commercial products I’ve seen use their own security infrastructures and could simplify the management of their applications through integration to a standard directory. If enough people within the user base ask for LDAP function, there is a good chance of getting it.

Ultimately, standards must prevail. There is some motion in the industry toward a common LDAP schema. As I noted before, there are de facto standard schemas. Vendors just need to get together and settle on a common way. The vendors also need to apply those standards to their products. As always, what Microsoft chooses to do or not do will be the wild card in the standards effort.

Directory support needs to be considered in everything you purchase. That includes devices like phone systems and networking hardware, along with application software and operating systems. Industry initiatives to incorporate LDAP support in traditional hardware devices are underway, and products may become available in the near future.

If you concentrate on developing systems and buying products that support LDAP, it may soon be possible to add a user to every system in your network from a single management point. Likewise, it may be possible to remove or disable that user from a single management point.

The next step beyond implementing directories in your environment is to integrate with other organizations’ directories. The Universal Description, Discovery, and Integration (UDDI) project—supported by IBM, Microsoft, and others—is a comprehensive initiative that should enable businesses to discover each other and to define how those businesses interact over the Internet. Access to directories like UDDI will make B2B e-business applications self-defining yet allow them to remain secure. You can keep an eye on the progress of the UDDI project at www.uddi.org.

A single, common directory will truly be a panacea. It will be simpler to manage and substantially more secure than anything now available. I’d like to write more about it, but right now I have to go to the server room and add a new user to three different directories. Honestly!


REFERENCES AND RELATED MATERIALS

• Implementing Directory Services. Archie Reed. McGraw-Hill, New York City, 2000

• “Introduction to X.500,” Timothy A. Howes, Ph.D., Mark C. Smith, and Gordon S. Good, Cisco Knowledge Suite, May 30, 2000, www.knowcisco.com/matter/ tut1000007

• iSeries 400 Information Center (LDAP): www.iseries.ibm.com/infocenter

• Network World Fusion Research Directories: www.nwfusion.com/research/ directories.html

• UDDI Web site: www.uddi.org

• Understanding and Deploying LDAP Directory Services. Timothy A. Howes, Ph.D., Mark C. Smith, and Good S. Good. MacMillan Technical Publishing, Indianapolis, Indiana, 1999


BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: