Novell is now a part of Micro Focus

What It Really Means to Be Integrated with NDS eDirectory

Articles and Tips: article

David S. Condrey
President of Condrey Consulting
Development Manager of Omnibond System
davidc@condreyconsulting.com

01 Jul 2000


Novell has long been touting the technical, strategic, and business advantages of integrating with Novell Directory Services (NDS). This AppNote takes a big-picture look at what true directory integration is and provides a few examples for technical analysts, administrators, and programmers.

Introduction

From the title of this document, it should be apparent that the content is subjective in nature. This is not a tutorial on how to accomplish a task with NDS and there are no solid right or wrong answers here. The intention is to convey something of a philosophy or mindset that is successfully applicable to the design, development, deployment, management, and growth of an enterprise-level computing environment built on a directory.

There are plenty of successful methodologies with respect to information technology infrastructure. However, many of these are only marginally successful when applied at the enterprise level. As you may guess, it takes a different approach to deployment when working at this level and there are many aspects to consider when making decisions. Many times you must give up some whipped-cream features to achieve industrial level stability and management. You have to be willing to make these decisions and deal with the people who want whipped-cream features. The directory is an enterprise-level construct and therefore should be treated as such.

I have worked with NDS since 1994 and have achieved a good deal of success in deploying and managing NDS in a large environment (more than 35,000 users). I have also been a developer within this environment for over 5 years, developing to both the server and client platforms. My team and I were recognized in the finals of the 1999 Novell Developer Contest in both the Custom Application and Commercial Application divisions. I keep myself busy as the development manager for a soon-to-be-released security product from Novell, as president of my own private company that develops and markets NDS software in over 20 countries, by teaching multi-day NetWare and NDS development classes, and by consulting with third-party companies. Oh yes, I also occasionally write articles for Novell.

The point of all this is that I have a great deal of interaction with many NDS administrators, programmers, and users. I am familiar with the trials and tribulations at these levels, as well as the rewards of doing things in certain ways. So, let's get started with our discussion of what it really means to be integrated with NDS eDirectory.

The Importance of Integrating with eDirectory

The directory is a far-reaching concept, and true directory integration affects everyone. This article contains design methodologies for NDS administrators, guidelines for CIOs, and tips for programmers. There is some technical information that may require further study, but let me assure you that everything presented here is applicable to anyone integrating with NDS eDirectory.

If you are currently a CIO or technical analyst, you may be interested in ways for your current installation to improve its leverage of the directory. You may be pondering a leap into the directory world for the first time or moving from another directory service. If so, you will see why NDS is such a powerful tool when leveraged correctly.

If you are currently an Admin with little NDS programming experience, you will see why it is important to have at least a cursory knowledge of NetWare and NDS programming, as well as have this knowledge present on your staff.

If you are currently an NDS programmer, you will see some enterprise-level administrative concepts that may be new to you and might therefore influence your programming and design methodologies.

Why You Care

It's obvious from the fact that you are reading this article that you are concerned with the deploying and leveraging aspects of NDS. This confirms that you do care; but maybe you don't realize why.

If you successfully integrate your organization and/or software with NDS, you can probably come as close to computing nirvana as possible with today's technology. I have stated publicly that I think NDS is the most significant thing put on the network since TCP/IP. Why? Because we are living in a world of heterogeneous entities and computing environments, each critical to the mission of the enterprise as a whole. There are NetWare file servers, UNIX mail servers, Mainframe database servers, and NT web servers on almost every network. No one OS can do it all, and successful integration means having all mission-critical components working together. NDS and Novell products shine at bringing all these things together.

But that's just the technology part, and these are just tools. There are also managers, policies, departments, users, and data. When you think about it, the mission-critical components are not servers or technology, but people and data. The technology, when applied correctly, merely facilitates this interaction. That is a sobering thought to people and companies that spend their days toiling to improve the technology. However, that's where you and NDS come in--to set the infrastructure that can be applied across the board to improve the mission- critical aspects of users, groups, and the organization as a whole.

We are now beyond the phase where the directory was essentially a phone book. The key to real NDS integration is enabling and enhancing secure collaborative works between entities within the organization through the use of NDS.

Mantra: NDS is a Tool

As you manage NDS as a directory and write applications for it, don't lose sight of the fact that it is a just a tool. As with any tool, correct use is based on acquired and honed skills. This means it must be used correctly and in the right situations. Using the directory just for the sake of using the directory happens more than we would think. There are jobs for which NDS is simply not suited. Replacing your relational transaction read/write accounting database with NDS leaps to mind. However, using NDS to control access to that database from any type of client platform is perfectly acceptable.

To really get the most out of NDS as a tool, you must understand how to write code for it at some level. This may mean anything from using Active-X controls with Visual Basic to using the C API in a multi-threaded NLM environment. Think of NDS as a Swiss Army Knife. If you are managing an NDS network and aren't able to write code for NDS, you are effectively only using the small blade of the knife and don't know that the scissors or can opener even exist.

The User

Nearly all ground-breaking "killer" applications have one thing in common; they create an environment in which individuals are more productive with their time or meet some need that the user community has. As previously mentioned, the users are the reason we are all here and the user object is the center of the directory. Everything else is just ancillary in nature and exists only to help the individual be more productive.

It is important to think about how your design will positively impact the life and actions of the users as you design the NDS structure of a tree as well as when you write code for it. This may seem like a given, but this aspect of design is often overlooked, especially when it comes to server or network resource management applications.

Ask yourself the following questions as you refine the design:

  • What will be the user's view of the application as it relates to the rest of the directory?

  • Does my application promote collaboration or leverage existing structures within NDS on behalf of the user?

  • Does my application leverage the organization's structure, personnel, and policies defined through the directory on behalf of the user?

Lastly, for the directory to be truly useful as an enterprise resource, all individuals in the organization need to be reflected in the directory with a user object. This is true even if the individual would not be considered a "computer user". The user is a part of the organization and for the directory to be reflective of the organization all entities must be represented.

The Organization

Building out from the user, we use NDS to develop relationships between users and resources. The manner in which this is done is different for each organization.

The organization and its policies must be adequately reflected in the directory. The use of the organizational design model is imperative here. That's not to say that any design approach other than the organizational model is incorrect. In fact, we will see in a later section that the tree design should lend itself to automation and that may dictate a hybrid design. However, the organizational approach must be reflected to some extent and the fact that it can and should be incorporated into other models is important. The important thing to note here is that sometimes tree design is dictated by those management actions you intent to automate with utilities.

Within the organizational design model, there is a rigid hierarchical structure that on most occasions describes departments and workgroups within departments. These constructs serve well for autonomous work within the group or department. However, the mission of the enterprise is often related to having users be able to work across this hierarchal structure. That is, users need to interact and share data with users in other groups or departments and departments as a whole need to do this.

As you develop code and applications for NDS, you will find that tools to facilitate this type of interaction are the most successful, and the most lacking. This is true for both in-house and commercial application development. These are the types of things that NDS can only accomplish for you if you bring them out using the API. This can be done on a commercial basis and seems to be an area where there is a need across the board and tremendous opportunities exist. Development can be done on a local basis to really have NDS reflect your operational policies and procedures as well as how your organization interoperates with itself.

As is the case with users, each part of the organization should have representation in the directory. The old adage, "If I build it, they will come" applies here and is a much better strategy than getting everyone onboard and then building the infrastructure. I have seen this strategy work repeatedly as a method of getting all parts of an organization involved in leveraging the directory. Commercial developers should develop tools that can be used to either facilitate the building of this infrastructure or leverage it afterward.

The Intersection

The place where the user and the organization come together is in the security and management of the enterprise data. If all users and parts of the organization are represented and the directory appropriately reflects the relationships within the enterprise, then we can begin to apply those constructs to the data itself in multiple operating system and application environments.

The obvious first step is uniform authentication. Developers should not authenticate users to multiple authorities. This leads to confusion for the user as well as support personnel. Administrators should not purchase applications that use application-specific authentication credentials. By using NDS as a centralized authentication authority, we can create the beginnings of a consistent computing environment for all users.

The next step is authorization. Once the user has authenticated, developers must determine if the user should be given access to the data. This is authorization. Developers should not use multiple authorities or application- specific authorities for security. There is no need to do so because the relationships are already maintained correctly in the directory. This relieves the application developer of an incredible responsibility, improves network administration, and most importantly makes the security environment predictable for the user.

There are new products available from Novell that allow developers to leverage authentication credentials as well as authorization assignments in the directory from heterogeneous platforms using an API. Later articles will explore this API and its use in various environments.

A larger goal is to have customer representation in the directory with tools and constructs that facilitate the management of these entities. The customer is a part of any successful organization and should ultimately be reflected in the organization's directory. Developers should expand on this necessity perhaps by expanding on the base schema with new classes to adequately represent a customer. Make schema extensions count and relate NDS appropriately to the business process with respect to customers.

The Automation Imperative

Within large organizations, it is very important to design the tree and develop tools that facilitate automation. For example, in a tree with thousands of users, it often does not make sense to have departmental administrators create the users by hand when they join the organization and clean them up when they leave. It makes more sense to have this procedure tied to the transactions in the personnel system for the organization.

From a tree design perspective, this may mean slight or major modifications to the classic organizational model for tree design. This decision may lend itself to more centralized user administration. In general I believe that this is a good thing. However, you must define your user placement and rudimentary user interaction strategies up front so that the automated user management process can adhere to them.

From a programming perspective, this means that you must be able to take action on user management events so that it fits the defined strategies. There are several canned methods of creating users in bulk, but these will probably not reflect the policies and structure of your organization appropriately. It is up to you to develop code to adhere to these methodologies.

It is important to note that just creating the objects in the tree is not enough. You must also programmatically define other resources on the network in which that object is counting on (ex: disk space) and establish relationships between that object and the resources (ex: trustee assignments) as well as the relationship between that object and other objects in the tree (ex: group memberships).

Using NDS-enabled Products as Infrastructure Enhancers Only

In development vernacular, it is common to speak of your toolbox as the holder of the tools in your development arsenal. As a Novell and NDS developer you probably would list the following as the contents of your toolbox:

  • Your compiler

  • The NDK

  • Maybe some wrapper functions (particularly for NDS API operations)

It is said, "Anything worth doing must be able to be applied to itself". One thing that most developers don't list as toolbox inhabitants is other Novell or NDS-enabled products. Most products are standalone in nature (except for the requisite client OS with Client32 or the NetWare OS). As a commercial developer, what better way to insure adoption of your product than to improve the customer's leverage of existing Novell products? Or if you are an in-house developer, what better way to bring your directory and software installation full circle than building on your existing software base and integrating it to your environment the way that your organization does business?

For some developers, as well as administrators, this means a change in mindset. This change involves leaving behind the idea of counting on NDS-enabled products to be your infrastructure and adopting the idea of using NDS-enabled products to build your infrastructure. The difference in language is subtle, but

the difference in thinking and application is vast. Once adopted, the new way of thinking about development tools is empowering. Maybe you missed it so I'll say it again, "Stop simply counting on NDS-enabled products to be the infrastructure and start using them as tools to build your infrastructure."

When people say things like the above statement to me, I sometimes need an example in order for them to really "get it". So, let's look at an example." Most everyone is using ZENworks and Application Launcher these days to deliver applications to users based on some set of application associations (see Figure 1).

Figure 1: ZENworks lets you deliver applications to users based on application associations.

What you see at first glance is application objects associated either directly or indirectly with this user that allow the user to run applications. But with a little thought and programming, Application Launcher can do much more.

As we have discussed, using NDS to enable collaborative works between people and entities within an organization is the key to true NDS integration and should be a goal for both administrators and developers. One of the keys to collaboration is the exchange of data and access to data locations.

Consider using the API to create and associate App:Application objects that allow Application Launcher to serve as a segue to disk space instead of applications.

By using EXPLORER.EXE as the application with the file system folder specified as the command line parameter, NDS and Application Launcher can be used to replace much of the functionality classically under the domain of login scripts and drive mappings. This has a variety of benefits:

  • Increases the speed of login by eliminating complicated and lengthy login script processing

  • Leverages the hierarchy and organizational aspects of the NDS tree

  • Provides a consistent interface for the user to both applications and data

  • Provides a visual linkage between NDS and the file system for the user

  • Improves manageability by providing access to disk resources through NDS

Of course, you don't necessarily need to use the API to create Application objects in the tree, but if you want to tie disk space resource allocation to the automated creation and management of collaborative resources across the enterprise, then using the API to automate the process is imperative.

This example illustrates a construct used as a major building block for Clemson University's Collaborative Learning Environment (CLE), which won the Grand Prize in the 1999 Novell Developer Contest in the custom application category (see Figure 2).

Figure 2: Building block for the Collaborative Learning Environment (CLE) at Clemson University.

In this application, an NDS security structure and disk space are maintained for each of over 6000 class sections per semester. The NDS security structure is comprised of class roll and instructor groups whose memberships are automatically maintained through an NLM dynamically acting on transaction records received from the student database on the IBM OS/390 system. An Application Launcher object and automatically maintained associations provide the user interface into the disk space for each class section (see Figure 3).

Figure 3: Clemson Univer- sity uses NDS objects to control disk space usage for class sessions.

The larger idea here is to leverage the organizational structure built through automation with the intrinsic power of NDS-enabled applications, to create something greater than the sum of its parts. This is using NDS to build relationships between people and data. This is how you leverage NDS.

The Programmer Perspective

As stated previously, to achieve true NDS integration, your organization must have the tools and skills to develop code for it.

As an in-house developer, it is not only incumbent for you to make the most out of commercial tools--but supplement their actions with tools of your own that fit your business policies. This is the extra mile that allows your organization to get the most out of the directory.

As a commercial developer, it is incumbent for you to minimize the effort of the in-house developer as well as developing your code in such a way as to allow the in-house developer to enhance and build on the actions your code takes. If it is difficult for the in-house programmer to do this with your product, the customer may look elsewhere.

One of the key decisions you must make is where your code is going to run. It can run on the client or on the server, or both. It is fine to prototype the application and develop wrapper functions on the client since this is somewhat easier and the debugging environment is a little better.

In a production environment, it is generally more appropriate for automated management applications to run on the server. They need not be multithreaded in nature, but this is preferable in a transactional environment. There is a set of established methods that allow for safe multithreaded NDS access on the server that will be explored thoroughly in another article. You should be careful to adhere to these methodologies. If the application requires a user interface, it is usually more appropriate to have this portion of the solution on the client since not many administrators spend much time at their server consoles.

In developing NLM programs for the server, my tool of choice is Metrowerks CodeWarrior. Be sure to use a later version of the NDK from Novell in lieu of the version of the NDK that installs with CodeWarrior. The development environment on the client is a personal preference. Borland C++ Builder or Microsoft Visual C are both excellent development environments with good runtime debugging facilities.

You should understand the relationships between the objects in the tree so that you can be aware of what is already there to build on. This means that you should understand the basic class and attribute definitions that make up the schema. This is not nearly as hard as it seems and if you give it 30 minutes you'll be well on your way. There are several good tools for looking at the schema. My favorite is a tool called "NDS Snoop", or "Snoop" for short. If you want to see what's going on under the covers with objects in the tree, especially as you are writing code, I highly recommend Snoop. You can download it from http://developer.novell.com/nds/snoop.htm.

Once you get a feel of the relationships between the object types (classes) with the schema, explore a little deeper into the schema and understand the benefits and drawbacks of each of the attribute syntax definitions as well as the attribute flags. Understanding these and when they are used can help you understand the relationships between objects as well as give you some experience when it comes time to invent your own object class or extend an existing one.

Once you develop an understanding of the structure of NDS, you will be better at developing uses of NDS that help achieve integration with your business or customers.

If you are interested in getting started with NDS development, I recommend Novell's DeveloperNet University. This Web site has an excellent discussion and tutorial. I would suggest starting with client-based code and working toward single-threaded NLMs before moving into a multi-threaded NLM environment. You can access DeveloperNet University from the Novell Developer Web site at http://developer.novell.com.

Conclusion

Integration with NDS requires building an infrastructure with directory representation of all individuals in the enterprise as well as all organizational components in the enterprise. Automating the management of this infrastructure is the next step. There is a tremendous opportunity for development in this area.

As a commercial developer, we are ready to take the next step in leveraging the directory in an entirely new scope of applications. It's not just phone book anymore. Organizations are relying on the directory to make their business run. This new tier of applications will come from helping the customer use NDS to build their infrastructure instead of counting on NDS to be their infrastructure as has been the case in the past; this being done with an increase in user collaboration tools as a mindset.

As an administrator or in-house developer, developing a sound security and relationship structure based on the directory, and developing the correct tools to manage it can lead to some incredible leveraging power within your organization. Building the infrastructure and automating the management of it can lead to directory adoption by your entire organization, including factions that may be resistant to it, simply because of the automated aspects of it. Making use of data resources that you can count on is easy and effective.

Getting to this stage requires investment and commitment, but administrators will be rewarded with the huge returns that come from it. The result is an increase in the overall level of usability of the computing environment by administrators and users. By integrating the user's collaborative work with the directory in such an attributable way, users begin to see the inherent value in the directory to the organization. Once this is accomplished, critical mass will have been achieved as the network becomes a mission critical component of the organization itself.

Integrated with NDS does not mean simply using NDS. Integration means making your organization a part of NDS as well as having NDS as part of your organization; that is having NDS and its operation reflect how your organization does business. This benefits administrators, in-house developers, and commercial developers alike.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates