Novell eDirectory vs. Microsoft Active Directory - …osman/462139… · · 2008-10-14COMPETITIVE...

w w w. n o v e l l . c o m

C O M P E T I T I V E W H I T E PA P E R

Novell® eDirectory™ vs.Microsoft* Active Directory*

Table of Contents

2

2

3

8

21

I N T R O D U C T I O N

T H E V I TA L R O L E O F A D I R E C TO RY

S E L E C T I N G A H I G H - E N DD I R E C TO RY S E RV I C E

C O M PA R I N G M I C R O S O F T A C T I V E D I R E C TO RY TO N O V E L L e D I R E C TO RY

S U M M A RY

Novell eDirectory vs.Microsoft Active Directory

Novell eDirectory vs. Microsoft Active Directory

2

IntroductionMillions of people unknowingly tap the power of a directory service every day. Directory

services are a foundational technology serving a number of critical functions, yet the

everyday user rarely sees them. Any Web site or application that personalizes its pres-

entation or controls access to its content is almost certainly taking advantage of a

directory. Directories provide the information technology power behind customer

services, citizenry records and white or yellow page indexes. And from small shops to

massive enterprises, people count on directories to allow access to their networks, files,

printers and other resources.

If you are evaluating which Lightweight Directory Access Protocol (LDAP) directory

will best address your business needs, selecting the right one is no trivial task. Given

the numerous offerings available, it can be difficult to determine which directory is best

suited to the unique needs of your organization. This paper will assist you in that evalu-

ation process by clearly outlining what a directory is, why it is necessary and how to

evaluate one that will best fit your organization’s needs—with particular focus on the

differences between Novell® eDirectory™ and Microsoft Active Directory*.

T H E V I TA L R O L E O F A D I R E C TO RY

Directories provide the identity infrastructure

for controlling access and authentication,

provisioning, personalized content presentation

and various other aspects of managing the

relationships between information resources and

the people who use them. As a central repository

of organizational information, a well-applied

directory becomes a business component of

crucial importance.

Today, directories are being applied to manage

identities on a scale never before seen. Internet

news sites use directories to identify readers,

profile them and personalize their content.

Financial institutions securely extend their

services to customers over the Web by using the

identification and authorization capabilities of

a directory. Outsourced management firms

manage their diverse clientele and the services

they need with directories. And directories

empower service providers to identify and track a

wide range of devices, from broadband modems

to fleets of automobiles. Governments provide

health care services and manage electronic tax

collection systems for entire citizenries—again,

all backed by the power of directories.

Directories address multiple challenges,

the least of which is merely identifying a user or

consumer. Layered on top of that is the ability

to authorize multiple levels of access to various

resources, provide a common username for accessing

multiple services and act as a foundation for

provisioning services to a user.

The diverse roles directories now play within

organizations have made them a very common

technology type. However, the uses described

above distinctly define the role of a high-end

directory service. And this high-end application

of directory technology requires organizations

to consider some very specific qualities in the

directory they select.

S E L E C T I N G A H I G H - E N D

D I R E C TO RY S E RV I C E

Now that we have discussed the diverse

applications of a directory service and discussed

how directories can become mission-critical

components of an agile organization, we come

to the question, which high-end directory can

best deliver these advantages?

The business criteria for selecting the right

directory service falls into one or more of the

following five categories:

• Scalability

How big is “big”? How scalable does our

system need to be, addressing the needs of

today as well as tomorrow? Can it still

perform when scaled into the millions of

identities and beyond?

• Compatibility

Does it work with our applications? Does it

support directory access standards? Does it

work on our preferred platforms?

• Reliability

What mechanisms ensure that service is

always available? Can it meet our availability

goals? Is it prone to service errors or data

corruption? Does it have well-thought-out

options for disaster recovery?

• Manageability

What tools and services provide proactive

management and monitoring of the system?

Does it plug into common network

management consoles? Do the management

tools adapt to organizational needs?

• Securability

Does the system allow you to provide access

to privileged users while rigorously denying

malicious intruders? Can you provide access

through a variety of means? Does it provide

a security model flexible enough for

company needs?

A true high-end directory service will excel

in each of these five areas. In other words,

determining how well a given directory fulfills these

five criteria should ultimately determine its ability

to address your needs and business requirements.

Most organizations will not put equal weight

on each of the above high-end directory services

criteria. It is very much a worthwhile exercise to

prioritize your organization’s business requirements

against these five points before diving into the


3

minute technical details. When selecting a directory

service, questions (such as those listed above)

may help to more exactly clarify your goals for

deploying a directory, as well as prioritize what

criteria matter most to the organization.

Let us now examine each of these criteria in

more detail.

Scalability

Customer-driven organizations know that their

number of managed identities may range from

hundreds of thousands to millions, or in some

cases, hundreds of millions. In addition, partners,

supply-chain companies and other stakeholders

who need personalized access continue to push

scalability requirements.

Scalability goes far beyond how many user or

device identities can be stored in the directory.

While shear volume is an important factor, so too

are functions that are less obvious. Some vendors

claim scalability as storing vast numbers of objects,

without the objects in their tests actually containing

any real data. Performance metrics for LDAP

responses per second, the efficiency of replication

and how modifications affect the size of the

datastore must also be considered. Finally, the

directory’s standard management tools must be

able to scale as the directory itself scales.

Compatibility

Because directories act as a hub for all things

identity-related, compatibility is a key factor in

selecting a high-end directory service. Compatibility

must be measured with regard to adherence to

standards and compatibility with your existing

environment. The top priority is almost always

whether a directory offering can work for the

immediate business needs to which it will be

applied. But also important to consider is its

ability to accommodate the next wave of uses

your business may need to integrate with the

selected directory.

Protocol Standards and Application Compatibility

Lightweight Directory Access Protocol, or LDAP,

forms the common denominator for accessing

directories. LDAP is not a directory itself—it is

nothing more than an access protocol used to

communicate with a directory. While there are

many, many other directory access protocols

available, LDAP dominates; and LDAP compatibility

is the essential starting point for any true high-

end directory service. Most directories claim

LDAP as their protocol common denominator,

but the implementation of the standard and its

de facto extensions remains an area of concern

for compatibility.

The hallmark of a directory’s compliance to

the LDAP standard is LDAP Certified status, as set

forth by The Open Group (http://www.opengroup.

org/dif/cert03). LDAP Certified status ensures

that a directory uses LDAP according to the

specification and helps to ensure that LDAP-

based applications will work with the LDAP

Certified directory. (Similarly, The Open Group

also maintains the LDAP Ready certification for

LDAP applications.) At a minimum, a high-end

directory service needs to support LDAP v3 and

earn LDAP Certified status.


4

Web services comprise an emerging set of

standards designed to allow applications to use

Web-based protocols to communicate. The primary

protocol used by Web services is Simple Object

Access Protocol (SOAP), which is based on

eXtensible Markup Language (XML). SOAP allows

dissimilar applications to interact regardless of

their underlying platform, programming language

or internal application calls. This description also

loosely defines Web services and its promise.

The openness that Web services provides

increases the need to manage identities and access

control. Directory Services Markup Language (DSML)

addresses this need by providing a mechanism to

encode directory requests within SOAP. DSML allows

Web services-enabled applications to leverage a

directory. This offers a number of benefits, including:

• Organizations can set up relationships with

partners, allowing mutual use of identities

through Internet technologies.

• Organizations with supply chains can manage

the identities of each supplier to provide

secure access over the Internet.

• Organizations can selectively expose parts

of their directory to be queried by external

entities, as might be the case for a publicly

published corporate or organizational

address book.

Although there are a number of other protocols

and standards for directories, LDAP sets the base

standard for directory access, and SOAP/DSML show

the most promise in providing integration with Web

services-enabled applications. Prioritizing which

directory access standards are most important

depends on the directory-enabled applications you

plan to deploy and the level of expertise in your

organization. For a broader discussion of directory

access protocols, see Burton Group’s recent

research report “Interfacing with Directory Services:

Sorting out Options for Directory Access” at

http://www.burtongroup.com.

Platform Compatibility

There are few truly homogeneous networks.

Whether by intent or accident, nearly all

information systems of any size have a mixture

of machines and operating systems for both

desktops and servers—including Linux*, Windows*,

UNIX* and NetWare®. This almost mandates that a

selected directory technology must be able to be

hosted from multiple platforms. Managers should

have the option of choosing an optimal platform

based on preferred hardware and operating

systems, reliability expectations, personnel skills

and overall manageability. Further, because your

business’ choice of host platform may change over

time, a multi-platform capability is fundamental

to the selection of a high-end directory.

Reliability

Reliability is an essential quality for a high-end

directory. The more critical the directory’s

availability, the more reliable it must be;

so naturally, a high-end directory must provide

continuous availability, no matter what. Much like

a financial database, when the directory is down,

the organization is down.


5

The directory’s ability to self-correct and

prevent minor errors forms a first line of reliability.

The capacity to transparently host writable copies

of the directory across multiple servers—and

possibly wide geographies, to provide central

backup and local data availability—forms another

level of reliability.

Beyond continuity of service, a directory

needs to provide multiple levels of fall back and

recovery—from real-time failover to online, near-

line and offsite backup capabilities. Quick recovery

in the event of catastrophe—whether due to

hardware failures, operating system failures or

natural disasters—is a vital, business-sustaining

requirement for a high-end directory service.

Manageability

With technology, the cost of acquisition is

almost always smaller than the ongoing costs of

management. In selecting a high-end directory,

a key question to ask is how much effort it will

take to maintain.

Directory management breaks down into two

major groups of activities: administration and

maintenance. Administration involves day-to-day

tasks such as setting up groups, assigning access

rights and clearing account lockouts. Maintenance

involves less frequent tasks such as performance-

tuning LDAP services, extending the directory

schema or configuring alerts to report to your

enterprise management console.

In general, manageability depends on the

breadth of tools available. With several of the

directory contenders today, a limited set of tools

not only results in overly complex management,

but also demonstrates the manufacturer’s

inexperience and the consequential immaturity

of the product.

Tools for both directory maintenance and

administration should be securely accessible from

a variety of platforms and devices in order to

ensure immediacy of response to management

tasks both large and small.

To reduce costs and appropriately distribute

management, many organizations require some

form of delegated administration capability.

Delegated administration allows the assignment

of specific administrative tasks—such as changing

passwords or assigning application access—

to the appropriate people based on their roles.

This capability ensures that help desk or customer

support call center personnel can perform

appropriate management tasks without having

excessive system access.

The capability to integrate with enterprise

monitoring tools, such as Tivoli Enterprise Console*,

HP OpenView* and CA Unicenter*, is also important.

These standards-based systems use Simple Network

Management Protocol (SNMP) and other protocols

for monitoring events and directory health in real

time. If you intend to put a directory to high-end

use, support for monitoring through the generic

SNMP and the more directory-specific LDAP event

notifications are essential features.

To be sure, directory management is becoming

increasingly automated through rules-based event

handling and ongoing innovation in the systems that

connect to directories. However, many ongoing


6

management tasks still require appropriate tools.

The larger the scale and business criticality of your

directory service, the more you will rely on its

management tools to prevent overwhelming your

limited IT resources.

Securability

The system on which your business hinges its

identity services must be securable to the level

required by your organization. There is no single

checkbox item to say that a directory is secure.

In fact, no directory can claim to actually be

secure, only securable.

With directories, securable encompasses a

myriad of possibilities, not limited to: the operating

system on which the directory will be hosted;

the granularity of the directory’s permissions and

enforcement model; how secure data, such as

passwords, is encrypted and stored; whether strong

authentication methods (such as biometrics and

smart cards) can be used instead of passwords;

and much more. The nature of security requires

that some of these capabilities must be built into

the directory, rather than added piecemeal.

Security includes far more than mere

authentication (the logging on of users).

The directory must proactively enforce access

control in real time and ensure that the methods

used to gain access to data are suited to the task.

As an example, graded authentication might

be configured to allow access only when a user

has the correct rights or privileges and the user

has authenticated with multiple credentials

(password plus a biometric, for example). Such an

implementation may be desirable for accessing

highly confidential data. Most directories can

create an identity for use as a simple login, yet

few can use that identity as a comprehensive

security principal that can be leveraged across

multiple services and systems.

A final consideration is whether the directory

in question is supported by sufficient auditing

offerings to allow the directory to truly function

as the identity hub of your system security.

Business Value Comes First

Though not exhaustive, these five criteria—

scalability, compatibility, reliability, manageability

and securability—form the requirements foundation

for evaluating directory services for your organi-

zation’s high-end purposes. Understanding your

requirements and priorities in these key areas

ensures that your investment in a directory will

fit your needs for both today and tomorrow,

and keep cost aligned with benefits.

Directories that do not fulfill your organization’s

requirements in light of these five fundamental

values may not be suited for high-end needs,

but may still have an important place in your

enterprise. Application-specific directories will

often need to be deployed because they are

inseparable from a business-critical application.

(For example, Microsoft Exchange requires Active

Directory for the purpose of supporting e-mail.)

The presence of such a directory does not

negate the need for a high-end directory service,

nor dictate which directory should be used for

high-end purposes. Ultimately, the directory you

choose must be capable of unifying your various


7

application-specific directories under a single

management umbrella to create a manageable

identity system.

C O M PA R I N G M I C R O S O F T A C T I V E

D I R E C TO RY TO N O V E L L e D I R E C TO RY

Out of the several directory service providers, two

market leaders are Novell eDirectory and Microsoft

Active Directory. The balance of this document

will compare the two and evaluate how each

fulfills the requirements of a high-end directory.

The Offerings

Active Directory is currently in its second version.

Fundamentally, Active Directory is a network

operating system directory, having been created

in support of the Windows server operating system.

In Windows 2003, many of the enhancements

make up for deficiencies inherent in Active

Directory’s original release, showing the relative

inexperience Microsoft brings to its fledgling

directory offering.

Novell has been working in directory services

for 10 years—longer than any other major player

in the industry. Novell eDirectory was built from

previous experience producing Novell Directory

Services® (NDS®). NDS was a network operating

system directory built for NetWare that formed

an important prerequisite to the introduction of

Novell eDirectory. Today, Novell eDirectory leads

the industry as a truly platform-independent,

high-end directory.

Let us now compare the two offerings using

the five business criteria for selecting a high-end

directory service.

Scalability

Scalability has always been questionable in

Active Directory. Though Microsoft claims there

are Active Directory deployments that scale from

10 to 15 million objects, in practice few businesses

operate with that many, or have even attempted to

do so. At such a scale, Active Directory performance

becomes a liability due to data bloat, scaling

limitations of the Active Directory management

tools and the network traffic storms caused

by inefficient replication, thereby defeating

the investment.

In 1999, Novell demonstrated eDirectory

scalability to 1 billion identities. While possibly

seeming outlandish, Novell pushed eDirectory

to handle this size in order to pave the path to

super-massive directory deployments. Novell has

also run extensive LDAP performance tests

on 100 million-object systems to assure that

performance is sustained with very high volumes

of identities.

Multi-master replication in eDirectory allows

LDAP performance to scale linearly simply by

adding more LDAP server interfaces as needed—

even dynamically as conditions require.

Here are some examples of businesses and

governments who base their high-end directory

deployments on Novell eDirectory:

• Direction Générale des Impôts, the French

Tax Authority, uses Novell eDirectory as the

identity repository for taxpayers. Today the

directory hosts several hundred thousand

identities and will grow to accommodate

35 million (encompassing virtually all French

taxpayers) when the project is complete.

• Novell eDirectory is the

foundation for many of

the world’s largest identity

management deployments

• Novell is the directory

services pioneer with more

than 10 years of business

and technical experience

• Novell eDirectory is

deployed by more than

30,000 companies

worldwide

• Over 2 billion

eDirectory licenses

have been distributed

• eDirectory is redistributed

by more than 60 ISVs,

including SAP, TIBCO and

many others

• More than 2,000 products

have been developed for

use with eDirectory

• Novell eDirectory is

proven scalable,

compatible, reliable,

manageable and securable


8

Figure 1

• TransUnion, one of the world’s largest credit-

reporting agencies, has deployed eDirectory

to personalize the Web experience for 10 to

12 million customers annually.

• PC maker Gateway has deployed eDirectory

to manage employee, partner and customer

identities in excess of 5 million users.

Scalability and System Requirements

A major factor behind why Novell eDirectory

scalability far outpaces Active Directory’s is

simply the efficient use of hardware resources.

For example, consider the hard disk space used

by eDirectory and Active Directory, respectively.

The table in Figure 1 and the graph in Figure 2

illustrate that on average Active Directory

consumes twice as much disk space as eDirectory

when hosting the same number of objects. In a

high-end deployment, where millions of identities

and their related objects are stored in a directory,

this gap could be a substantial obstacle. In addition,

Active Directory’s excessive consumption of disk

space becomes even more problematic as access

controls are applied, as discussed later in the

“Securability” section.


9

DATABASE S IZE ( IN MEGABYTES)

OBJECTS ( IN THOUSANDS) NOVELL eDIRECTORY 8.7.3 MICROSOFT ACTIVE DIRECTORY 2003

0 28.57 59.04

10 52.81 100.04

100 159.24 348.04

200 312.13 598.04

300 449.00 872.04

400 543.81 1128.04

500 690.58 1382.04

600 827.16 1660.04

700 939.83 1918.04

800 1084.66 2136.04

900 1213.56 2386.04

1,000 1334.15 2635.04

To achieve anything approaching the scalability

of eDirectory requires significantly more hardware

for Active Directory, without achieving comparable

performance.

Compatibility

Protocol Standards and Application

Compatibility

Previously, we discussed that LDAP is the common

denominator for directory access. To date, The Open

Group lists 22 products as LDAP Certified, including

several entries for Novell eDirectory on various

operating systems. Currently The Open Group lists

no aspect of Active Directory as LDAP Certified.

Without this certification, businesses have no

assurance that non-Microsoft applications and other

directories will interoperate well with Active

Directory. In fact, very little is known on the

state of Active Directory and certification under

the LDAP Certified guidelines. Microsoft has had a

rocky past with LDAP compliance, resulting in many

products that cannot work with Active Directory

using LDAP. Perhaps the best evidence of the gap

between Active Directory and the LDAP standard

is Microsoft’s publication of a document defending

their LDAP support (http://www.microsoft.com/

windowsserver2003/techinfo/overview/ldapcomp.

mspx). And, consistent with their usual vendor

lock-in strategy, Microsoft almost invariably steers

developers to use proprietary Active Directory APIs

(ADSI) rather than LDAP.

In addition to LDAP, Web applications use DSML

to communicate with directories. Both Novell and

Microsoft support DSML.

Figure 2


10

Figure 3

Support for additional directory access methods is often not as important as support for LDAP. However,

depending on your current and potential applications, as well as your in-house developer expertise, you

may need to consider various other protocols. The table below offers some summary comparisons:


11

NOVELL eDIRECTORY MICROSOFT ACTIVE DIRECTORY

ODBC Novell eDirectory supports ODBC There is no ODBC driver for Active

(Open Database Connectivity) through a client-side driver to allow Directory. However, an LDAP/ODBC Driver

directory access for standard reporting exists. Active Directory’s partial LDAP

tools (such as Crystal Reports) or support may limit this approach.

database queries.

JDBC* A JDBC Driver allows Java programs Active Directory has no JDBC driver.

(Java* Database Connectivity) (applets, servlets, applications or (However, the Novell LDAP JDBC driver

J2EE* application servers) to access can be used to query AD through LDAP.)

eDirectory data.

JNDI* The Novell JNDI Provider enables The only way to access Active Directory

(Java Naming and Directory access to eDirectory through JNDI. with this protocol is through a JNDI Provider

Integration) (such as the one from Novell), which uses

Active Directory’s limited LDAP support.

JavaBeans* and Enterprise Several JavaBeans and EJBs allow the No support other than through LDAP.

JavaBeans (EJBs) use of eDirectory services in Java

applications and J2EE application

servers (such as IBM WebSphere* and

BEA WebLogic*).

ActiveX* Controls Novell provides ActiveX controls to Microsoft has a very rich set of controls

access eDirectory via ASP pages, for use in Visual Basic, RAD tools and

Visual Basic* and Visual Studio embedded HTML.

applications.

ADSI Novell has a client-side ADSI provider Microsoft pushes their proprietary ADSI

(Active Directory Services for eDirectory. for access to Active Directory over

Interface) standards such as LDAP.

Platform Compatibility

Active Directory supports only the Windows

server platform, starting with Windows 2000.

In addition, many enhancements to Active

Directory in Windows 2003 are not backward

compatible to Windows 2000/Active Directory.

This compromises the value of key features such

as the ability to rename and reorganize the

directory. Further, this tight coupling with the

Windows server operating system indicates that

new features in each version of Active Directory

will come with the high cost of operating system—

and possibly hardware—upgrades.

Microsoft recently introduced a version of

Active Directory that is somewhat less operating

system dependent, called Active Directory

Application Mode, or AD/AM. AD/AM is useful for

testing and deploying identity-enabled applications

and can help alleviate some of the inflexibility

inherent in an enterprise Active Directory

implementation. Once deployed, AD/AM can be

used to pass authentication credentials to an

existing Active Directory deployment; however,

richer integration requires the use of Microsoft’s

meta-directory product (and an additional fee

for both product and consulting time).

While AD/AM seems to address the necessary

decoupling from the Windows operating system,

it still does not constitute an effective replacement

for a high-end directory service. Rather, AD/AM

helps to remove some of the pain of deploying

Active Directory for application-specific needs;

and it simplifies the development or deployment

of applications that rely on Active Directory.

Also, even though AD/AM has been decoupled

from Windows, it can still only be deployed on

Windows 2003 or XP Professional.

A key strength of eDirectory is compatibility

with various platforms. This capability allows an

organization to select the best platform to meet

security and reliability requirements, and to take

advantage of the organization’s platform expertise.

Novell eDirectory can be hosted from Linux,

Windows, HP-UX*, IBM AIX*, Solaris* and NetWare.

Novell eDirectory distinctly avoids entanglement

with any specific network operating system.

While eDirectory can in fact aid in the management

of network operating systems such as Linux,

Windows and NetWare, much of the flexibility,

scalability and manageability of eDirectory result

from its independence of any specific platform.

Reliability

Because they play such a critical role in so many

businesses, directories are required to provide

“dial-tone” reliability.

The version of Active Directory which shipped

with Windows 2003 introduced tools that have

eased some past manageability problems. However,

scalability, reliability and security concerns still

plague even the most recent release of Active

Directory. To be sure, Microsoft Windows is seldom

equated with reliability. And with no option to

select a more robust platform such as Linux or any

of the high-end UNIX platforms—coupled with the

fact that Active Directory cannot be clustered—

Active Directory reliability suffers from the

reliability of Windows itself.

In contrast, because Novell pioneered the

directory services market, it has the industry’s

most extensive experience at providing high-end

directory services. Novell eDirectory meets the

reliability challenge with top-to-bottom

guarantors of reliability.

To examine how each offering stacks up,

let’s compare the two directory platforms using

four criteria: self-maintenance, service continuity,

maintenance tools and disaster recovery.

Automated Self-Maintenance

Day-to-day directory operations should be largely

self-policing to prevent service interruptions.

Automated self-maintenance simply means that

the directory has been designed to groom itself in

order to prevent data corruption and other problems

that are routine within very large, active datasets.

Novell eDirectory catches and corrects typical

minor errors with no administrator intervention,

thereby reducing the frequency of reliance on more

powerful maintenance tools.

As an example, consider the directory schema,

which defines the possible objects and attributes

that can be stored in the directory. Both Novell

eDirectory and Microsoft Active Directory allow


12

administrators to extend their respective directory

schemas to accommodate new object types and

attributes. However, only eDirectory allows schema

extensions to be removed. When an obsolete or

erroneous extension is removed from the eDirectory

schema, the associated data on existing objects

is then automatically removed as well.

In contrast, Active Directory does not allow the

removal of schema extensions. In fact, when an

administrator tries to extend the Active Directory

schema, before he can proceed, he receives

this warning: “WARNING: Creating schema

objects in the directory is a permanent operation.

While these objects may be disabled to prevent

their usage, they cannot be deleted and will

become a permanent part of your enterprise

installation.” This limitation is a prime example

of the immature state of Active Directory.

If someone without proper permissions bypasses

change control procedures (perhaps in the process

of deploying a departmental application) and

extends the Active Directory schema, those new

object classes or attributes are now a permanent

addition to the directory infrastructure. Even when

the deletion of schema objects makes sense to

reduce administrative clutter—such as when a

line of business application that required schema

extensions is no longer in use—Active Directory

cannot accommodate the change.

Continuous Service

In directory services, multi-master replication forms

the foundation for horizontal scalability and service

continuity. Coupled with layer four switching

technology or an LDAP proxy, multi-master

replication provides reliability that is limited

only by the underlying directory’s architecture.

In 1994, Novell introduced unlimited multi-

master directory replication. Today, Novell eDirectory

continues to lead the industry in this capability—

a difficult-to-engineer yet absolutely critical

feature that ensures continuous availability and

forms one of the compelling advantages that

eDirectory has over any other directory service.

While Active Directory has multi-master

replication, there are implementation weaknesses

to be aware of. An Active Directory implementation

relies on designated “operations master” servers.

Operations masters police one of five key functions

within the Active Directory system: the schema

master manages the schema; the domain naming

master enforces domain interaction rules; the RID

master ensures uniqueness of object identifiers;

the infrastructure master maintains interdomain

references between objects; and the PDC emulator

processes password changes and synchronizes time

among domain controllers. Microsoft introduced

the operations master roles as one of the elements

to help bring the Windows domain system into a

directory model.

Of these operations master servers, the PDC

emulator is one of the most vital, because time

synchronization is essential for many directory

processes to work. The PDC emulator operations

master role can be assigned to only one domain

controller in each domain. This single point for

critical operations presents a significant weakness

in Active Directory’s reliable.


13

While it is true that a standby operations

master server can be brought online in the event of

an outage, bringing that standby server online is a

manual process. What's more, Active Directory

offers little warning in the event of an operations

master server failure. Microsoft’s own product

documentation states: “Generally, you will notice

that a single master operations role holder is

unavailable when you try to perform some function

controlled by the particular operations master.”1

Clearly this approach is not sufficient for a high-

end directory deployment.

Novell eDirectory was designed from the

ground up for multi-master replication and does

not suffer the Active Directory architectural issues

inherited from retrofitting Windows NT* domains

as a directory.

Live Maintenance Tools

With critical services like directories, businesses

require the ability to immediately bring the system

back to full service when problems occur. Ideally,

a manager should be able to diagnose and manage

directory problems remotely, without the need to

bring down the hosting server—and certainly not

the entire directory.

Novell eDirectory addresses this issue with

maintenance tools that can do much of their

work on a live directory server. These tools give

a manager the ability to remotely repair errors

within the directory, and are optimized to take the

directory service offline only during those parts

of the repair that require exclusive data access.

The family of eDirectory live maintenance

tools includes:

• DSRepair provides real-time maintenance

of the directory database. DSRepair can be

run against replicas on one server or against

multiple servers for tree-wide maintenance.

The amount of data to repair can also be

scaled from the whole directory down to a

single partition, and even a single object.

DSRepair runs natively on all supported

platforms and is also remotely hosted

through the eDirectory administration

interface in Novell iManager.

• iMonitor helps to diagnose and troubleshoot

core directory functions, such as replication,

through the individual directory server.

This Web-based tool requires only a browser,

so management can be accomplished from

any platform.

The live maintenance tools in Novell eDirectory,

coupled with its self-maintenance processes,

ensure a level of reliability unmatched by any

other directory vendor.

Active Directory repairs frequently entail

dispatching technicians directly to the host

Windows server, and then taking the server

offline. Many Active Directory repair processes are

only available by rebooting the server in “Directory

Services Restore Mode.” Whether local or remote,

the process of taking directory servers offline for

repairs, then restarting those servers, can create

much lengthier service disruptions. This may be

regarded as an unacceptable option for a piece of

infrastructure technology as vital as a directory.

To expedite the repair process (and save network

managers undue travel), Microsoft recommends

__________

1 See http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/sag_ADrespondFSMOfailures.asp


14

purchasing specialized hardware that enables

remote management of offline Windows 200x

servers (sometimes called “headless” operation).

Certainly it is the unreliability of Window servers

that drives Microsoft to make this recommendation,

but it also furthers the uncertainty around Active

Directory’s ability to play a high-end role.

Disaster Recovery

Recovering a directory should be an absolute last

resort, but must be an extremely reliable process

for a high-end directory service.

Both Novell eDirectory and Microsoft Active

Directory provide traditional backup and restore

capabilities to various media types, allowing you to

choose a backup plan that suits your organization.

However, your high-end directory may require

recovery that does better than simply setting

you back to the data you had the night before,

or whenever your last backup was conducted.

Novell eDirectory offers an essential additional

backup capability. Hot Continuous Backup not

only creates a complete backup of your directory

dataset, but it also functions as a live journaling

service, continuously recording all directory

data changes from the time you declare a new

backup period should begin. This approach

ensures you have an up-to-the-last-second backup

of your directory data. Should an immediate

recovery be necessary, an administrator can

restore everything to the last logged transaction.

Complementing its already extensive reliability

arsenal, only Novell eDirectory provides this

maximum level of recoverability.

Manageability

Regardless of the scale of deployment, the

management tools for eDirectory excel in both

administration and maintenance, providing several

mechanisms for proactive and reactive management.

Creating and maintaining an Active Directory

service is a time- and human resource-intensive

operation. As an Active Directory deployment

grows larger, trees become “forests,” and the

issue of managing trusts—the old Achilles’ heel

of Windows NT domains—becomes more and

more troublesome. Microsoft has automated the

manual creation of trusts, making Active Directory

domains function together more seamlessly,

but these trusts still assume specific relationship

rules that must be understood in addition to your

implementation of rights for directory security.

Additionally, the utilities for managing Active

Directory reflect a lack of sensitivity to large-scale

management needs and a clear slant toward having

a homogeneous network.

Adapting to Change

Directories change. Organizations or departments

sometimes change names; customer bases may need

to merge; subsidiaries are spun out. For large-scale

business identity systems, directory flexibility is

the key to allowing a high-end directory service

to adapt to change.

Active Directory relies on a fairly static,

inflexible naming scheme—a legacy combination

of NetBIOS and Windows Domain Name System

moved to a DNS paradigm—that precludes any

organizational change without serious forethought.


15

Within an Active Directory forest (the name of a

deployed directory system conforming to common

schema and naming rules) there are domains and

servers. These derive their naming based on a DNS

naming structure, which is established when the

first servers are installed and the directory is

first provisioned.

If your naming convention remains static

forever, all is well. However, should a time come

that you must make structural changes to the

directory, Active Directory domain boundaries and

naming constraints can present significant barriers.

Microsoft’s support material strongly discourages

such procedures.2

Why does Microsoft discourage domain

operations? Consider: Just one hierarchy change

means manually contacting every domain controller

in the tree, rebooting those servers plus two reboots

of non-domain servers connected to the domain.

An incomplete operation can result in domain

controllers and servers unable to communicate

with the rest of the network, leaving those parts

of the system compromised and unavailable.

Furthermore, this operation is only available

in an all-Windows 2003 network. Active Directory

deployments involving Windows 2000 domain

controllers do not have this option. Additionally,

with Microsoft Exchange 2000 involved, changing

domain hierarchy is not possible. Therefore,

once you have deployed Active Directory, you must

be sure to make all changes before an Exchange

implementation. Once completed, there is

no supported way to change the hierarchy in

either Windows 2000 or Windows 2003 Active

Directory deployments.

In contrast, since its inception, eDirectory has

been extremely flexible. Novell eDirectory allows

the flexibility to change partition boundaries

as design needs change. Further, the ability of

eDirectory to house multiple partitions on a single

server provides several advantages, including

the ability to easily decommission servers and

consolidate directory data. Other options taken

for granted by eDirectory managers include:

• Renaming any organizational level of the

directory

• Moving entire sub-branches of a directory

• Merging two trees

• Using identity criteria to automatically

provision access (dynamic groups).‡

‡ This LDAP feature automatically grants group membership

to an identity based on attribute values, such as when a value

indicates that a user is a manager or is in the sales department.

Simplicity of Design

Novell eDirectory can be designed for optimal

performance for almost any business scenario.

The data in an eDirectory system can be custom

segmented into partitions and then replicated as

needed, which allows tuning for performance and

reliability. Should your business needs change,

partitioning and replication scenarios can be

rearranged accordingly.

Much of the deployment planning for Active

Directory revolves around placement of domains

and the Global Catalog.

The smallest unit of replication in Active

Directory is a domain. In order to host directory

data, a Windows server must be a domain

controller. A domain controller can only host a

__________

2 See Domain-Rename-Intro.doc

hosted on Microsoft.com


16

single domain. Domains cannot be sub-segmented

or consolidated easily. This results in a rigid

directory system requiring much more up-front

planning to future-proof the deployment.

Many of the Active Directory fixes introduced

with Windows 2003 address design flaws with

domains and the Global Catalog due to customer

complaints. The Global Catalog functions much like

a directory on top of a directory—it collects and

stores a subset of the directory information from

the entire directory system (forest). While Microsoft

no longer requires a Global Catalog server at each

site, inter-domain access still requires the Global

Catalog’s availability, thereby introducing a failure

point to design around.

Directory Management Tools

Various tools exist for managing and maintaining

Novell eDirectory. Each platform offers utilities

that are consistent with the look and feel of that

host operating system (such as Windows, Linux and

UNIX). However, the primary tool for eDirectory

administration is Novell iManager, providing secure,

browser-based directory management.

Novell iManager provides various management

views, depending on what aspect of the directory

is being managed. For example, for help desk or

customer support personnel, iManager can present

a task-oriented view and show only the tasks

assigned to the logged-on user. For more global

administrators, iManager can present a navigable

view of the directory tree, allowing fast access

to general management of one or multiple

directory objects.

To complement iManager, Novell also provides

iMonitor, a browser-based maintenance tool for

performing diagnostics on your eDirectory servers.

The Microsoft Management Console (MMC)

provides a shell application for the management

of many Windows features, including Active

Directory. Microsoft supplies numerous Active

Directory tools and plug-ins for MMC, but these

tools are fairly disjointed and most are aimed

at per-server administration. For example,

repairing the directory requires rebooting the

potentially damaged server and running the Active

Directory repair tool. Rather than take a holistic

approach to repair, the tools force you to perform

the repair one server at a time. Management

through a directory-wide view (versus per server)

requires additional tools from Microsoft or third

parties. The condition of Microsoft’s directory

management tools presents yet another example

of how Active Directory was produced for

managing Windows, rather than as a high-end

directory service.

Delegated Administration

Any management task available in Novell iManager

can be delegated out, including custom-made

management tasks.

Active Directory offers an integrated wizard

to delegate administrative tasks, but that tool

can only be used for a few, limited administrative

functions. For example, you can delegate password

management to help desk personnel, but delegating

the ability to change other user data (such as a

phone number) requires much deeper knowledge

of the rights and permissions involved, which is a


17

generally a more time-consuming process reserved

for skilled administrators.

Support for Common Network Management Tools

Both Microsoft Active Directory and Novell

eDirectory allow maintenance via traditional

SNMP (Simple Network Management Protocol),

allowing established SNMP enterprise tools to

manage and monitor a directory deployment.

Active Directory also has been instrumented

for Microsoft Operations Manager, providing

integration with Microsoft’s Windows-specific

management systems.

Securability

An exhaustive security comparison between Novell

eDirectory and Microsoft Active Directory is well

beyond the scope of this paper. For our purposes,

we will consider three aspects to evaluate the

securability of each. The first is simply the

platforms on which the directory service can be

hosted. The second is its access control model

and other security parameters, including how the

directory takes advantage of security protocols.

Finally, we will consider the variety and strength

of the authentication mechanisms each directory

can support.

Hosting from a Securable Platform

Much can be said of the poor track record Windows

has earned with respect to security. Basing a

high-end directory deployment on Windows is

a risky endeavor, because a directory relies on

the operating system as its first line of defense

against attackers. Since Active Directory runs

only on Windows, the Windows platform largely

determines Active Directory’s securability.

Compromised security on a Windows server may

mean exposure of very confidential data.

Novell eDirectory allows flexibility as to where

the directory can run based on expertise in an

organization and the inherent securability each

platform provides. With eDirectory, you can choose

any platform that meets the security needs of the

organization—Linux, UNIX, NetWare or Windows.

Access Control Model

Access control, or authorization, deals with who

can do what action to which other objects. This is

usually determined by what rights (or privileges)

a security principal has to the resource being

accessed. A security principal is any entity to

which rights can be granted. A security principal

is most commonly a user or a group of users, but it

can also be other object types, such as printers,

services or applications. Rights are the rules

stating what can or cannot be done to a resource

represented in the directory. How security

principals and rights are administered and

enforced comprises the access control model

(or authorization model).

Novell designed eDirectory to have a

highly flexible internal access control model.

Three notable components of the model are,

first, that any object can access other objects as

a security principal; second, that access to every

object is secured by an access control list (ACL);

and third, that the directory hierarchy forms


18

the basis for dynamic rights inheritance. These

components allow eDirectory to easily manage

complex security relationships between objects.

When an identity in eDirectory attempts to

access another resource in the directory, that

identity’s access rights are dynamically calculated

and enforced. Appropriate access is derived from

rights assigned directly to the identity for the

resource being accessed; from rights assigned to

the identity’s security equivalences (which include

groups and other assignments); and from rights

assigned to a container in which the resource

resides (rights inheritance).

Rights inheritance is a powerful capability

for a directory to provide. It both simplifies the

assignment of rights and prevents from bloating

the directory with redundant data written to

multiple objects’ access control lists. Among the

many patents for innovations established in the

eDirectory access control model, rights inheritance

is recognized as one of the major capabilities that

makes Novell eDirectory unique.

The security model for Active Directory is

derived from that of the Windows file system.

Every object in Active Directory has an access

control list, providing a solid basis for securing

directory resources.

However, Microsoft has emulated Novell’s

rights inheritance through the Active Directory

management tools. When assigning rights at the

container level, the management tool walks the

sub-tree and writes the access control list change

on every single subordinate object, potentially

effecting hundreds, thousands or tens of millions

of access control entries. What should be a simple

rights change ends up multiplying the directory

data, directly impacting disk storage and memory

requirements. It also can generate a flood of

replication traffic between servers. Aside from

resource issues, what happens to security if a

process is interrupted mid-way through writing

such a change to ten thousand objects? And when

an object is deleted, how intensive a process is it

to clean up rights when rights-related references

are so pervasive throughout the directory?

The Active Directory security model is also

limited to only three security principals: users,

groups and computers. Other objects types cannot

be granted rights to Active Directory resources.

In eDirectory, containers are often granted rights

to a resource, which allows all the identities

within the container to have the same access

rights. Because containers are not one of the

Active Directory security principals, this cannot

be done in Active Directory.

The security principal limitation also reduces

the uses to which Active Directory can be applied.

While adding new object classes is possible,

you cannot make the new objects act as security

principals—that is, securely authenticate and

access other resources. Therefore, secure uses

of Active Directory are limited to those that

do not rely on strong trust models in which

applications and devices securely authenticate

to the directory, as would be required for digital

rights management and trusted computing,

for example. This detail illustrates very well

how Active Directory was designed solely to

solve Windows management issues.


19

One final consideration in examining the Active

Directory security model is the hardware needed to

meet even the most basic security requirements.

In a comparative test on a container of 1 million

users, a rights assignment to the parent container

produces staggering results that show how poorly

Active Directory’s security model scales. By granting

a single user or group full access control at the

parent container, the Active Directory data set

swelled by more than 557 megabytes, stamping

each object with roughly 558 bytes per user. In the

test case, this singular rights grant amounted to a

20 percent growth in the Active Directory dataset.

It should also be noted that because the rights

assignment involved a write action to each of

the million objects, the assignment was far from

instantaneous. Though it was difficult to see when

all the modifications were complete (we had to

check by querying effective rights on objects in

the dib), it appeared to be complete after around

10 minutes.

Novell eDirectory uses dynamic inheritance

to apply such a rights modification, and thereby

can limit the write action to a single object.

Active Directory must stamp each object within

the affected container and all its sub-containers.

Even the simplest of security scenarios will

involve more complex rights assignments than

the aforementioned test case, and as such will

drive significant hardware requirements for

Active Directory.

This brings to bear many questions about

using Active Directory for a high-end deployment.

Will your directory require a sophisticated access

control implementation? If not, are you certain

that your security model will remain simplistic

as your business use of the directory matures?

Have you correctly budgeted hardware to scale to

your security needs? Will you be able to withstand

the latency associated with every large-scale

rights assignment, especially those that involve

revoking assignments that have become outdated

when you need to re-design your access control

implementation? Finally, can your network

withstand the replication storms that such

changes would necessarily create?

Authentication

In addition to a directory’s internal security

model and platform options, the authentication

mechanisms a high-end directory supports helps

determine its securability. Authentication is the

process of validating that a security principal is

indeed who or what it claims to be.

For most people, the most familiar type of

authentication is a network or Web site login;

and generally, passwords form the least common

denominator for authentication. Strong authenti-

cation is comprised of non-password methods,

such as biometrics (fingerprint, retina scan and

voice recognition), token cards and proximity

devices, to name a few, as well as whether

authentication requires multiple factors—

perhaps a biometric plus a proximity card. Finally,

graded authentication can be implemented to

ensure that certain tasks require more credentials

than others—for instance, changing a password

might require a user to provide a PIN, biometric

or other additional credential.


20

Both Active Directory and eDirectory support

a range of authentication options, such as

simple passwords (including SHA-1 and MD-5

password hashing), PKI, biometrics, smart cards,

tokens, etc. Novell eDirectory, however, offers a

distinct advantage in the flexibility of its

authentication framework.

The eDirectory component that facilitates strong

authentication is Novell Modular Authentication

Service (NMAS™). Besides supporting virtually any

existing credential type as well as being able to

be quickly adapted to new authentication methods,

NMAS supports graded authentication. NMAS allows

a user’s access rights to be dependent on the

method of authentication or the combination of

several methods. For example, an accounting

employee who uses a simple password to log on to

the corporate network may only be granted access

to general departmental financial information;

whereas, logging in with a biometric or a digital

certificate or both would grant that same employee

access to more detailed financial data about

specific projects or individuals. This capability

gives businesses the choice of securing applications,

network resources and sensitive corporate data

with the method or combination of authentication

that best suits organizational policies and objectives.

While Microsoft Active Directory offers a breadth

of authentication options, it does not offer graded

authentication based on multiple factors.

To summarize our short examination of the

securability of both Active Directory and eDirectory,

we find once again that Active Directory reveals

Microsoft’s inability to adequately address the

full requirements of high-end directory services.

On the other hand, Novell eDirectory gives

businesses flexibility in host platform options,

its internal authorization model and its authenti-

cation capabilities. Once again, eDirectory can be

adapted to the needs of your business, rather than

forcing the opposite.

S U M M A RY

The role of directories in information technology

has grown to become a fundamental piece of

infrastructure and the foundation for an

organization’s ability to manage the identities

that make business work. A high-end directory

provides the authoritative source for all identity-

driven services; and scalability, compatibility,

reliability, manageability and securability are

the requirements categories for identifying such

a directory.

Novell eDirectory has grown from a foundation

that is secure, reliable and scalable, while adapting

to emerging standards and meeting the needs

of developers. From LDAP to SOAP and from a

strong and flexible security model to unmatched

scalability, eDirectory is the unparalleled leader

in the high-end directory space.

Active Directory, in its second generation (as

opposed to eDirectory in its eighth), struggles to

simply meet the needs of the network operating

system for which it was built. Meeting the needs

of the high-end directory market is still a far sight

from the current iteration of Active Directory.

For many organizations, having Windows

servers for line-of-business applications requires


21

462-001396-002

© 2004 Novell, Inc. All rights reserved.Novell, the Novell logo, NetWare,NDS and Novell Directory Services areregistered trademarks, and eDirectory,NMAS and the N logo are trademarksof Novell, Inc. in the United States and other countries.

*Active Directory, ActiveX, Microsoft,Visual Basic, Windows and WindowsNT are registered trademarks ofMicrosoft Corporation. Linux is aregistered trademark of Linus Torvalds.UNIX is a registered trademark ofX/Open, Ltd. AIX, IBM, TivoliEnterprise Console and WebSphere are registered trademarks of IBMCorporation. HP, HP-UX andOpenView are registered trademarks ofHewlett-Packard Company. Unicenter isa registered trademark of ComputerAssociates International, Inc. Java andSolaris are registered trademarks, andJ2EE, JavaBeans, JDBC and JNDI aretrademarks of Sun Microsystems, Inc.BEA and WebLogic are registeredtrademarks of BEA Systems, Inc.Oracle is a registered trademark ofOracle Corporation. PeopleSoft is aregistered trademark of PeopleSoft, Inc.SAP is a registered trademark of SAPAG. All other third-party trademarks arethe property of their respective owners.

Novell Product Trainingand Support Services

For more information about

Novell’s worldwide product

training, certification programs,

consulting and technical support

services, please visit:

www.novell.com/ngage

For More Information

Contact your local

Novell Solutions Provider,

or visit the Novell Web site at:

www.novell.com

You may also call Novell at:

1 888 321 4272 US/Canada

1 801 861 4272 Worldwide

1 801 861 8473 Facsimile

Novell, Inc.404 Wyman Street

Waltham, MA 02451 USA

www.novell.com

having Active Directory in some form or other.

While this may be the case, it is important to

recognize that Active Directory is a network

operating system directory and cannot effectively

fill the role of a high-end directory service.

In contrast, Novell eDirectory fills the high-end

need. And through meta-directory technologies such

as Novell Nsure Identity Manager, eDirectory can

integrate an Active Directory deployment with

many other identity-enabled systems, such as

Oracle*, PeopleSoft* and SAP*. Such an approach

assures that Active Directory can be managed

appropriately for the services it provides.

When compared head-to-head with Microsoft

Active Directory, Novell eDirectory:

• Provides unmatched scalability, which has

been demonstrated to 1 billion identities and

backs many of the world’s largest identity

management systems.

• Assures better compatibility with its LDAP

Certified distinction, as well as support for a

variety of other directory access standards.

• Comprises better reliability, thanks to

automated self-repair, multi-master

replication, live maintenance tools and

disaster recovery tools.

• Excels in manageability—having complete,

well-thought-out management tools, and

allowing organizations to easily tune and

adapt eDirectory to accommodate changing

business requirements.

• Offers much better securability through its

host platforms, access control model and

authentication options.

Novell eDirectory is the industry’s best choice

for large-scale, high-end directory deployments,

providing an identity cornerstone for the enterprise

and the Internet that can grow and adapt to meet

the demands of your business today and tomorrow.

For more information about Novell eDirectory,

go to www.novell.com/edirectory. You can also

contact one of thousands of Novell partners

worldwide or contact Novell directly at 1-888-

321-4CRC (4272).


22

Novell eDirectory vs. Microsoft Active Directory - …osman/462139… · · 2008-10-14COMPETITIVE...

Documents

Transcript of Novell eDirectory vs. Microsoft Active Directory - …osman/462139… · · 2008-10-14COMPETITIVE...