Differences Windows Active Directory and Novell Directory Services

Differences Windows Active Directory and Novell Directory Services
Donnie Hamlett Technology Specialist Microsoft – New York

Agenda Introduction X.500 Directories, History and Terminology
X.500 Implemented with AD and NDS Objects Networking and Services LDAP Directory Design and Partitioning the Directory Programming Summary

Introduction Purpose of this session is to get a thorough understanding of the basic differences between the Windows 2000 AD and Novell NDS.

X.500 History X.500 is the standard produced by the ISO/ITU defining the protocols and information model for a directory service that is independent of computing application and network platform X.509 Authentication Framework is a series of standards, describes the use of digital certificates and PKI X.525 Replication First released in 1988 and updated in 1993 and 1997 X.500 standard defines a specification for a rich, distributed directory based on hierarchically named information objects (directory entries) that users can browse and search X.500 – Glorified, very logical, electronic yellow pages for X.400 messaging systems

X.500 Fundamentals DIB - Directory Information Base
The actual database(s) that store(s) the entries in the directory service Directory Information Tree Dictated by the database schema to present a hierarchical tree objects DIT DIB

X.500 Schema Object Classes
Design of the directory store. Defines objects, attributes, and system information Object Classes Define the kinds of objects that can be instantiated in the directory Define the rules for an object Define the attributes that are intended for the object DIB Object Attribute

X.500 Objects Attributes Specific entries in the directory store
Are comprise of attributes Attributes Describe certain aspects of the object USER OBJECT Attributes..First Name, Last Name, Phone Number, Address

X.500 Directory Services DSA - Directory System Agent
The actual process client applications bind to to search the directory Utilizes DSP - Directory System Protocol DUA - Directory User Agent Client Process that binds to a DSA to retrieve information from the directory Utilizes the Directory Access Protocol Access Protocols DAP – Directory Access Protocol LDAP – Lightweight Directory Access Protocol, developed because DAP is bulky and it didn’t lend itself to the internet. DAP LDAP

X.500 Directory Services O=US, O=Microsoft, OU=Development, CN=Thomas
Hierarchy Representation of data in the directory. Is easier to use than flat systems Defined in X.500 (Root) DC – Domain Component C – Country L - Locality O – Organization OU – Organizational Unit CN – Common Name Distinguished Name defines the name and location in the DIT Relative Distinguished Name Uses a reference point, Partial name O=US, O=Microsoft, OU=Development, CN=Thomas

X.500 Implemented with AD and NDS
No one used the full set of X.500 definitions to design their directory service. Everyone has their own proprietary take on how X.500 is implemented.

Differences – X.500 Names Both Novell and AD use X.500 name schemes but they do not implement all of them. Active Directory DC OU CN Novell Directory Service C O OU CN

Differences – Objects Windows – Static Inheritance
More weight on directory at creation, write intensive All Ace's are contained within the object Larger objects increases the size of the DIB Rights controlled by groups Novell – Dynamic Inheritance When the object is called you must aggregate its rights by walking the tree More weight on the directory when read Rights controlled by OU’s (also groups) Must Tree Walk – this can go across WAN – bad

Sales Managers read access
Object Access ACE ACEs can apply to specific attributes ACL Sales Managers read access Directory Object Access to directory objects is controlled via Access Control Lists (ACLs) Fine granularity is provided by Access Control Entries (ACEs) that apply to specific attributes

Global Data Availability - Catalogs
Windows 2000 Forest acme.com xyx.com asia.acme.com europe.acme.com = Global Catalog Replica Active Directory Catalogs: Enable efficient cross-domain data sharing Use the same set-up tools as replicas Use same replication mechanisms and the same interval as domain replicas Enforce object and attribute level security Slide Objective: Compare AD catalog services with NDS catalog services. In addition to the WAN and replication aspects of Global Data Availability are catalogs. Since it is not always practical to store all possible objects in a single partition, both NDS and Active Directory have provided global catalog functionality in their directory services. Catalogs gather, store and organize a subset of the information about all directory objects in the organization that may be of interest throughout the company (like employee names and phone number). Catalogs are useful in customer scenarios where wide areas networking may make replication traffic prohibitively slow (for example across oceans between the USA and Europe) or when multiple partitions are required to support a highly decentralized organizational structure. Active Directory provides a mechanism called the “Global catalog” to allow administrators to build a specialized directory containing a subset of object attributes that are of company-wide interest beyond a single domain. Catalogs are set up by assigning a GC to individual domain controllers and specifying which object attributes will appear and be replicated in the global catalog using the Schema Manager snap-in. When changes are made to objects, those changes are propagated automatically using the same replication technologies used within a domain. As a result of this shared replication technology: GCs require no special set-up and configuration is easy. GCs are updated simultaneously with with the directory to ensure that catalogs are consistent with the directory GCs enforce the same object and attribute level security settings as exist in the directory.

Global Data Availability - Catalogs
Dredger Dredger Dredger San Diego Chicago Boston NDS Catalogs: Are based on periodic ‘dredging’ Occur only at scheduled 1-7 day intervals Users are granted/denied access to entire catalog – no attribute/object-level security Are being completely redesigned... Slide Objective: Compare AD catalog services with NDS catalog services. While Active Directory catalogs are tightly integrated with domain replication technologies simplifying set-up and administration, maintaining the same security settings while not experiencing any latency between replicas and GCs, NDS has a very different approach Unlike NDS itself, NDS catalogs are not incrementally updated, but are entirely rebuilt from scratch every 1-7 days using a process known as the “dredger” which reconstructs the catalog from scratch and strips all security setting s from the object and attributes that are stored in the catalog - meaning that catalog users either have access to the entire contents of the catalog or they don’t. Microsoft believes Novell's catalog approach has several weakness in facilitating global; data availability with the enterprise. Because of the time required to dredge every partition individually, Novell recommends that catalogs only be rebuilt periodically (default is 24 hours). This means that catalogs are likely to be out of date with the underlying objects in their partitions. Objects that are dredged lose their access control properties. Because a lot of the value of directories resides in the ability to only present a limited view of directory object information to people who need to see it, customers will tend to only put information in the catalog that they feel comfortable having all people see, making the catalog less useful. To address this attribute level access control settings, Novell does allow you to construct multiple different catalog views for different sets of users, but this requires duplicated effort in set-up and administration and substantially increases catalog dredging time. Finally, it is important to note the Novell has been in the process of reevaluating its entire catalog architecture and may decide to redesign them entirely.

Differences – Networking and Services
Active Directory Based on TCPIP DNS Server Resource Records ( MX-Record) LDAP for internal searches, each object has a unique GUID example on following page All Domain Controllers are native LDAP Servers Integrates with DNS NDS Originally based on IPX/SPX Service Advertising Protocol (SAP) to advertise Services Implemented in TCPIP with Service Location Protocol (SLIP) also advertisement based SLIP does not integrate with DNS proprietary When implemented together reduces network performance because routers must support RIP that allows for both SLIP and SAP protocols Not a native LDAP Server – it has a LDAP interface that translates LDAP request to native NDAP protocols

Active Directory Global namespace = DNS + LDAP Directories
edu com stanford microsoft aVendor students courses music Domain : microsoft.com Vera Kark MargretJ sarahj thorj Domain : aVendor.com Domain: stanford.edu

Internet Standards Support - LDAP Active Directory vs
Internet Standards Support - LDAP Active Directory vs. NDS – LDAP Search Better Slide Objective: Show LDAP Performance of Active Directory as compared to Novell NDS The next Internet Standard of general importance is LDAP. Now both Active Directory and the most recent version of NDS support LDAP v.3, but each directory supports it in different ways. Microsoft design Active Directory, from the ground up, as a native LDAP server, meaning that LDAP-based requests are processed natively and without translation against the Active Directory data-store. In addition all of Active Directory’s services are published via LDAP for ease of interoperation with other LDAP-based applications. For example, even schema management, change history, and query scoping are published through LDAP In contrast, NDS is not a native LDAP server and LDAP queries made against NDS must be translated to Unicode and then re-translated back in to LDAP for every LDAP request. This dramatically slows LDAP Query performance as illustrated on this graph. On a single processor server, Windows 2000 Server provides more than twice the number of LDAP queries per second. More important, Active Directory performance scales on SMP servers. On a 4-way server, Windows 2000 Server provides more than 6-times the number of LDAP queries per second when compared to Novell’s NDS. This means that customers can deploy fewer Active Directory servers to service LDAP queries; thus lowering equipment costs and management overhead. In addition to LDAP performance, not all NDS services are published through NDS meaning that: Differences in LDAP and NDS data forms may inhibit 1:1 mapping of class and attribute data Multiple access methods must be implement in NDS since schema management through LDAP controls is not provided Enabling access to NDS namespaces containing multiple partitions requires companies to either expose their applications to the performance limitations of tree-walking or deal with catalogs that may be out of date. Test and Configuration Information: 1 million object database (500K users, 500K contact objects) All data in memory Indexed base query for given name of a user Xeon 400 MHz with 4GB RAM Note: Novell has performed 2 different LDAP tests also at Key Labs which indicate that NDS is the faster directory. However, Novell’s tests are peripheral tests which do not reflect common or a large number of usage scenarios as have been demonstrated with Active Directory. Please see the following market bulletins for more detailed information: NDS Active Directory LDAP Requests Processed Translated Natively Services Published through LDAP Limited All Active Directory is a faster & more interoperable LDAP Server

Differences - Design Active Directory
Partition the directory by Domain Different Administrative view and Replication view Domain Site Replication occurs via sites (IP subnets of good connectivity) A server can only host one Domain partition Multi-master replication Uses update Sequence Numbers to prevent corruption Replication is controlled and easy to configure A Domain can efficiently span multiple sites

Replication What is Replicated ? – only changes are replicated
Directory Information Configuration Schema There are two forms of replication Intrasite Replication Intersite Replication Knowledge Consistency Checker Automatically configures and checks topology for the most efficient replication Tools Sites and Services MMC snap-in Replmon

Sites A Site separates networks physical topology from the Active Directories logical view of the Network Site is a area of “good connectivity” A Site is a collection of subnets All directory replication is controlled via Sites A Site can be composed of multiple Domains Clients discover their site based on the subnet mask received from DHCP (or hand-configured) Basis for locality-based resource discovery

Intrasite Replication
Automatically Configured for you Replication occurs whenever there is a directory change or a interval of ~ 7 minutes Not Compressed Not easily controllable

Intrasite Replication
Domain Controller Domain Controller Domain Controller Intra-Site Replication Domain Controller Domain Controller

Intersite Replication
Compressed 10-1 Configurable Scheduled (15 minutes – 3hours) RPC or SMTP Site Links Site Bridges

Intersite Replication
Domain Controller Domain Controller Domain Controller Inter-Site Replication Site 1 Domain Controller Domain Controller Domain Controller Domain Controller Domain Controller Site 2 Domain Controller Domain Controller

Site Links Represents the Priority of Replication Traffic Between the Sites Identified in the Site Link Higher Cost Numbers Represent Lower Priority Replication Paths Control Topology by Setting the Costs on Site Links Control the Replication Frequency by Setting the Number of Minutes Between Replication Attempts Control Link Availability Using the Schedule on Site Links Can Link multiple site to create a controlled path of replication called a Site Bridge

Site Links and Bridges Site Link Bridge XYZ Site X Site Y Site Link XY
Site Z Site Link YZ

Architecture Replication
Based on update sequence numbers Local USN advanced by any write Each replica knows last USN obtained from each partner Replication is per property Property versioning for collision detection and resolution Propagation dampening via “up-to-date” vectors Uses RPC or messaging Replication Units: Domains (in NT 5.0) Not Time Based Each server has a local, monotonically increasing Update Sequence Number (USN) Any write increments and stores the current USN in the object and property written Deletions leave tombstones Properties are versioned for collision detection A DC maintains the last USN sent by each partner DC Requests objects with USN greater than saved USN (pull replication) Property Versions maintain consistency Time used only for arbitration in property update collisions Per-property replication makes collisions extremely rare Forward Optimization: do no transmit changes that have reached the target via another path

Before replication R1 R2 R1 USN:5 R2 USN:273 R1 USN:3 R2 USN:305 R3 USN:54 R3 R2 USN:273 R3 USN:62

After replication R1 R2 R1 USN:5 R2 USN:305 R1 USN:5 R2 USN:305 R3 USN:62 R3 R2 USN:305 R3 USN:62

Sites and the AD Site Seattle Site Redmond Site Paris Microsoft Sales
MSHQ1 MSHQ2 MSHQ3 Sales HR Sales1 Sales2 Sales3 Europe HR1 HR2 MSNA MSNA1 MSNA2 EURO1 EURO2 MSHQ1 HR1 Sales1 Sales2 MSHQ2 HR2 MSNA1 MSNA2 EURO1 Site Seattle Site Redmond Site Paris MSHQ3 Sales3 EURO2

Operation Masters These Roles are These are the following Roles
Recoverable – Recovery Console Transferable – Command Line These are the following Roles RID Master – one per domain, controls relative id’s PDC Emulator – one per domain, allows password updates and backwards compatibility with NT 4.0 BDC’s Infrastructure Master – one per domain, updates group and user information when changes are made Schema Master – one per forest, controls schema updates Domain Naming Master – one per forest, controls all additions and removals of domains

Differences - Design NDS Partition the directory by OU
OU’s are tied to physical locations Multimaster replication A server can host multiple partitions Replication occurs via time stamps Replication is very difficult to configure and is not controllable It is not recommended to have OU’s span physical boundaries

Global Data Availability - Searches
Windows 2000 Domain AD Replica Boston San Diego Chicago AD Replica Boston Chicago San Diego AD Replica Boston Chicago San Diego Find: ‘All Bobs’ Replication Answer Slide Objective: Show differences in AD and NDS WAN Replication technologies and the impact on performing directory searches. The first aspect of facilitating global data availability throughout the enterprise are “Searches”. In an enterprise directory environment searches are performed frequently to collect information stored in the directory about users, machines and network resources. In Active Directory a full and complete copy, or “replica”, of the entire Active Directory database for a given domain is located at every site, in this example San Diego, Chicago, and Boston, wherever there is a domain controller. Each replica is a fully write able copy so that changes to the directory can be made in any location with a domain controller. This is known as a mullti-master directory model. The directory replicas are kept in sync, through periodic replication, where only the attribute changes made to each local replica are propagated to all other sites. As a result all sites contain a full replica of the entire directory which can be searched locally, so that searches do not need to cross WAN links to obtain a complete result set. This architectural design improves read performance and provides redundancy in the event that a WAN link is lost. [Advances Slide Build] A simple example of this is shown above where a San Diego user submits a query “looking for all Bobs” against the local Active Directory replica. Instead of crossing to the Chicago and Boston sites to collect this information, the result set can be completely and assembled just from querying the local copy of the directory. These types of searches are very common in enterprises and could have just easily been done for such searches as “Find all color printers” or “Find all Marketing Groups” of Find all users with this phone number”. Active Directory: Partitions map to Windows 2000 domains Partitions can span many sites and WAN links Optimizes replication automatically between sites and over slow network links Impact: Faster and more complete searches

Global Data Availability - Searches
NDS Tree San Diego Chicago Boston Find: ‘All Bobs’ San Diego San Diego San Diego WAN Chicago Chicago Chicago Answer Boston Boston Boston NDS Server NDS Server NDS Server Slide Objective: Show differences in AD and NDS WAN Replication technologies and the impact on performing directory searches. NDS is designed differently. In NDS, Novell recommends that partitions do not span WAN links. Therefore each site is its own partition and boundary for replication. Therefore, information about other partitions is not stored locally and the scope of replication is limited to sites. As a result, cross-location searches, like the one illustrated before must tree walk across WAN links every time a query is made against the NDS directory. Using the same example a search for “Find all Bobs” will have to cross a WAN at least four times for the query and the result for each partition. [Advance Slide Build] This is less than ideal since query results must span WAN links which consume bandwidth and take more time to complete. In addition, if just one of the WAN links was down at the time of the search, the result set from the query could be incomplete and would not include the information stored on a given partition, making searches in NDS potentially incomplete. So why does Active Directory and NDS differ so much on how they perform searches? Mostly it’s a result of the way Active Directory and NDS perform replication. NDS Version 8: Partitions cannot span WAN links . . .easily Replication does not occur on an inter-site basis Cross-location searches must ‘tree walk’ Impact: Slower and less complete searches; more network traffic

Global Data Availability - Replication
NDS WAN Site 1 Site 2 Active Directory WAN Site Site 2 Slide Objective: Show the greater complexity and higher cost of NDS WAN replication and why Novell recommends against partitions that span WANs. In NDS, Novell recommends that partitions not span WAN links because cross-site replication occurs so inefficiently. For example, in the case where there are just 2 sites with 5 replica servers in each site, NDS would create a one-way point-to-point replication session between each pair of servers, or 90 connections in total. While connections within a site are not expensive due to the speed on LAN-based networking, there will be 25 connections that cross the WAN between the sites. Since WAN links are often both slower, less reliable and more expensive this is a costly replication mechanism. This situation only becomes more complex as additional sites are added. For example just adding a third site with 5 replicas would increase the number of WAN connections from 25 to 75. [Advance Slide Build] In contrast, Active Directory’s design is more efficient with regard to both replication and WAN bandwidth usage. Using the same two site 5 replicas/site example, Active Directory only requires 13 connections, rather than 90, and only a single WAN connection, rather than 25. This is due to Active Directory’s use of the Knowledge Consistency Checker (or KCC) which automatically analyzes the network topology and configures inter-site bridgehead servers. This ensures that a single replication event will only be sent across the WAN only once. Further, Active Directory uses a spanning tree algorithm to reduce the number of connections required within a site, supports replication scheduling to minimize the usage of WANs and automatically compresses all data sent across a WAN link by a factor of 8-10 times. Note: Now using Novell’s WAN Manager technology administrators can hand-configure replication topologies to simulate bridgehead and spanning tree behavior, but: Routing tables must be maintained manually on each replica server There is no data compression Only rudimentary replication scheduling services Because of these reasons, WAN Manager is not widely used in practice by NDS administrators, and Novell recommends that partitions not be configured to span WAN links for this reason alone. R B Replica Bridgehead Server Connection NDS: 90 Connections; 25 WAN crossings Active Directory: 13 Connections; 1 WAN crossing

Internet Standards Support - PKI
Authorization Authentication Kerberos File System Windows 2000 Smart Card X.509/PKI Active Directory Certificates Active Directory Advantages: Better PKI Management integrated key recovery mechanism and revocable certificates web-based access and management integrated client-side distribution of keys Comprehensive OS Integration (IIS, EFS, IPSec) Application Integration (CryptoAPI) Slide Objective: Show better PKI management and integration with Active Directory as compared to Novell NDS The final component of Internet Standard support is support for PKI technologies. Microsoft believes that public key technologies will form the basis for the majority of security infrastructures deployed over the Internet. Uses range from simplifying Virtual Private Networking within a company to enabling secure transactions in business to consumer e-commerce scenarios. Because directory services are an integral part of making public key technologies easy to use and manage, it is important to evaluate the degree of integration between a given directory service and the Internet security technologies that a company plans to use. Microsoft believes there are 3 key areas in which the PKI technologies of Windows 2000 are superior to Novell’s PKI offering: Management. Windows 2000 PKI provides for: Integrated recovery key mechanisms. Novell’s PKI does not support tools for the recovery, archival or escrow of encryption keys. Revocable Certificates. Novell’s PKI does not provide a mechanism for revoking certificates once issued. – for example there is no way in NDS to disable a certificate issues to a fired employee. Web-based Access and Management. There is no way to access Novell’s PKI through a web browser as an admin or user. Client-side distribution. The PKI in Win2000 is integrated to automatically distribute root keys to clients. Novell’s PKI is not integrated with ZENWorks to distribute keys – this means that every user needs to manually request, download and manage certificates using a ConsoleOne client. Operating System Integration Windows 2000 PKI is integrated into the core operating system functions such as EFS, IIS web server, IE and IPSEC support and provides a platform for smartcard ISVs Novell’s PKI lacks comprehensive integration with its NetWare operating system, or any other OS. Further Novell’s PKI is layered onto NDS and is not integrated with its core authorization and authentication functions. Application Integration Microsoft provides a comprehensive API called CryptoAPI that enables ISVs and customers to PKI-enable their applications. In contrast, NDS does not provide a similar API to enable ISV or customer applications with PKI services. In summary both Novell and Microsoft directories support PKI, but as we’ve seen with other internet standard support areas: it’s the degree and extent of integration and management tools that most distinguish the two directory services.

Internet Standards Support - Summary
Active Directory Native LDAP server Full namespace integration with DNS Integrated support for PKI technologies NDS LDAP requests are translated No Namespace Integration with DNS Limited Integration with PKI On the second of the four key directory solution requirements for customers, Internet Standards support, Microsoft delivers a directory that best integrates with and leverages the three key internet standards: Active Directory provides: A native LDAP server that publishes all of its services through LDAP for faster performance and simplified integration with other LDAP services. NDS in contrast has just recently added LDAP support to NDS and must translate LDAP requests slowing performance and has yet to publish all NDS services through LDAP complicating administration and integration. Full namespace integration with DNS, the location mechanism for the Internet. Because domains have a 1:1 relationships with Active Directory partitions, Active Directory namespaces can be located directly through DNS. NDS, in contrast,using an entirely separate locator mechanism, SLP, to locate internal resources which is unrelated to DNS used externally, increasing management and making service location much more difficult. Integrated support for PKI technologies for simpler security administration of extranet transactions and services, automatic distribution of public keys to clients, and a better platform on which to PKI-enable applications. NDS, in contrast lacks any application-level PKI support, no OS integration, and lacks key PKI management capabilities like revocable certificates, encryption key recovery, and client-side distribution making Novell’s PKI more costly to administer due to its greater dependence on manual administration Finally, its important to summarize the directory solution requirement of Internet Standards support as one that goes beyond surface level support but the the degree to which the standard is integrated in to the directory and how it reduces management, enables interoperability, and allows an enterprise to transact and communicate over the Internet. On all counts Microsoft believes the Windows 2000 Active Directory meets these requirement far better than NDS.

Application Integration
NT-DS Application Active Directory A D S I O L E D B NDS Application A D O LDAP Application Databases Active Directory Services Interface Provides a consistent, simple way for COM-enabled apps to access directory services Usable for any LDAP server (including NDS) Leverages COM Windows Development tools Greatly simplifies development of directory-enabled applications Slide Objective: Show the Unique Value of ADSI in easily enabling applications with directory functionality. Since the Windows platform is the richest for application developers and is supported by over 8,000 applications, the Active Directory feature set is extensive, Microsoft invested considerable effort in making those features as accessible and leverageable as possible by making it easier to write directory-enabled applications that access the Active Directory and other LDAP-enabled directories. The culmination of this effort is the Active Directory Services Interface (or ADSI). ADSI is a set of extensible easy-to-use programming interfaces based on Microsoft COM that can be used to to write applications that can access and manage: Active Directory Any other LDAP-based directories And other directory services, including NDS. ADSI abstracts the capabilities of directory services from different network providers to present a single set of directory service interfaces for managing network resources. As a result ADSI greatly simplifies the development of directory-enabled applications. Developers and administrators can use this single set of directory service interfaces to manage network resources no matter which network environment contains the resource. Combined with the wealth of tools that support COM such as Visual Basic, Visual C++, and Visual J++ development systems ADSI makes it easy for developers to directory enable their applications.

Application Integration
Active Directory enables powerful directory-enabled applications Group Policy Integration Service Publication Directory Object Extension ADSI Extension Model Active Directory Class Sore AD-enabled Applications Baan, J.D. Edwards, SAP, Cisco & others BackOffice 2000, MSMQ, MTS and most others Slide Objective: Describe the Management and functionality benefits enabled by Active Directory application integration. Active Directory was designed to provide developers with the features they need to build powerful directory-enabled applications that provide greater functionality and lower TCO. Active-Directory-enabled applications can provide: Group Policy Integration: that allow administrators to define sets of applications, including specific configurations, that users should have available based on their role in the company, the domain of which they are a member and the security groups to which they belong. Service Publication: that enables applications to publish the names and locations of services they provide so that client s can access and use those services dynamically – which in turn allows administrators to reconfigure servers for optimal response tikes and availability without having to update clients. Directory Object Extension. provides the ability for applications to add new types of objects and to extend existing objects with new attributes. This enables Active Directory to be a consolidation point for reducing the number of directories that companies have. Benefits include improved information sharing and common management of users, computers, applications, and directory-enabled devices. The ADSI Extension Model. enables application developers to associate COM-based business rules with objects stored in Active Directory. This provides a consistent and simple way for developers and administrators to interact with an application and its objects. The Extension Model also makes it easy to invoke methods across groups of objects, such as ‘all users in the Accounting department’ to simplify administration. The Active Directory Class Store. is used to store the names (for instance, Class ID or Program ID) and locations of COM objects installed on the network. COM uses the Class Store to locate and install the COM objects that users are allowed to use on their machines automatically. This can lower the TCO of COM-based applications by simplifying client configuration and administration. Windows 2000 Server and Active Directory together provide a full-featured platform for building directory-enabled applications. As a testament to the power of this platform leading vendor like Baan, JD Edwards, SAP and Cisco have added support for Active Directory within their products. Moreover the Windows 2000 Server logo program requires applications to integrate with Active Directory where appropriate. In addition, Microsoft itself is AD-enabling its next generation of BackOffice and Front Office applications either natively, as in the case of Exchange 2000, or through integration to provide richer and more integrated directory-enabled services to the Microsoft family of applications.

Application Integration - Summary
Windows 2000 & Active Directory COM, ADSI, Logo programs LDAP-based access to all features Rich Development Environment (VB,C++,Java) Supports Distributed Applications over WANs Large ISV Support: 8,000+ Windows Applications NetWare & NDS ADSI support not available on NetWare Incomplete LDAP-based access to NDS features Java-only development environment Partitions limit application functionality Poor ISV Support - GroupWise not even NDS-enabled In summary, Active Directory has provided compelling reasons for developers to write AD-enabled applications including: A simplified development environment for doing so through ADSI and COM LDAP-based access to all Active Directory features A rich development environment supporting Visual Basic Visual C++ and Java development environment Support for distributed applications over WAN so that developers don’t have to build enterprise-wide applications that must be aware of the partitions and WAN boundaries of the customer’s network topology. Which has resulted in large ISV support to AD-enable their applications. The Windows code-base today supports over 8,000 applications. Scores of which are being logo-certified every month for use on Windows 2000 that are Active Directory-aware. In contrast the NetWare platform and NDS directory service have almost no application integration support for enterprise customers: ADSI support is not available on NDS – making the development of NDS-enabled applications time-consuming and difficult Only a limited number of NDS service are available through LDAP – meaning fewer opportunities for developers to build functionality into their applications The development environment is limited to Java with no support for other and more common development environments – limiting the pool of developers who could potentially write NDS-enabled applications NDS partitions are limited to the boundaries of the LAN and are not recommended to span a WAN - forcing every developer to build applications that have to be aware of how each NDS directory is partitioned in order to avoid doing cross-WAN searches that would involve tree-walking. As a result of these inherent limitations imposed on developers there are very few enterprise applications that are truly NDS-enabled after several years of NDS availability on the market. As testimony to the difficulty of developing NDS-enabled applications, not even Novell’s own GroupWise applications product is NDS-aware and uses its own database. It is becoming increasingly apparent that a directory that lacks simple application integration capabilities and a rich underlying platform does not interest many developers and lowers the value of a directory-enabled network environment.

Active Directory vs. NDS
Active NDS Comparison Directory Version 8 Storage technology Indexed Indexed Max objects/partition Millions Millions Partition Boundary Geo/Political WAN Partition-spanning groups? Yes Not Advised Same store for catalogs? Yes No Catalog update interval Continuous Scheduled Attribute security in catalog? Yes No Native LDAP support? Yes No Global change LDAP interface? Yes No DNS naming integration Yes No Integrated PKI support? Yes No ADSI provider support? Yes Yes* Java Support Yes (JADSI) Yes (JNDI) VB, C, C++ Support Yes No Interoperability Tools Yes No Slide Objective: While Active Directory and NDS8 share similar functionality and scalability, Active Directory exceeds NDS in providing an Enterprise-class directory service. To recap the main differences between Active Directory and Novell’s NDS in meeting the directory solution requirements of enterprise customers today it is important first to note that: Both Active Directory and NDS have an indexed storage technology and scale to met he requirements of any environment easily. However, its in meeting the more advanced directory solution requirements of today’s and tomorrow’s enterprise customers where the differences between the two directories come in stark relief. Regarding Global Data Availability AD does much more efficient replication and can afford to replicate the entire name space on every DC meaning fewer partitions and less administration. AD therefore does not force customers to partition ‘artificially’ around WAN boundaries (geo/political boundaries are non-technical limits). In contrast both NDS partitions and groups don’t span WAN links. Active Directory’s catalog architecture using the same replication mechanisms as domain replicas so that global catalogs are continuously up-to-date and maintain both the same object and attribute level security permissions set in the directory itself. In contrast NDS catalogs use an entirely separate replication mechanism that actually rebuilds the catalog from scratch on a scheduled basis which means that the catalog and underlying directory are out of sync. Moreover the catalog strips all security permissions set on objects and attributes meaning that the NDS catalog needs to be manually maintained. As far as support for Internet Standards support is concerned. Both directories support LDAP, DNS and PKI technologies but Active Direcot4r implements these standards in a more integrated manner that improves performance and reduces management. First Active Directory is a native LDAP server improving performance by 2-6 times that of NDS and publishes all of its services through LDAP to simplify interoperability and application integration. In contrast, NDS LDAP support is only translated which slows down performance and only provides a limited set of NDS services through LDAP. Second Active Directory provides DNS namespace integration to facilitate extranet management and the location of intranet services. While NDS 8 does allow the use of a DNS-style syntax, they have not integrated DNS naming into their scheme the way AD does and instead uses its own proprietary implementation of SLP, vastly complicating the location of resources . There is no DNS-based ‘global root’ capability and there is no guarantee of universal object name uniqueness. Third, Active Directory has extensively integrated PKI technologies to provide such useful management time savers as integrated key recovery mechanism and revocable certificates, web-based access and management and integrated client-side distribution of keys. NDS provides none of this. In the area of application integration, Active Directory provides A rich tool and development environment that allows vendors and customers to easily directory-enable their applications and devices to reduce management and enhance functionality. NDS in contrast provides few tools and only a Java development environment to do the same. NDS also provides no single place that applications can obtain information about object changes in the tree. Each partition can report changes but apps need to put a listener in each partition and ‘roll up’ the events themselves. Moreover, Netware lacks the application services found in Windows 2000 that would make Netware an attractive platform to host applications since Netware lacks SMP, transaction, component, queuing, and universal language support Finally Active Directory provides a flexible set of interoperability services that consolidate directory management with synchronization and meta-directory services as well as application integration and full LDAP support. Novell in contrast lacks synchronization tools, has an unclear meta-directory strategy while providing few application integration tools and only limited LDAP service publishing support and instead chooses to recommend that customers just simply rip and replace their directories with a on-size-fits all NDS service. * Not available to NetWare applications

This document is for informational purposes only
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. © 2000 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Where do you want to go today?, Windows, the Windows logo and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Closing In today’s marketplace, organizations need to carefully manage their costs in order to stay competitive. Windows 2000 Server has been designed to provide powerful management through its integrated Active Directory service. Active Directory enables customers to increase the value of their existing investments and lower their overall costs of computing by making the Windows network operating system more manageable, secure and interoperable. For more information on the Windows 2000 Active Directory see:

Differences Windows Active Directory and Novell Directory Services

Similar presentations

Presentation on theme: "Differences Windows Active Directory and Novell Directory Services"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Differences Windows Active Directory and Novell Directory Services

Similar presentations

Presentation on theme: "Differences Windows Active Directory and Novell Directory Services"— Presentation transcript:

Similar presentations

About project

Feedback