|
Directory Services True X.500, MS Exchange
and Novell NDS
Introduction
The Directory Service, a global repository holding information
about users and their environment, is now well established
technology. Many vendors are capable of delivering Directory Service
products and solutions, each of which may have different
characteristics depending on the vendors approach.
The LAN Operating System and E-Mail suppliers have developed
Directory and Name Server architectures quite naturally as a means
of holding centrally, the key information which establishes a users
rights and accessibility to the many office applications that
dominate our desktop.
The CCITT (ITU-T) have established the X.500 standard as a
yellow/white pages and name server system as a direct result of the
need for holding e-mail address and providing (originally) name
services for OSI(Open Systems Interconnection) applications.
It is significant that Microsoft and Novell have modelled their
own directory solutions on the X.500 standard, one might draw the
conclusion that as well as the undoubted suitability of the X.500
architecture, pressure from the market is also being brought to
bear. Large scale public sector projects in most regions of the
world continue to push the Open Systems standards and in particular
X.400 and X.500.
This document presents a summary of the main features of NDS and
Exchange, and makes comments regarding the positioning of a true
X.500 compliant product against these products.
Microsoft Exchange
When Microsoft first described their information management
product a couple of years ago, they stated that the product upon
general release would provide true X.500 Directory capability. This
would be provided from both the Client and the Server applications.
Microsoft Exchange Server was release in April 1996 with cut down
X.500 capability - in fact, the Client cannot access X.500 Directory
information without the inclusion of third-party interface software,
and the Exchange Server application has a directory service which
will only store objects conforming to X.500 schema objects. There is
no support for any of the true X.500 access protocols.
The Microsoft Exchange Client is shipped without any X.500
capability. If the client is to be used to access true X.500
Directories, then additional software in the form of a Service
Provider Interface(SPI) for X.500 needs to be added to the Client
software. This software converts the MAPI calls to X.500 (and vice
versa) to provide the access to the X.500 DSA. Accessing the
Microsoft Exchange address book is undertaken via MAPI.
Microsoft have indicated that future releases of the Exchange
Server application will be updated to provide true X.500 features,
such as Directory Access Protocol (DAP) and Directory Services
Protocol (DSP), but no firm indication of the release dates are
available. Currently, Microsoft uses the Exchange Server Directory
Replication Component to handle directory replication, and the
Exchange Directory Synchronisation process (DX) handles directory
synchronisation with other electronic mail systems, such as
Microsoft Mail. These are both proprietary access protocols.
It should be noted that Exchange is not just a Directory system
or an electronic mail system. Microsoft have taken a significant
number of technologies and are incorporating these into one product.
Exchange is an information dissemination and management system. It
uses X.400 as the messaging system and the implication is that X.500
will be used as the Directory system. It is therefore not designed
or intended to be a dedicated messaging or directory system.
Microsoft are not a dedicated X.400 or X.500 application developer
and have little experience of the incorporation of international
standards into their applications. There is therefore a very strong
argument in favour of applications from vendors who are dedicated to
particular standards. They have the knowledge and experience of the
standards. There is a strong argument for applications from
suppliers dedicated to the individual protocols to be used.
Microsoft's goal is to unify the Microsoft Exchange Server
directory with the name space of the operating system, file space,
Microsoft Exchange Server public folder hierarchy and security
database. Microsoft have given no indication when this upgrade will
be available.
Enterprise Directory Services
The Microsoft Exchange Server Directory is a central
"database" of user information. The Directory contains a
list of users and Microsoft Exchange Server system components, along
with various detailed information associated with each entry. One of
the main advantages of the Directory is that it is distributed. A
single large directory can be stored across multiple computers and
it is treated as a single entity within the system.
The Directory system has a number of features :
- Unlisted entries - certain addresses can be marked as
"hidden" from the address book. These are still
considered legal addresses which can be managed by
administrators, but they cannot be seen by users in the address
book list.
- Customised user information - client personal address books
allow for the storage of non-address information, such as name,
surname, title, company, address, city, postal code, country,
department, office, manager, up to eight different phone
numbers, notes and up to ten custom defined fields.
- Directory Query facilities - rich querying and navigation
capabilities are included. A user can query on any field within
the Directory, including custom defined fields. The distributed
nature of the Microsoft Exchange Server Directory provides users
with an organisation address list for the entire organisation,
but it can be viewed in smaller lists to help users navigate
large organisations.
- Distribution Lists - can contain any combination of Microsoft
Exchange Server addresses, custom foreign addresses, Microsoft
Exchange Server public folder addresses, other distribution
lists and personal address book entries. Microsoft Exchange
Server supports both global distribution lists and personal
distribution lists. Global distribution lists can be managed
from the Microsoft Exchange client interface by any user who has
been granted permission to do so by a Microsoft Exchange Server
administrator.
- Changes to distribution list members - global address lists
stored in the Microsoft Exchange Server Directory are
automatically updated when changes, deletions and additions are
made. Private distribution lists are not automatically updated,
but Microsoft Exchange Server will automatically re-route
messages to the updated address and notify the sender of the new
address.
Directory Replication
Directory replication is performed using the Microsoft Mail
version 3.2 directory synchronisation protocol. Microsoft Exchange
Servers can be grouped into one or more "sites" for
unified administration, security and communication services. A site
consists of one or more Microsoft Exchange Servers working together
to provide communication services to a set of users. From the
Microsoft Exchange Server administration program, the administrator
can manage everything that is associated with the site. Within a
site Microsoft Exchange Servers automatically discover each other
and route messages and synchronise directories automatically.
Conclusion
Microsoft Exchange Server has been delayed by two years. Press
reports have indicated that when Exchange was put forward for beta
testing, a number of significant problems were discovered. In
addition, the beta testers also indicated that additional features
and facilities should be included within the package. The reports
indicate that Exchange had to undergo major architectural changes at
a very late stage to ensure that these additional features could be
included. The extent to which this affects the X.500 development is
unknown, although, it could be fair to assume that Microsoft would
not send out a package with only a subset of a standard without a
valid reason. The early specifications for Exchange indicated that
true X.500 Directory services would be provided with both the client
and server products. We therefore need to question why Microsoft
have introduced Exchange with only limited X.500 support :
- Priority - the development of additional features and bug
fixes has taken priority
- Microsoft have found the development of international
standards more complex than they thought - they are not known
for their support of standards. Microsoft usually want to force
their own proprietary protocols onto the market.
- Lack of commitment to X.500 - they could be waiting to see how
the X.500 markets develops
It should also be noted that the various components that make up
the directory services architecture are a mixture of proprietary
protocols and applications from previous products. This gives an
indication that Microsoft have cobbled together a number of
components that provide a basic directory service.
NetWare Directory Services
NDS is a distributed database that can hold details about all
network resources, users, groups, printers and volumes. NDS replaces
the 'bindery' which is a 'per server' system database and has no
knowledge of the network. The following is a description of the NDS
(NetWare 4.1).
Novell NDS is an object-oriented, global information database. An
NDS database can handle millions of objects per server because it
follows the X.500 directory services standard and provides a
hierarchical name structure rather than a flat domain structure. A
flat database with this many entries is very difficult to administer
on a domain basis.
The NDS hierarchical organisation of objects allows the database
to be mapped as a tree, which in turn allows the database to be
partitioned into subtrees. Because object names contain the
hierarchy information, subtrees can be partitioned and
geographically distributed and still provide the ability for users
to globally access network resources. Any user can access any
resource from any location in the tree. The network administrator
can also administer the entire tree and its objects from a single
location.
NDS provides a global, distributed, replicated name scheme.
Unlike server-centric networks, NDS divides the directory into
logical subtrees called partitions. Although any part of the
directory can be considered a subtree, a partition forms a distinct
unit of data for storing and replicating directory information.
Partition boundaries cannot overlap; each entry in the directory
appears in only one partition.
Authenticating in a NetWare 4 environment consists of two
processes: user login and background authentication. With user
login, the client logs into an NDS environment to establish the
user's identity. No matter where the user is logging in, NDS follows
the tree until it finds a writable copy of the user object. NDS then
retrieves the client's private key. With background authentication,
a client still logged into the network can authenticate to other
permitted services and servers. This is a working example of what an
X.500 Directory might do in the future with security features such
as key and certificate management.
NDS does not support DAP, DISP or any other standards based X.500
access protocol. It is developed 'in sympathy' with X.500 and that
is about all.
The following list shows how NDS tracks X.500 functionality:
- NDS follows X.500 object and attribute definitions, allowing
extensible container and leaf objects.
- It provides every object within the name space a unique name.
- Has a DIB that contains information stored about objects
stored in the directory.
- Arranges objects in a tree similar to X.500.
NDS also supports other X.500 type features such as:
Comparison of NDS terminology with X.500
NDS X.500
- Property Attribute
- Container Object Parent Entry
- Leaf Object Leaf Entry
- Replicas Shadow Copies
Conclusion
Novell is still the market leader in PC LAN Operating Systems and
despite the market pressure from Exchange, continues to reign.
Novell attempted to make it in office systems when they bought
WordPerfect, experience has shown that they are better concentrating
on their core business and this is what they have chosen to do.
Given the huge installed base and tried and tested code, NetWare
is still the king of file and print, and there is no compelling
business case for migrating to Microsoft NT. For similar reasons
there is no sound reason for migrating Windows NT sites to NetWare
after all there is nothing inherently wrong with Microsoft's own NT
Server features. At the moment there are few arguments for
integrating a NetWare server into an existing NT network. The only
exception will be if Novell can beat Microsoft by incorporating NT
servers in NDS, making NetWare a viable management platform for an
NT network, for those unwilling to wait for Microsoft's serious
directory services product.
NDS is part of Novell NetWare 4.1 and linked into the one
application environment. It has extensive management tools for
controlling the information and performing more complex tasks such
as moving and modifying sub-trees contained in the DIT.
Whilst it is not an X.500 system, NDS is a very comprehensive and
technically well engineered directory system in common with Novell's
general product line.
Competitive Positioning
Now
Whilst the significance of X.500 is being felt throughout the
industry, more evidence of pilot and large scale deployment is
needed to galvanise its success. The 1993 edition of the standard
brings more practical features, multi platform availability and good
quality management tools for administration (although these are
usually tailored interpretations by each vendor).
The case for X.500 (or not) compared with similar solutions from
NDS and Exchange is still a debate about the suitability X.500
overall.
It is interesting to note that in the marketing information for
NDS and Exchange, both vendors compare and contrast functionality
with each other (competitively), but pay respect and due homage to
X.500 as the guiding light.
X.500 has the following main advantages over a proprietary
directory service:
- Openness - vendor independent through conformance with
international standards.
- Standard interfaces make integration easy e.g. e-mail address
book
- Flexible in structure - can be tailored to suit.
- Robust and reliable - industrial strength product.
- Can scale easily to thousands of entries distributed across an
enterprise.
Positioning of X.500 against NDS and Exchange requires prior
preparation in two areas:
- A straight feature comparison between products and technology.
- An architectural analysis concerning the place that X.500 may
take in an enterprise's system, and a resulting debate about
X..500 enterprise wide or, a combination of NDS/Exchange and
X.500 across the enterprise.
NDS and Exchange are combined with other systems and software,
they exist as part of the office system or LAN operating system.
They have special features which can be closely coupled to the
operation of the systems on which they work. They have access
control, authentication, hold user profiles - many of the feature
lists that we now ascribe to modern X.500 systems. Clearly a feature
comparison on this level is difficult. X.500 vendors are still some
way behind producing the rich functionality of the LAN systems, to
yield similar benefits
The strength of X.500 as a backbone and infrastructure solution
for directory should be emphasised. At present the ability of NDS
and Exchange to scale over large scale enterprises is not as good as
X.500. Novell class a medium size NDS system as one that supports
500 users, Microsoft Exchange Server - 400 users. Their
implementations of Directory are not X.500 solutions, they cannot
interconnect with each other or X.500, except through convoluted
import and export programs. They cannot easily support other mail
systems.
An enterprise directory system can combine proprietary and
X.500 systems. Potential customers should be sold on the benefits of
X.500 as an infrastructure product and used in conjunction with the
dominant mail/network system address book or directory
Where an organisation wants to have independent systems and
software within their enterprise, it is easier to justify X.500 as a
directory service. In this case the ability of a variety of
proprietary systems to interconnect means that the use of a 'no axe
to grind' X.500 system is possible. X.500 has the ability to
interconnect Microsoft Mail, cc:Mail, ALL-IN-1 and PROFS address
book systems; development of other address book synchronisation is
possible. Other vendor X.500 systems do this just as well e.g. CDC
MailHub.
X.500 is available for serious deployment now The battle for the
middleground departmental server technology by Microsoft and Novell
is all bound up with issues to do with relational databases,
client-server, Internet access services as well as messaging and
directory services.
In the Future
Novell
Novell on the face of it competes with NT although NDS and
Exchange are, or could be thought of as, a subset of the operating
system.
Novell's' DNS is a very comprehensive directory service that is a
direct reflection on their undoubted leadership in the area of
Network Operating Systems. As a product, it ranks better than
Microsoft's Exchange Server. It is also a powerful competitor for
X.500 in a Novell 'shop'. There are no know plans at this time for
Novell to provide full X.500 accessibility.
Microsoft
Microsoft have indicated a commitment to true X.500 Directory
services, although no firm release dates are given. The next major
release of Windows NT (codename Cairo) provides a complete re-write
of Windows NT in an object-oriented architecture. This indicates
that Back Office components, such as Exchange will also undergo some
form of conversion to object design and implementation. This would
probably be the stage at which the true X.500 capability is
introduced into Exchange. Cairo is currently due for release in
1997, but given Microsoft's past history, 1998 seems to be the
expected release date.
However, if market conditions indicate a strong uptake in X.500
requirements, Microsoft may be forced into a quick update of
Exchange to include X.500 services. Dedicated X.500 application
providers have spent many man-years developing their X.500 compliant
products. If Microsoft want to produce true X.500 capability within
Exchange, a question mark on the quality of application development
is raised.
As already stated, Microsoft Exchange Server is not just a
Directory server, and Microsoft obviously have priorities for the
inclusion of additional functionality within Exchange. We do not
know the level of importance Microsoft place on the provision of
true X.500 capability.
Microsoft has already incorporated an X.400 MTA within Exchange
Server, the Exchange directory - whilst not a proper X.500
implementation may be developed further to allow access to X.500
type interfaces, allowing the Exchange directory to participate in a
distributed X.500 system. This is a hypothetical view but given that
Microsoft's plans for Cairo (including an Object File
Store/Directory) seem some way off, it would not be surprising if
they 'took on' more of X.500 in the circumstances.
Press
here to go to workflow mainpage < |
WORKFLOW