Understanding and Deploying LDAP Directory Services > 22. Directory Coexistence > Determining Your Requirements |
Determining Your RequirementsThe essence of directory coexistence is synchronizing data. Now that you have an idea why directory coexistence is important, we turn our attention to the task of determining your specific directory coexistence requirements. The best method to use may vary depending on your organization and the purpose of your directory service, but any requirement gathering should cover the following areas:
You can use much of the work you began in Chapter 6 to get you started. In that chapter we showed you how to create a table of data sources and data elements within your organization. This table should show where existing data in your enterprise is located and which data elements are interesting to your directory service. Your next task is to figure out which of these data elements and sources need to coexist with the directory and which can serve as simple, one-time data sources. This process is the heart of your directory coexistence strategy. Tip You should always be suspicious of a decision to do a one-time data dump from a data source. This is a convenient way to jump-start your directory and load it with data, but often it can create problems down the road. Duplicate, uncoordinated data tends to increase your overall data maintenance costs and can lead to user frustration and confusion. On the other hand, if a data source is being phased out, taking a one-time dump of data may be the ideal approach. Be sure to think farther ahead than just populating your directory when you consider whether coexistence is needed. For those data elements that must coexist, you need to determine the mode of coexistence. The key question here is Who owns the data? Answering this question determines where the data is updated and, therefore, who is in charge of maintaining the coexistence relationships. Most data is updated in one place, but you may also have data that you'd like to be updated in multiple places. In such a case there are multiple data sources for the same data element. Although desirable in rare circumstances, this should be avoided as much as possible. It brings with it complications that make your job of implementing and administering a coexistence solution much harder. An example of data that might be migrated is the user name and password information contained in an old email system that is about to be decommissioned. In this case, the best approach is probably to migrate the data to the directory and then forget about the old email system. Care must be taken so that after the data is migrated , the old system does not accept updates; users might be surprised when such updates are lost. An example of data that might need coexistence would be the user name and password information contained in an existing network operating system directory, such as Microsoft's Active Directory. If you expect this directory to continue providing service, you will probably want the common information it maintains with your enterprise directory to be synchronized on a regular basis. The source of this information could be the enterprise directory or the NOS directory, depending on your needs. An example of data that you might want to maintain in multiple data sources is user password data. It would be nice if user passwords were synchronized across your enterprise directory, NOS directories, and various application directories. It might also be nice if a user could change his or her password in any of these systems. On the other hand, the security implications of synchronizing passwords to multiple systems might prevent you from doing so. You'll also need to determine how frequently information should be synchronized to maintain effective coexistence. The ideal solution is usually to synchronize information in real time as soon as it is changed, but this is often unrealistic . Synchronization can be an expensive proposition, and it may consume large amounts of resources or require parts of your directory service (or other data sources) to be unavailable during the process. For these reasons, you may be forced to synchronize less frequently than you would like. Be sure to determine an acceptable range of synchronization frequency, and make sure the frequency you choose does not adversely affect the performance of your directory too much. As discussed in Chapter 11, "Privacy and Security Design," different data elements have different security needs. Some data elements are highly sensitive in nature and should be protected from unauthorized access and tampering. Other data elements are not sensitive, and they need to be protected only from unauthorized modification. The coexistence process itself may present another way to compromise your data. Beware of designing coexistence procedures that become a security hole. Also be aware of the capabilities of the systems you coexist with. You may take great care in protecting the data in your system, but it will do you little good if your system is synchronized to another system that provides no security. Tip Be careful to design your directory coexistence procedures with security in mind. A badly designed directory coexistence process often presents back-door holes that can be used to compromise the security of your directory. Make sure that systems your directory receives data from and sends data to are as secure as the directory itself. Also be sure to secure the processes and links between these systems. The result of all this design work should be summarized in a directory coexistence table that lists all your data sources, the data elements flowing to or from them, and how often the data flows. An example of a directory coexistence table is shown in Table 22.1. For this example, we've assumed that there are three sources for directory data in addition to the directory service itself: the corporate human resources database, Microsoft Windows NT domain registry, and the telephone operations database. As you can see, some information flows from the directory to these data sources, some flows from the data sources to the directory, and other information is simply maintained in the directory service and does not need to coexist with any other information. Table 22.1. A sample directory coexistence table
This information can also be represented in graphical form, as shown in Figure 22.1. This can help you better picture the way data flows and how the different systems need to interact. Figure 22.1 A sample data flow graph.
|
Index terms contained in this sectioncoexistence (directories)data to be synchronized migrating data modes of multiple sources one-time data dumps summary table 2nd 3rd 4th synchronization frequency 2nd synchronization performance synchronization security 2nd 3rd type of synchronization data directory coexistence migrating modes of multiple sources one-time dumps summary table 2nd 3rd 4th synchronization frequency 2nd synchronization performance synchronization requirements synchronization security 2nd 3rd type of synchronization directories coexistence data to be synchronized migrating data modes of multiple data sources one-time data dumps summary table 2nd 3rd 4th synchronization frequency 2nd synchronization performance synchronization security 2nd 3rd type of synchronization frequency synchronization directory coexistence requirements 2nd migrating data directory coexistence modes of directory coexistence multiple data sources directory coexistence one-time data dumps directory coexistence performance synchronization directory coexistence requirements requirements directory coexistence data to be synchronized synchronization frequency 2nd synchronization performance synchronization security 2nd 3rd types of synchronization security synchronization directory coexistence requirements 2nd 3rd synchronization directory coexistence data requirements frequency requirements 2nd performance requirements security requirements 2nd 3rd type requirements tables directory coexistence 2nd 3rd 4th updates data directory coexistence |
2002, O'Reilly & Associates, Inc. |