2.3. Performing a Site Survey
- Identify the applications that use the directory.Determine the directory-enabled applications deployed across the enterprise and their data needs.
- Identify data sources.Survey the enterprise and identify sources of data, such as Active Directory, other LDAP servers, PBX systems, human resources databases, and email systems.
- Characterize the data the directory needs to contain.Determine what objects should be present in the directory (for example, people or groups) and what attributes of these objects to maintain in the directory (such as usernames and passwords).
- Determine the level of service to provide.Decide how available the directory data needs to be to client applications, and design the architecture accordingly. How available the directory needs to be affects how data are replicated and how chaining policies are configured to connect data stored on remote servers.
- Identify a data master.A data master contains the primary source for directory data. This data might be mirrored to other servers for load balancing and recovery purposes. For each piece of data, determine its data master.
- Determine data ownership.For each piece of data, determine the person responsible for ensuring that the data is up-to-date.
- Determine data access.If data are imported from other sources, develop a strategy for both bulk imports and incremental updates. As a part of this strategy, try to master data in a single place, and limit the number of applications that can change the data. Also, limit the number of people who write to any given piece of data. A smaller group ensures data integrity while reducing the administrative overhead.
- Document the site survey.
2.3.1. Identifying the Applications That Use the Directory
- Directory browser applications, such as online telephone books. Decide what information (such as email addresses, telephone numbers, and employee name) users need, and include it in the directory.
- Email applications, especially email servers. All email servers require email addresses, user names, and some routing information to be available in the directory. Others, however, require more advanced information such as the place on disk where a user's mailbox is stored, vacation notification information, and protocol information (IMAP versus POP, for example).
- Directory-enabled human resources applications. These require more personal information such as government identification numbers, home addresses, home telephone numbers, birth dates, salary, and job title.
- Microsoft Active Directory. Through Windows User Sync, Windows directory services can be integrated to function in tandem with the Directory Server. Both directories can store user information (user names and passwords, email addresses, telephone numbers) and group information (members). Style the Directory Server deployment after the existing Windows server deployment (or vice versa) so that the users, groups, and other directory data can be smoothly synchronized.
Table 2.1. Example Application Data Needs
|Application||Class of Data||Data|
|Phonebook||People||Name, email address, phone number, user ID, password, department number, manager, mail stop.|
|Web server||People, groups||User ID, password, group name, groups members, group owner.|
|Calendar server||People, meeting rooms||Name, user ID, cube number, conference room name.|
- The data required by various legacy applications and users
- The ability of legacy applications to communicate with an LDAP directory
2.3.2. Identifying Data Sources
- Identify organizations that provide information.Locate all the organizations that manage information essential to the enterprise. Typically, this includes the information services, human resources, payroll, and accounting departments.
- Identify the tools and processes that are information sources.Some common sources for information are networking operating systems (Windows, Novell Netware, UNIX NIS), email systems, security systems, PBX (telephone switching) systems, and human resources applications.
- Determine how centralizing each piece of data affects the management of data.Centralized data management can require new tools and new processes. Sometimes centralization requires increasing staff in some organizations while decreasing staff in others.
Table 2.2. Example Information Sources
|Data Source||Class of Data||Data|
|Human resources database||People||Name, address, phone number, department number, manager.|
|Email system||People, Groups||Name, email address, user ID, password, email preferences.|
|Facilities system||Facilities||Building names, floor names, cube numbers, access codes.|
2.3.3. Characterizing the Directory Data
- Number of occurrences in various applications
- Data owner
- Relationship to other directory data
Table 2.3. Directory Data Characteristics
|Employee Name||Text string||128 characters||Human resources||User's entry|
|Fax number||Phone number||14 digits||Facilities||User's entry|
|Email address||Text||Many character||IS department||User's entry|
2.3.4. Determining Level of Service
2.3.5. Considering a Data Master
- Replication among Directory Servers
- Synchronization between Directory Server and Active Directory
- Independent client applications which access the Directory Server data
- Master the data in both the directory and all applications that do not use the directory.Maintaining multiple data masters does not require custom scripts for moving data in and out of the directory and the other applications. However, if data changes in one place, someone has to change it on all the other sites. Maintaining master data in the directory and all applications not using the directory can result in data being unsynchronized across the enterprise (which is what the directory is supposed to prevent).
- Master the data in some application other than the directory, and then write scripts, programs, or gateways to import that data into the directory.Mastering data in non-directory applications makes the most sense if there are one or two applications that are already used to master data, and the directory will be used only for lookups (for example, for online corporate telephone books).
2.3.6. Determining Data Ownership
- Allow read-only access to the directory for everyone except a small group of directory content managers.
- Allow individual users to manage some strategic subset of information for themselves.This subset of information might include their passwords, descriptive information about themselves and their role within the organization, their automobile license plate number, and contact information such as telephone numbers or office numbers.
- Allow a person's manager to write to some strategic subset of that person's information, such as contact information or job title.
- Allow an organization's administrator to create and manage entries for that organization.This approach allows an organization's administrators to function as the directory content managers.
- Create roles that give groups of people read or write access privileges.For example, there can be roles created for human resources, finance, or accounting. Allow each of these roles to have read access, write access, or both to the data needed by the group. This could include salary information, government identification numbers, and home phone numbers and address.For more information about roles and grouping entries, see Section 4.3, “Grouping Directory Entries”.
2.3.7. Determining Data Access
- Can the data be read anonymously?The LDAP protocol supports anonymous access and allows easy lookups for common information such as office sites, email addresses, and business telephone numbers. However, anonymous access gives anyone with access to the directory access to the common information. Consequently, use anonymous access sparingly.
- Can the data be read widely across the enterprise?Access control can be set so that the client must log into (or bind to) the directory to read specific information. Unlike anonymous access, this form of access control ensures that only members of the organization can view directory information. It also captures login information in the directory's access log so there is a record of who accessed the information.For more information about access controls, see Section 9.7, “Designing Access Control”.
- Is there an identifiable group of people or applications that need to read the data?Anyone who has write privileges to the data generally also needs read access (with the exception of write access to passwords). There may also be data specific to a particular organization or project group. Identifying these access needs helps determine what groups, roles, and access controls the directory needs.For information about groups and roles, see Chapter 4, Designing the Directory Tree. For information about access controls, see Section 9.7, “Designing Access Control”.