Queue, support for NT clustering, and built-in router technology, NT should prove to be a formidable force for enterprise computing.
Directory Services
Central to NT 5.0's
new features
is its directory service, called Active Directory. Due to be included in the NT 5.0 release in early 1998, Active Directory puts to rest complaints that NT doesn't have an enterprise-capable directory system.
Compared to X.500, NetWare Directory Service (NDS), or Banyan's StreetTalk, the less robust directory services in NT 4.0 were paltry. Rather than create something new, Microsoft built Active Directory entirely around the Domain Naming System (DNS) and Light
weight Directory Access Protocol (LDAP).
We're familiar with DNS as the hierarchical, replicated naming service on which the Internet is built. Although DNS is the backbone directory protocol of the largest data network in the world, it doesn't provide enough flexibility to act as an enterprise directory by itself. DNS is largely a service for mapping machine names to IP addresses. A full directory service must be able to map names of arbitrary objects (e.g., machines and applications) to any kind of information about those objects.
Enter X.500, a hierarchical, replicated directory system that allows locating everything from systems to services. Despite years of availability, however, X.500 has not been widely used, largely because it's extremely complex. That's where LDAP comes in. A simplified version of X.500's DAP, LDAP has received promises of support from several directory vendors, leading to the possibility of a common way to access diverse directories.
Active Directory builds on both
DNS and LDAP. It groups machines into administrative units called domains, each of which gets a DNS domain name, such as acme.com. Each domain must have at least one domain controller, which is an NT machine running the Active Directory server.
While an Active Directory domain controller must run on an NT server, any client with DNS and LDAP software can potentially access that controller's directory database. DNS is, and LDAP will soon be, a widely deployed industry standard. Thus, Unix, Mac, and OS/2 clients should be able to access an Active Directory server in the same way as Windows and NT clients (see the figure
"How Active Directory Works"
).
Furthermore, the Active Directory database can store all kinds of information, which means that you can use it as a general-purpose directory service for a heterogeneous network. For example, it allows storing and retrieving of the information needed to contact a service running on a Unix server in the network. For Microsoft to tak
e an ecumenical approach to a key technology is surprising.
For improved fault tolerance and performance, a domain can have more than one domain controller, with each holding a complete copy of that domain's directory database. Active Directory implements multimaster replication, which means that an entry can be changed in any domain controller's replica of the database and that change will eventually propagate to all other replicas in the domain.
To accomplish this replication, Microsoft created a protocol to communicate between domain controllers. Active Directory also supports the X.500-defined Directory Information Shadowing Protocol (DISP) for interoperable replication with the outside world, but it's not clear how useful this will be. Achieving effective replication relies on both a common protocol and a common view of what is being replicated (i.e., on a common schema for the directory databases involved). Several largely independent efforts are in progress to define how those schemas shoul
d look. However, until this issue is resolved, standard replication protocols are of limited value.
For Microsoft, creating a proprietary replication protocol for use among domain controllers lets Active Directory be more flexible than it could have been relying solely on DISP. For example, Active Directory allows replication to occur using remote procedure calls (RPCs) over LANs, but it also allows domain controllers to exchange replication information using e-mail over links with slow or sporadic connections (users trying to build NT-based networks in countries with unreliable telephone systems will appreciate this second option).
For well-connected servers, such as those located in the same physical site, replication exchanges generally take place every 5 minutes. For servers that aren't so well connected, such as those that are connected by a slow WAN, you can configure the replication interval as needed. Also, whatever the interval, only the specific information that has been changed is copie
d -- there's no need to copy the entire directory database.
Finally, Microsoft provides no shortage of different APIs for Active Directory clients. The preferred choice is the Active Directory Service Interface (ADSI), a generic COM-based
interface
usable with Active Directory, NDS, and other directory services. Other options include Microsoft's MAPI, LDAP's C API, and OLE Database, another COM-based interface that allows access to all kinds of data, whether it's stored in a relational database, an ordinary file, or even, as in this case, a directory service. Software developers are free to pick the one that best meets their needs.
Active Directory's most visible competitor is unquestionably NDS. Based on X.500, NDS is a powerful, flexible, and reasonably complex technology. Because it was developed several years ago, it's perhaps not quite as well integrated as it might be with DNS and LDAP, today's key directory standards. Still, NDS has legions of loyal fans, and it has bee
n an effective selling point for Novell in marketing NetWare 4. It will be hard to argue that Active Directory is technically superior to NDS, so expect Microsoft to promote Active Directory's relative simplicity and conformance with standards in the company's attempt to counter what has been one of NetWare's greatest strengths.
Distributed Objects
Besides finding systems and people, Active Directory contains a class store that acts as a distributed version of the Windows Registry: Applications can use Active Directory to find the code for objects anywhere on a network. That capability implies that you can write applications that can exist on systems other than those from which they were called. Beginning with NT 4.0, Microsoft extended COM to work over networks, calling the result DCOM.
COM defines a standard way for one piece of software to provide services to another, regardless of what language either is written in. A COM object lets a client access its methods through inter
faces, each of which contains one or more methods. Client software using this object can acquire individual pointers to each interface and invoke that interface's methods.
COM itself lets a client remain unaware of whether the object it's using is implemented in a dynamically linked library or in another process on the same machine. DCOM extends that simplicity to COM objects running on other machines. When a client invokes a method on a remote object, DCOM locates the object on the network and issues an RPC to the destination system. The remote object's location can be supplied by the client, stored in the client's registry, or, in NT 5.0, looked up using Active Directory. Both the client and the remote object can behave just as in the local case. In fact, you can use the same code in both situations.
DCOM relies on Microsoft's implementation of the Remote Procedure Call protocol defined by the Open Group's Distributed Computing Environment (DCE). Renamed as Microsoft RPC, it has become commonly
used in Windows and NT applications (although DCE itself is not especially popular). And because it ships with every copy of those OSes, it is almost certainly the most widely available RPC protocol today. Microsoft refers to the DCOM variation as Object RPC (ORPC), but the packets on the wire conform almost exactly to the original DCE specs.
Another plus for DCOM is integration with the Microsoft Transaction Server. MTS applications must be written as COM objects. For now, at least, direct remote access to those objects is possible only via DCOM. Because MTS applications must be COM objects (Microsoft calls them ActiveX components), independent software vendors (ISVs) can create applications that conform to the MTS standards and let users combine them to build complete solutions. The result of this is likely to be a server-side component market that's analogous to the market for ActiveX client-side components that exists today. No other transaction server has been able to do this, although several ven
dors, including IBM and Oracle, are about to make the attempt.
DCOM has been shipping since mid-1996 as a standard part of NT 4.0. A version for Windows 95 was released in January, and versions for other OSes are on the way. Software AG is the primary source for them. The company expects to release DCOM for Solaris, HP-UX, Linux, MVS, and several other OSes by the end of the year. Once this happens, DCOM will no longer be of interest solely to the Windows/NT community. (For more information on DCOM, see the Special Report in the April BYTE.)
However, DCE RPC (aka DCOM's ORPC) isn't the only multivendor standard protocol for invoking remote methods. As part of the Common Object Request Broker Architecture (CORBA), the Object Management Group (OMG) has defined an alternative called IIOP. IIOP is a little more than an RPC protocol -- it also provides a redirection facility to let clients learn about objects that have moved -- but it addresses the same basic problem as DCOM's ORPC. (OMG considered ado
pting DCE RPC as its required protocol, but after a bitter fight, it chose instead to create IIOP.)
According to Andrew Watson, who is OMG's architecture director, "OMG's CORBA and the rest of the Object Management Architecture (OMA) are supported by more vendors and implemented on more platforms than any other middleware design, DCOM/ActiveX included. OMG specifications have always been publicly available and were designed from the start to be platform-neutral, programming-language-neutral, and to support distribution, rather than having these features added piecemeal."
While diversity in directory and security services can be painful, diversity in RPC protocols isn't as bad. IIOP is sure to get some use. Netscape has adopted IIOP as its standard protocol for invoking remote methods and will ship it with every copy of Navigator. But the anti-Microsoft forces aren't united behind a single competitor to DCOM's ORPC. For communication between Java objects, Sun is shipping as part of the Java environ
ment an alternative protocol known as Remote Method Invocation (RMI).
Which of these will get the most use remains to be seen, but Microsoft is the most likely beneficiary of the competition between them. Also, the company's ability to include its protocol in two hugely popular OSes confers some advantage. Microsoft joined with a multivendor standard -- DCE RPC -- is a powerful force, even when pitted against another multivendor standard.
Security Services
A directory service lets you find what you need, and a communications protocol lets you interact with it. However, not everybody should be able to find or interact with everything in the network. Controlling access is the job of distributed security services, and NT 5.0 brings new tools here, as well.
Effective
distributed security
has several aspects. First, and probably most important, it needs an authentication mechanism, allowing, say, a client to prove its identity to a server. Next, the client
supplies authorization information that the server uses to determine what access rights that client has. It also needs data integrity. A cryptographic checksum included with all transmitted data lets the receiver of that data detect any changes made by attackers while it was in transit. For true paranoids (and those with CPU cycles to burn), data privacy can be accomplished by encrypting all transmitted data.
As with directory protocols, Microsoft has chosen to adopt the leading industry standards for distributed security rather than pursue a proprietary path. NT has supported the Secure Sockets Layer (SSL) for some time (along with its "enhanced" SSL, called Private Communications Technology, or PCT). However, the infrastructure required for public-key-based security such as SSL isn't completely in place. Furthermore, public-key encryption can be slow for some kinds of applications.
For those reasons, within the local NT world today, the primary protocol used for distributed security is NT LAN Ma
nager (NTLM). NTLM is a reasonable security protocol for a single domain, providing authentication, data integrity, and data privacy. It's not perfect, however, nor is it popular outside the Microsoft environment.
Instead of enhancing and promoting its existing protocol, Microsoft is about to relegate NTLM to legacy status. As part of NT 5.0, Microsoft will begin shipping an implementation of MIT's Kerberos. Kerberos provides authentication, data integrity, and data privacy, but it also offers features that aren't in NTLM. For example, in NTLM, only clients can prove their identity to servers, which means that clients must trust that servers are whom they claim to be. Kerberos, on the other hand, offers mutual authentication, letting both parties verify the identity of the other.
Microsoft's Kerberos is a standard implementation of Kerberos Version 5. Each domain has its own Kerberos server, which in Microsoft's implementation shares the database used by Active Directory. Consequently, the Kerbero
s server must execute on the domain-controller machine, and like Active Directory servers, it can be replicated within a domain.
Every user who wishes to securely access remote services must log in to a Kerberos server. A successful log-in returns a ticket-granting ticket (TGT) to the user, which can then be handed back to the Kerberos server to request tickets to specific applications servers.
If the Kerberos server determines that a user is presenting a valid TGT, it returns the requested ticket to the user, with no questions asked. The user sends this ticket to the remote applications server, which can examine it to verify the user's identity (i.e., to authenticate the user). All these tickets are encrypted in various ways, and various keys are used to perform that encryption. Providing distributed security is not a simple thing. Thus, Kerberos is reasonably complicated.
Microsoft choosing to promote nothing but standard security protocols seems almost too good to be true -- and, unfortun
ately, it is. Even though Microsoft will implement the standard Kerberos 5 protocol, that protocol does not define exactly what should be sent to identify the client. Different implementations of Kerberos send different authorization information. Not surprisingly, the Microsoft version will send NT-specific security identifiers. This means that full interoperability with other Kerberos implementations will be problematic. It's hard to see what a better path might be, however, because there is no widely accepted multivendor standard to follow in this area.
NT Everywhere?
There are two main conclusions that users can draw from the forthcoming enhancements to NT. First, Microsoft is doing its level best to make NT function effectively in a distributed environment. Although we'll need to wait for the code to ship to see how well it has succeeded, adding serious directory and security services will fix a long-standing concern with the OS. Second, by choosing to implement standard protocols
for distributed services, Microsoft is trying to let NT fit well into a multivendor environment, one that includes Unix, Macs, and even mainframes.
The scene isn't perfect. Problems with directory replication, Kerberos authorization information, and perhaps other yet undiscovered areas still exist. Nevertheless, by buying almost completely into multivendor middleware standards, Microsoft has made clear what the future will look like in this long-contested area. No other company has the power to create a proprietary middleware solution with even a chance of becoming a widely used standard. Somewhat surprisingly, Microsoft has chosen not to do this. By embracing standards, Microsoft has guaranteed their adoption.
Where to Find
Microsoft Corp.
Redmond, WA
Phone: 800-426-9400
Phone: 206-882-8080
Fax: 206-936-7329
Internet:
http://www.microsoft.com
NT 5.0 in the Enterprise
