More About the Directory and Security Server
Installation Planning Scenarios
One of the key design points for the Directory and Security Server was to ensure that existing OS/2 LAN Server and OS/2 WARP Server installations can be migrated at the customer's pace. For this reason, it is possible to migrate existing OS/2 LAN Server and OS/2 WARP Server domains to a DSS cell by simply installing DSS on top of OS/2 WARP Server, or OS/2 LAN Server plus OS/2 WARP, on each domain controller that is to be migrated. Clients and additional servers remain unchanged, although it is necessary to install at least one DSS integrated client for administration. This configuration results in the following benefits:
If DSS is installed on additional servers as well as the domain controllers, then DCE ACLs are used on the additional servers. The additional servers are no longer subject to the OS/2 LAN Server group limits. Also, the additional servers use DCE directory and security services directly so there is no need for DSS to synchronize the DCE and OS/2 LAN Server registries, resulting in less network traffic. In addition, they can make their resources available across cell boundaries.
The Directory and Security Server allows customers to migrate OS/2 LAN Server and OS/2 WARP Server installations in the manner that works best for each individual customer situation. All of the domain controllers can be migrated at once, with additional servers migrated later as needed, or all of the servers in a domain, both the domain controller and the additional servers, can be upgraded when the domain is migrated to a DSS cell. Similarly, existing OS/2 LAN Server and OS/2 WARP Server clients can be used indefinitely or they can be migrated to OS/2 integrated clients.
In any discussion of the Directory and Security Server, it is helpful to understand how the DSS servers are related.
The directory servers use the security server's authentication service to prove to each other that they are indeed valid servers rather than imposters attempting to mine information from the directory database. They use the security service's Access Control List (ACL) facility to restrict directory server administration to only those userids that have been registered as administrators. Entries in the directory server database are time stamped using the facilities provided by the time server.
The DSS domain controller uses the directory server to locate objects, both in the home cell and in other cells. It also stores the DSS resource domain information in the directory server's database. The DSS domain controller also uses the directory server to obtain resource information for propagation to unchanged additional servers via the OS/2 LAN Server DCDB file.
The time server registers itself as an object in the directory database and uses the directory server to find other time servers in the network. It uses the security service to ensure that it is communicating with a valid time server rather than an imposter.
The DSS domain controller uses the time server to set the system time on all domain controllers and additional servers in the network.
The security server registers itself with the directory server as an object in the directory database. The security service uses the time synchronized by the time service to ensure that passwords and the service tickets that allow clients to use Directory and Security Server services are properly time stamped and voided when they expire.
The DSS domain controller uses the security server to authenticate unchanged OS/2 LAN Server clients and servers. In addition, the DSS domain controller uses the security server to obtain security information for propagation to unchanged additional servers via the NET.ACC file. The integrated client uses the security server for authentication and to obtain permission to use Directory and Security Server services.
The directory server, sometimes called the cell directory service (CDS) is used by the DSS services to locate objects in the network. It stores information about objects such as domain controllers, additional servers, printers and file system directories, in a common database that represents a common cell name space. (A name space is simply the total collection of names shared by the DSS directory servers and other DCE directory servers.) This frees users from knowing the real location of these objects. Clients can transparently access these objects (also known as resources) in their local resource domain or any other resource domain in the cell without knowing or caring about the real physical location of the objects.
The database in which the name space is stored is known as a clearinghouse. Clearinghouses contain replicas, which are just physical copies of the database or of portions of the database. One of the powerful features of the Directory and Security Server is that the directory database can be replicated on several directory servers throughout the network. This allows remote sites, (for example, branch offices), to maintain a local copy of the directory to improve performance and to ensure that the directory is available even when the communication line to the master directory server is down. Another powerful directory feature is the ability to partition the directory database so that servers need only manage that portion of the database that is most relevant to the local clients.
The basic role of the security server is to allow DSS clients and servers to prove their identity. The security server includes several services:
Like the directory server, the security server supports the use of replicas for performance enhancement and fault tolerance.
Note: For more information on DSS security, see IBM Directory and Security Server for OS&slash.2; WARP Security by Lee Terrell and Wayne Sigler.
The components of the Directory and Security Server are administered using a graphical user interface (GUI), which runs on the DSS integrated client. This administration GUI can be used to administer existing OS/2 LAN Server or OS/2 WARP Server domains, IBM and non-IBM DCE cells, and DSS cells. There is also a DCE-only GUI, which is a subset of the DSS administration GUI and that runs on a DCE client. Most administration functions can be performed remotely.
The basic scope of administration in the Directory and Security Server is the cell. Users are defined at the cell level rather than at the domain level, as is done in OS/2 LAN Server and OS/2 WARP Server. Cells can include many users and resources and can span many geographical sites. They can consist of existing OS/2 LAN Server and OS/2 WARP Server clients and servers, DSS integrated clients, and domain controllers and additional servers, that have been upgraded to DSS. In these mixed environments, the existing clients and servers use a protocol that does not recognize the DCE directory and security services. They use the existing OS/2 LAN Server protocols and understand the existing OS/2 LAN Server security and directory structures. For this reason, DSS synchronizes the DCE directory and security databases with the OS/2 LAN Server directory and security databases. This is accomplished with two DSS functions: registry synchronization and directory synchronization. Registry synchronization is the act of ensuring that all updates to the Directory and Security Server registry database are propagated to the NET.ACC file on the domain controller. Directory synchronization ensures that changes to the Directory and Security Server directory database are reflected in the domain control database.
In order to reduce the traffic on the network, synchronization is done on a resource domain boundary. Synchronization may be enabled or disabled, on an individual basis, for each resource domain in the cell. It is enabled by default when the resource domain is created. When synchronization is enabled for a resource domain, changes to the registry database for users and groups in that resource domain can be reflected in changes to the NET.ACC file on the domain controller for that resource domain and changes to the directory database for resources in that resource domain, can be propagated to the DCDB on that resource domain's domain controller.
Resource domains allow a level of granularity in administration that is not possible with OS/2 LAN Server and OS/2 WARP Server domains. They can have a hierarchical administration relationship. A company might have one resource domain for each branch office and each of those resource domains might be children of a resource domain for the entire company. In this case it would be possible for the administrator of the entire company resource domain to administer the resource domains in any branch office, but the branch office resource domain administrators could only administer their own resource domains. This makes it possible to put boundaries on the resources that a given administrator can control, even though all of the resources are in a single cell.
Several types of clients can be used with the Directory and Security Server. Existing OS/2 LAN Server and OS/2 WARP Server clients can be used unchanged. These clients are capable of accessing resources anywhere in the DSS cell using a single userid and password. In addition, they can continue to be used to access resources on OS/2 LAN Server and OS/2 WARP Server domains that are not part of the DSS cell. The Directory and Security Server strengthens the control of the administrator with respect to existing clients. In a DSS cell some of the administration functions that could be performed from existing clients must now be performed from a DSS integrated client. This is done so that DCE security can be used end-to-end on the client that performs the administration.
DSS integrated clients can access not only DSS domain controllers and additional servers, but also additional servers and domain controllers in existing OS/2 LAN Server and OS/2 WARP Server domains. They can also access unchanged additional servers in the DSS cell. In addition, they can be used to do distributed processing with any OSF DCE-compliant application and seamlessly access DSS resources across cell boundaries.
DSS directory, security and time servers can also be used to provide services for any OSF DCE-compliant clients.
One of the advantages of DCE, and of using DCE directory and security services with OS/2 LAN Server, is that DCE is designed from the ground up to work in a distributed, heterogeneous environment over both LANs and WANs. This presents many options for tuning the network for a wide variety of requirements. This section is not meant to be a tuning guide but rather is intended to highlight some of the tuneable features of the Directory and Security Server.
Although all of the server components of Directory and Security Server can be installed on a single machine, it is not necessary to do so. Suppose, for example, that we have a campus environment with many departments sharing several geographically close buildings. Today these are served by five LAN domains averaging 800 users per domain, and we want to migrate them to the Directory and Security Server. We could simply install DSS on each domain controller, installing the same components (OS/2 LAN Server integration, directory server and security server) on each domain controller. However, a single DSS cell can comfortably support 4000 users with fewer than five directory and security servers. We could save considerable space on the domain controllers by simply installing the directory and/or security server on a single machine (this machine does not have to be one of the domain controllers, but could be), and only installing the OS/2 LAN Server integration features on the other domain controllers. If we add users over time and reach a point where performance has degraded, we can simply add one or two replicas of the security and/or directory server as needed. Again, they can be placed on the domain controllers or any other machine in the network that meets the hardware and software prerequisite. Because DCE uses a fair use algorithm, the load is automatically balanced between the master and replicas.
If we have a branch office environment, where the branches are connected using a TCP/IP network with a router in each branch, we can put a directory server in each branch or we can just put one in those branches that are connected via slow lines. Even though DCE uses a fair use algorithm for load balancing, we can take advantage of the fact that it tries to avoid crossing router boundaries when performing directory operations. This causes DSS to look at the directory server(s) on the local subnet first. The directory operation only looks outside the local subnet if it cannot find a server on the local subnet with the desired information.
Directory information is also cached at the client. It is possible for DCE applications to specify whether the local client cache should be used to look for information. In this way, the programmer can make the trade off between the fast performance obtained by use of the local cache and the increased security obtained by forcing the client to access the server when information is required. Accessing the server every time data is fetched also ensures that the latest copy of the data is used.
In addition to using directory replicas, it is also possible to use registry replicas. This distributes the security operations across several servers, which increases capacity and decreases response time.
In summary, while it is not necessary to tune Directory and Security Server for small installations, when large networks are installed, Directory and Security Server offers many opportunities to tune the network to match the needs of each organization.
The toolkit allows the development of applications in either a "pure" DCE environment or in a DSS environment using both DCE APIs and DSS enhancements and modifications to OS/2 LAN Server APIs. The DCE portion of the toolkit contains all the standard DCE development tools, including the Interface Definition Language (IDL) compiler and the Symbols and Message Strings (SAMS) compiler. It also includes the online programming documentation and a wealth of example programs. The header files included with the DCE portion of the toolkit use standard DCE long file names in order to maximize portability. For this reason, DCE application development must be done on a machine using the high performance file system (HPFS). Applications can run on either HPFS or FAT systems. The toolkit does not include a DCE client. In order to develop and test DCE applications programs, the programmer must install a DCE client from the Directory and Security Server package.
Although the DSS toolkit contains all of the OSF DCE development tools, it also contains enhancements that make it easier to create DCE applications that are intended to run only on DSS. The most significant of these is the Managed Object Class Library (MOCL), which abstracts many of the common DCE management API functions, such as creating a server instance, into an Object-Oriented library that can be used by both object-oriented programs and more conventional C programs. Use of the MOCL rather than the analogous DCE APIs can significantly reduce the work effort required to write programs that provide DCE management functions.
The DSS toolkit also includes a full set of OS/2 LAN Server application development tools. The design philosophy for the OS/2 LAN Server integration function of DSS has been to change the OS/2 LAN Server APIs as little as possible in order to avoid breakage of existing applications. Most of the changes to the OS/2 LAN Server APIs have been done by mapping existing APIs to the appropriate DCE functions necessary to use DCE directory and security services, thereby making the changes transparent to existing applications. In some cases, however, it is necessary to let DCE directory names, etc., show through the OS/2 LAN Server API. Where possible, this has been done by using parameters that were formerly reserved or by adding new information levels to existing APIs.
In general, the API changes for DSS are limited to these sets of APIs: Access, Alias, Application, Group, Requester, Server, User and User Profile Management. The following is a list of some of the changes:
Like the DCE portion of the toolkit, the OS/2 LAN Server integration application development tools include header files and sample programs. All of the OS/2 LAN Server header files use short file names, so development can be done on FAT systems.
The first step in planning your Directory and Security Server installation is to decide on the number of cells you will need. Cells are logical units of administration that can contain from 2 to thousands of users and the servers needed to support them. They can span many network segments and can include both LANs and WANs. Cells are not restricted by geographic boundaries so they can be defined to include all floors of a building or multiple branch offices spread throughout the world.
There are many factors to consider when deciding how many cells to use and what users and resources to include in them. One set of factors to consider is the set of business needs of your company. If your company has multiple divisions or lines of business that are completely isolated from each other and have no need to share data, then it may be best to create a cell for each of those divisions. On the other hand, if most or many of the people in your company need to share data with each other, then it may be more useful to create a single cell for the entire company. You should also consider the way in which administrators are distributed throughout your company. If you have a great deal of administrative expertise in each major LAN site in your company today, it may make sense for you to use more than one cell. If you want to have administration done at regional sites or the headquarters site, then it may be more efficient for you to use a single DSS cell. This is especially true if you have a multi-tiered company with varying degrees of administrative expertise at each level of the corporation.
Directory and Security Server cells are compliant with the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE) version 1.1. DSS security and directory servers can be used to provide security and directory services for any OSF DCE client. Companies that have made the decision to use DCE as the strategic company infrastructure may choose to run other DCE 1.1-compliant applications in their cells in addition to DSS. If this is the case in your company, or if you may encounter this situation in the future, you should take this into consideration when planning the number of DSS cells to use. One of the things to consider with respect to other DCE applications in DSS cells is the fact that DCE is designed to favor operations within a single cell. That means that, if a set of users must frequently access both LAN Server resources and other DCE applications or resources, the best performance will probably be achieved by including those DCE applications and resources in the DSS cell. This is the best model as long as the cell servers are geographically separate from each other. If all of the cell servers are in one site (for example, in a single room) and a physical disaster (fire, flood, etc.) should occur that wiped out all of the cell servers, then all applications would be unavailable. The only way to avoid this situation is to distribute the cell servers to geographically separate areas or to use multiple cells that are geographically distributed.
Another point to consider when deciding how many cells to use is that each cell must have at least one directory server and one security server. For this reason, using multiple cells increases the amount of administration that must be done, especially if the cells are small and would normally require only one or two security and directory servers per cell.
If your Directory and Security Server installation includes existing OS/2 LAN Server servers and clients that will not be upgraded to use DSS directly, then there are other factors to consider when deciding how many cells to use. Existing OS/2 LAN Server clients can seamlessly access resources across domains within a single DSS cell. However, they cannot seamlessly access resources across DSS cells. You must use a DSS integrated client to seamlessly access resources across cells. In addition, unchanged existing OS/2 LAN Server additional servers that are part of a DSS cell, cannot make their resources available to clients in other cells. If you are migrating your installation to DSS and must intermix unchanged OS/2 LAN Server clients and servers with DSS clients and servers that have been upgraded with DSS, then you should use a single cell for all clients that must access a set of resources and all servers that contain them. If it is necessary to partition the administration of these resources, this can be accomplished by using Directory and Security Server resource domains.
The following are a few examples that might make it easier to determine how many Directory and Security Server cells to use for your company.
The Widget Stamping manufacturing area in the second city has 500 employees and two LANs, one in the manufacturing area and one in shipping and receiving. The two sites are connected via a TCP/IP connection over a T1 line. Administration of the LANs at the manufacturing only site is done by one person on a part-time basis. There is one full-time and one part-time administrator at the home office site. Directory and Security Server will be used to tie all of the LANs together for the purposes of consolidating administration and allowing some cross-domain resource access.
This situation calls for a single cell. Using one cell allows the administrators at the home office to administer users, groups and resources at both sites from a single location. In addition, Directory and Security Server resource domains can be used to restrict resource access to only those employees who have a business need to access those resource, while at the same time allowing cross-domain and cross-site sharing of data and other resources for employees with a need to do so.
A single Directory and Security Server cell will be used for this bank, with Directory and Security Server resource domains used to restrict branch employees access to only the data and resources in their branch and selected resources and data at the central site. Administrators at the central site will be able to access and administer the branch resource domains directly from the central site. Those employees with a business need to do so will be able to access data and resources at any branch.
This is a case where multiple cells is probably the best answer. Although there are no architectural reasons why 30,000 users could not be placed into a single Directory and Security Server cell, hardware limitations and administration complexity will combine to make that impractical. Deciding how many cells should be used requires a detailed analysis of the data and resource sharing needs in the corporation. In this instance, it may be most practical to define a cell for each regional office and the branches it serves. This allows Directory and Security Server resource domains to be used to restrict branch office personnel to only those resources that they have a business need to access. At the same time, it allows hierarchical administration of large branch offices and direct administration of smaller branch offices from the regional offices. Depending upon the number of users and resources in the claims offices and their need to share data between offices, it is probably most practical to use a single cell for all of the claims offices. Again, resource domains can be used to restrict access for those employees who have no need to access data or resources across office or domain boundaries. The central site should probably be a separate cell. Directory and Security Server integrated clients can be used to access resources across cell boundaries when necessary. These would be needed mostly in the central site with a few in the region and claims offices also. Most branches would not need to access resources across cells and could use unchanged OS/2 LAN Server clients.
IBM currently supports DCE as a strategic infrastructure. IBM is a charter member of OSF and a member of the OSF DCE 1.2 Project Steering Committee. In that role, IBM has worked with the other OSF members to enhance DCE and make it the premier infrastructure for network centric computing. DCE is a core architecture in the company's Open Blueprint strategy and has been implemented on IBM mainframe, mini-computer, workstation and PC platforms. The Open Blueprint states IBM's current direction with respect to DCE: to tie together all of IBM's major operating system platforms and resource managers using the common DCE directory and security services. The objectives of this strategy are twofold: to allow an end-user to access all of the resources to which he has been authorized in a single login, and to ease the administration burden through the use of a single user definition. The Directory and Security Server OS/2 LAN Server integration function is the first step in realizing this goal. Over time, IBM intends to deliver this level of integration between DCE and all of its major resource managers.
The IBM Directory and Security Server for OS/2 WARP delivers a powerful set of distributed computing services that help large and small enterprises move to a distributed, network centric computing environment. These services can be used to install a "pure" DCE network on OS/2 WARP, which can interoperate with OSF DCE-compliant components on a variety of platforms including mainframes, mini-computers, workstations and PCs. DSS also extends OS/2 LAN Server from the workgroup to a distributed environment using DCE's powerful directory and security services. The OS/2 LAN Server integration is accomplished by add on function that installs on top of OS/2 WARP Server and OS/2 LAN Server 4.0 plus OS/2 WARP.
DSS allows older OS/2 LAN Server clients to take advantage of DCE services with no changes to the clients. These older clients use a protocol that is not aware of DCE. Because of this, and because the Directory and Security Server delivers an environment with a single user definition and single-signon, which strengthens the administrative control of existing OS/2 LAN Server networks, existing OS/2 LAN Server and OS/2 WARP Server clients cannot be used to administer DSS networks. The amount of administration that can be performed by existing clients depends upon the level of the client. OS/2 LAN Server 3.x clients can only change their own password. OS/2 LAN Server 4.x and OS/2 WARP Server clients can also administer their own logon assignments, private applications and application selector lists. All other administration must be done by a DSS integrated client.
DSS also changes some of the OS/2 LAN Server APIs. For the most part, these changes involve new information levels and extend the use of existing parameters on existing OS/2 LAN Server APIs. In the case of ACLs on servers upon which DSS has been installed, it is necessary to use DCE APIs to administer the ACLs via a program.
DSS delivers an implementation of OSF DCE 1.1 on OS/2 WARP that is interoperable with any other OSF DCE-compatible implementation of DCE on any platform, using supported transport protocols. All of the OSF DCE 1.1 function is available, including extended registry attributes for easy integration with existing client-server applications. DCE's powerful directory and security services, industry-standard remote procedure call and DFS client are all available in the IBM Directory and Security Server for OS/2 WARP. In addition, DSS adds a graphical user interface administration tool, which allows DCE to be administered with the same ease as that provided by the award-winning OS/2 LAN Server 4.0 administration GUI.
DSS extends the reach of OS/2 LAN Server into the distributed networking environment, allowing OS/2 LAN Server users on unchanged, existing clients to access remote servers anywhere in the DSS cell via the powerful DCE directory services. Using a single identity and a single signon, OS/2 LAN Server users on existing clients can access resources on any domain in the cell without the need to keep userids and passwords in sync across multiple domains. Users of DSS integrated clients can seamlessly access resources in any cell using end-to-end Kerberos security. The workload of OS/2 LAN Server administrators is reduced because they only have to administer a single identity for each user rather than an identity in each domain. It is not necessary for the administrator to set up a trust relationship between domains in order for a user at an existing OS/2 LAN Server client to access resources in another domain in the cell.
The IBM Directory and Security Server for OS/2 WARP is the first product to implement IBM's Open Blueprint strategy. It is a large step on the way toward network centric computing. Notices
Disclaimer
The information contained in this document is for informational purposes only and represents the current view of IBM Corporation on the products and information discussed at the date of publication. IBM expressly reserves the right to change or withdraw current products or features described in this document. This document could include technical inaccuracies or typographical errors for which IBM is not responsible.
The following paragraph does not apply to the United Kingdom or any country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSES. Some states do not allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you.
NOTE TO U.S. GOVERNMENT USERS: Documentation and programs related to restricted rights - Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule contract with IBM Corp.
IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Commercial Relations, IBM Corporation, Purchase, NY 10577.
The following terms are trademarks of the IBM Corporation in the United States or other countries or both:
Windows is a trademark of Microsoft Corporation.
Other company, product, and service names, which may be denoted by a double asterisk (**), may be trademarks or service marks of others.
(1) OS/2 WARP Server consists of OS/2 WARP operating system, plus IBM and other separate networking products.