 |
|
|
Directory Services & The Internet A common cry from the confused user these days goes something like: "how do I access the internal Web server in the marketing department?" "Easy", replies the beleaguered administrator, "just point your Web browser at dilbert.marketing.UK.NSS.com" "Oh, very obvious! How was I supposed to guess that one? And while we’re at it, how can I get a listing of all the users in the UK Marketing group?" "Er…. you can’t. At least, not very easily" From this point onwards, the conversation goes rapidly downhill, and parts of it certainly aren’t printable. It gets even worse ten minutes later when the user phones up to say that he cannot access any of the information on "Dilbert", and the administrator has to create yet another user account on yet another server, even though that particular user is already defined several times in various systems. This is a common enough scenario in today’s Internet/intranet type of environment. What the user requires is a simple means of looking up names and addresses of various network resources, including servers, printers and, of course, other users. What the administrator requires is a simple means of defining all these resource to the network, and preferably storing them in a single, central location. What both of them require is a directory service. The Role of Standards in Directory Services Naming problems have always been with us, of course - just ask anyone who has implemented a TCP/IP network. The simplest way - at least at the outset - is to use the HOSTS file. This is a text-based file which can be found on most TCP/IP systems, and which contains a simple list of IP addresses and the names that relate to them (see box). This file can name common systems both inside and outside an organisation, and each address can have several names, usually a "formal" name followed by a number of less formal "nicknames" or aliases. Hence, in our sample HOSTS file, the marketing server can be referred to by its IP address of 10.1.1.2, its full name of dilbert.marketing.UK.NSS.com, or by its shortened aliases of Dilbert or Marketing. Whilst the use of HOSTS files is possible in smaller networks, they can have serious drawbacks in larger ones. The main problem is that a copy of the file must exist on each and every TCP/IP client which intends to refer to resources by name rather than IP address. This approach is obviously not very scaleable, and presents systems administrators with a potential nightmare in a network with hundreds or thousands of clients. Ensuring each and every HOSTS file is always completely up-to-date as network changes are made is bad enough, but there is also the temptation for users to create their own files with customised naming conventions, making it difficult for "hot desking" colleagues. Of course, it is possible to manage HOSTS files by keeping a master version on one of the central servers, and downloading it to clients automatically on a regular basis - but this approach, too, can have its problems in large distributed networks. Domain Name Service (DNS) Obviously, such solutions will not scale in large organisations, and certainly will not scale to the Internet. The problem of Internet naming has been largely satisfied to date by something called the Domain Name Service (DNS), which allows a computer that is registered to the Internet to be uniquely identified by that name wherever it may be located. Because computers work with numbers rather than names, the second major function of DNS is to translate the unique host name into the appropriate IP address required to establish communications. While these are the main functions of the DNS, it can also be put to more general use. For instance, the standard also allows the DNS to identify the types of applications that are available on a particular machine - such as Telnet or FTP - to identify gateways to networks and to show which machines are capable of mail relay and to which network. These are some of the functions required from a more general directory service. The use of DNS is certainly mandatory in some form if you wish to participate in the Internet. However, a good naming scheme coupled with the implementation of DNS servers can also make life considerably easier for users of a large corporate TCP/IP network. DNS provides for central control over names and IP addresses and removes the need for individual HOSTS files (although these can co-exist quite happily where required). It allows control to be applied both in a distributed fashion, and where it can be most effective in local sites and divisions. The domain name protocol is quite complex syntactically, although its operation is straightforward. A host, given a name, asks the server for a name-to-address translation. If the name server does not possess the means to perform that translation directly, it will pass the request on to a server with a higher authority than itself. This process can be repeated until the request is satisfied, which will always happen unless the requested address was incorrectly specified or there is some unforeseen problem (such as a DNS server being temporarily unavailable). The configuration for the basic operation of a domain name server can be quite awkward in all but the simplest of configurations, making it unattractive for use in smaller networks. However, once the core of information is in place it scales well, and adding extra nodes into the database is easy. In a large network, the use of DNS instead of local HOSTS files makes it easier to manage addressees and to achieve consistency across a large user population. It also allows changes to be administered centrally. X.500 Underpinning the concept of a global naming structure is one very important set of OSI standards - X.500 - that describe the interconnection of differing information systems as developed by the CCITT (ITU) in their 1988 and 1992 version of the X.500 specifications. But X.500 goes beyond simple naming, and into the realms of the true directory service. A directory service is simply a database of objects, representing everything on your network, that helps manage relationships between people and networks, network devices, network applications, and information on the network. These managed relationships identify whether a person or object can be authenticated to the network and the access allowed to other network objects and information. The bigger networks get (like the Internet) and the more people and resources you need to locate and access, the greater the need for directories and standard methods of accessing directories. Central to X.500 is the concept of the global, distributed directory based on hierarchically named information objects (directory entries) that users can browse and search. The information about the objects in the directory is collectively stored in the Directory Information Base (DIB), which acts as an interface between the directory users and the processes providing directory services. To facilitate scaling and replication, portions of the DIB can be held on multiple Directory Servers (DSA’s). Users can attach to any DSA and query objects anywhere in the global directory without having to know the precise location of the requested information. Genuine distributed directories need both an advanced model and three protocols (user to server, server to server, and server replication). Simplifying the model, we can divide X.500 into two requirements: one that defines the directory structure and the other that defines directory access. The X.500 directory structure outlines the logical directory object schema and how the schema is held, as well as each object’s attributes and how objects relate to one another. Directory access refers to how these objects can be queried, and replicated with other X.500 directory systems. The three protocols defined to cope with these requirements are as follows:
Security mechanisms have also been defined to protect the information in the directory and restrict user access to it (i.e. to prevent users seeing or modifying restricted information). In combination with strong authentication using public/private key technology and digital signatures (defined in the X.500 standards) this provides an extremely flexible and secure method for data protection . Basing a directory service on X.500 therefore makes it secure, whilst covering key management requirements such as centralised administration, performance and fault tolerance. Such directories are not only suitable for large-scale Internet use, but also for corporate enterprise right down to single e-mail directories. To make your intranet user friendly, for example, you could implement white pages so users can easily look up E-mail addresses, certificate servers so people can find public encryption keys, yellow pages allowing them to locate other users, organisations and resources by type or function, and a whole raft of other services that will provide an infrastructure that fully supports commercial use. LDAP Unfortunately, the DAP protocol as defined in the X.500 specifications has a significant overhead, resulting in a distinct lack of full DAP clients and applications. A team from the University of Michigan worked at reducing the overhead associated with DAP, allowing them to retrieve the same X.500 directory information, but more rapidly and with smaller clients. They named this new protocol specification the Lightweight Directory Access Protocol (LDAP), and this is quickly becoming the standard for clients on both the Internet and intranets to access directory information. LDAP v2 is defined in RFC 1777, and version 3 - which defines a number of improvements to enable client access to the server to be more efficiently implemented and more suitable for the Internet model - is currently a draft RFC undergoing preparation and review by the IETF. Having garnered huge support from major vendors such as Netscape, Novell, IBM, Lotus, Banyan and even Microsoft, LDAP is now being positioned as the standard capable of providing open access to directory services on the Internet, as well as integrating directories and making a truly global directory service a reality. The aim is to let users quickly and easily access directories of people and information such as user names, e-mail addresses, and telephone numbers. For instance, using an LDAP client it would be possible to search for the user name "Bob Walder" and retrieve the e-mail address and perhaps the telephone number. It would also be possible to search all entries directly below the "c=UK" object which have the word "PLC" in their name and a fax number property, in order to produce a fax number listing. It is important to realise that LDAP does not do away with X.500, but is rather an X.500 access mechanism, designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). It does not, however, have to make use of any of the X.500 protocols directly, which allows it to map onto any other X.500-compliant directory service. LDAP itself is specifically targeted at management applications and browser applications that provide read/write interactive access to directories, providing a simple means to query data from any directory which uses the X.500 data and service model. LDAP, in it's current state (version 2), is best used as a protocol for client to directory information access. As it matures, however, it will become a directory to directory protocol. There are moves afoot to disassociate LDAP from X.500, since it is perceived that the association with the unfashionable OSI standard is likely to harm LDAP in the long term. However, in doing this there is a real danger that LDAP may end up re-inventing the wheel if it grows into providing more that just an access protocol. The X.500 standards provide a solid, proven blueprint for a global distributed directory, and it could prove unwise to simply ditch them in favour of a new de facto "standard". The Corporate Environment Although some recent claims position LDAP as the only protocol needed to provide a global directory service, it is important to realise that is can only ever provide part of the picture. Behind LDAP, which is not sufficient in itself to define a complete directory standard, you still require a full X.500-like directory. Of course, it is one thing to talk idealistically of standards, but quite another to actually implement directory services within an organisation. However, it is important to understand that the X.500 recommendations do not describe a readily available application. X.500 is simply a definition of services and data, whilst the application development forming the user interface and the system code is left to the computer industry. As usual, such specifications are open to a certain degree of interpretation, and are capable of being implemented partially, allowing vendors to claim their products are "X.500-like" or "X.500-ready". Most of the current Network Operating System (NOS) vendors are heading towards full X.500 compliance, a key requirement for the interoperability required if we are to realise the Holy Grail of a true global directory across the Internet. Banyan Vines was the first widely available NOS to include a Directory Service - called StreetTalk - which immediately earmarked it for consideration by large organisations intent on implementing a scaleable, enterprise-wide solution. Every server in a network has a StreetTalk service which keeps track of resources and users on the server, and every resource and user is given a StreetTalk name. The naming structure is similar to X.500, but is restricted to three levels - the first part identifying the specific network item or user, the second denoting the group to which the user or items belong, and the third, the name of the organisation or company (i.e. BOB@IT@NSS). Each StreetTalk service creates and maintains a database of names that contains information about resources across the network, as well as information about resources on the individual server. These databases are automatically synchronised across the network, thus ensuring that every server always knows about every resource, effectively creating the illusion of a single enterprise-wide database which is known as StreetTalk Directory Services. Last year, Banyan and Netscape - along with more than 35 other vendors - jointly announced their commitment to LDAP. "By marrying LDAP-compliant directory services such as Switchboard and StreetTalk with the address book and other directory functions of Netscape Navigator and Netscape Directory Server software, millions of users can now look up people on the Internet as easily as looking up people within their own corporate departments," said Eric Hahn, senior vice-president of enterprise technologies at Netscape. Banyan committed to supporting the LDAP protocol across its directory and messaging product lines with the aim of allowing customers to select client and server applications from multiple vendors with the confidence that these products - including Banyan’s own StreetTalk, Switchboard, and BeyondMail - will seamlessly interoperate with other LDAP-compliant offerings. Novell introduced Novell Directory Services (NDS) quite late in the day compared to Banyan, but that didn’t stop it from quickly eclipsing StreetTalk thanks to the huge market share enjoyed by the NetWare operating system. The NDS Directory is a hierarchical affair which treats all NetWare resources - users, file servers and print servers - as objects. Not only that, but because the NDS objects are arranged as a tree (with a theoretically unlimited number of levels), the Directory is also capable of representing the organisation structure of the company within the database, with the company as a whole, its operational divisions and departments all held as objects. Although the X.500 standard forms the foundation of NDS, Novell felt that the basic X.500 objects and attributes did not scale very well in a business environment. Without object types defining resources such as computers, printers, and file servers, a directory is limited to Yellow Pages functionality. In order to introduce these new object and attribute types to NDS, Novell followed the CCITT recommendations and added them in a transparent and portable way. Novell is also committed to LDAP, and launched LDAP Services for NDS at the end of 1996. This allows an organisation to easily publish corporate information to its own intranet and to the Internet, while still maintaining control, through NDS, over who can access that information. This service provides a way to expose information stored in NDS to any LDAP enabled browser or application - using class and attribute mappings, which define the relationship between objects in LDAP and NDS - whilst implementing levels of security not implemented in the current LDAP 2 standard. But as well as acting as a door to NDS, LDAP Services for NDS is also a management tool that allows you to enhance performance of LDAP client connections and moderate LDAP access activity. All management tasks are performed through the standard Nwadmin utility. Last onto the scene is Microsoft. Next Generation Directory Services (NGDS) - due to see the light of day with the release of NT 5.0 sometime next year - will combine the Internet’s Domain Name Service (DNS) as a locator service and X.500 naming standards to provide enterprises with the interoperability they need to unify and manage multiple name spaces. As with Novell’s NDS, Active Directory allow a single point of administration for all published resources, which can include files, peripheral devices, host connections, databases, Web access, users, arbitrary other objects, services, and so forth. It incorporates the lightweight directory access protocol (LDAP) as its core protocol, allowing it to work across operating system boundaries and integrate multiple name spaces. This will allow Active Directory to subsume and manage application-specific directories, as well as other NOS-based directories, to provide a general purpose directory service. Another key part of the Microsoft strategy is Active Directory Services Interface - a component of the Windows Open Services Architecture (WOSA) Open Directory Services Interface (ODSI) - which provides a set of API’s which makes it easy for developers to "directory enable" their applications. Going forward, administrators and developers can thus deal with a single set of directory service interfaces - whether they are using Active Directory, NDS, X.500, Notes, NetWare Bindery or any other type of Directory Service for which an Active Directory interface can be developed. Summary The growth in popularity of X.500 so far can largely be attributed to the fact that it meets the needs of the users in providing universal access, definable attributes, directory manageability, a multi-part naming hierarchy and scalability. Riding on the crest of the Internet wave, the momentum behind the LDAP protocol is also a very positive move towards helping product vendors and users alike to provide powerful directory services. There is a significant X.500 following which insists that it is important that LDAP retains its focus as an access protocol and continues to be refined and improved along those lines. They argue that there is little point in reinventing the wheel at this stage, since X.500 provides everything that is required to provide a full-blown directory service. And for those worried about the overhead, it is now possible to run versions of the DSP and DISP protocols directly over TCP/IP, known as nDSP and mDISP respectively. But there is also another lobby which is pushing to divorce LDAP from its X.500 roots, promoting extensions to LDAP which sill allow it to run as a stand-alone directory service rather than a simple front-end access mechanism for X.500 directories. Of course, the pragmatists out there in the real world - those who are forced into implementing enterprise-wide directory services today - are likely to take a different view again. They are finding that it is not necessary to run true X.500 directory services at all, and both Banyan and Novell have already demonstrated how products which are merely "based on X.500" can still be attractive providing they support LDAP. By supporting LDAP as the access protocol, X.500-like products will ensure that proprietary standards do not proliferate the market. Whether or not X.500 eventually triumphs over LDAP as the directory service of choice for the Internet, the long-term benefits to end users of the proliferation of X.500-derived products will be legion. In particular, it will ensure that there will be no requirement for numerous proprietary directory backbones and gateways, whilst guaranteeing that there will be a real choice for end users which only comes with true vendor interoperability. |
Security Testing |
Send mail to webmaster
with questions or
|