Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.
Whitepapers
Directory Deployment Planning Checklist
Published on 5th March 2008
Overview
When planning a directory deployment, there are a lot of things to take into account. This document has been written to help those planning a directory deployment, and in particular Isode partners working on directory deployments for their customers and prospects.
As the specifics of the approach taken will depend on the deployment requirements this paper does not attempt to be prescriptive, there are no "right answers". Instead, a series of questions that (may) need to be asked are listed. Notes on those questions help define the answers and explain the implications of choices made. References to other material are provided where appropriate.
The paper looks at:
- Which Applications will Use the Directory?
- What Schema is Needed?
- Where Does the Data Come From and How is it Managed?
- User Authentication Requirements
- Password Policy & Management
- Administrator Authentication Requirements
- Hardware Selection
- Failover Clustering & Read Redundancy
- Server Location
- Survivability and Disaster Recovery
- Replication
- Replication with Partners
- Server/Server Authentication
- PKI
- Backup and Maintenance
- Operational Management
Which Applications will Use the Directory?
A directory is an infrastructure application, and a directory deployment design will be driven by the set of applications to which a directory is put. Some common directory applications are listed here:
| Application | Notes |
|---|---|
| Whitepages | The directory is used as an information service to humans. This
may be a “people” directory or used for a wide range
of other data. This may be achieved using Isode’s DSI (Directory Service Interface) Web Application. |
| Email Client Support | An email client can access the directory for address book support, typically for enterprise people and role information. |
| Messaging Server Configuration | Messaging products, such as Isode’s messaging server hold information in the directory. |
| Groups and Email Distribution Lists | Directory is used to manage groups of users, and in particular email distribution lists |
| Single Sign On | Use of the directory as a repository of authentication information that can be used by computers and applications to provide a single point of authentication. |
| PKI | PKI systems generally use the directory as a mechanism for publishing and distributing information such as certificates and CRLs. |
| Support applications with built-in LDAP | A wide range of applications (e.g., Radius servers) make use of LDAP for authentication, and in some cases for authorization and capability configuration. |
| Web application support | Web applications, custom or standard, often use directory for authentication, configuration, and authorization. |
| Mobile Phone Support | Mobile phone operators will often use directory to hold account and operational information. |
| XMPP Support | Directory is used to provide authentication and user data for an instant messaging and presence service. |
What Schema is Needed?
There is a need to work out what schema will be used in the directory. M-Vault has extensive built in schema support, and it is straightforward to extend where needed. This definition could be left to the implementation phase in many projects. Schema that may be needed:
| Schema | Notes |
|---|---|
| Shared Information Schema | LDAP and X.500 provide substantial core schema on people and organizations. This will provide sufficient for many deployments. Some industries define specific schema, such as ATN Directory for Aviation, and ACP 133 for military, described in whitepaper ACP 133: The Military Directory Standard. |
| Extended Information Schema | Where information additional to the chosen core schema is needed, this should be defined by the project to meet user requirements. |
| Application Schema | Where applications use the directory, schema requirements should be determined from each one. Many applications use only standard schema. Where applications need extended schema, this is usually straightforward. |
| DIT Layout | An overall layout of the top levels of the DIT (Directory Information Tree) should be considered, including examples as to how real objects for each of the applications using the directory will be named. This is key planning as to how the directory will look and how the various applications will fit together. |
Where Does the Data Come From and How is it Managed?
Need to consider where data is sourced and how it is managed:
| Source | Notes |
|---|---|
| Managed in the directory by the Administrator | Holding definitive data in the directory is an ideal situation, and should generally be chosen if this is an option. Isode provides two tools for managing data in the directory:
|
| Managed in the Directory by the End-User | Directory is often a convenient approach to allow users to manage some or all of their own data (e.g., mobile phone number). Isode’s PIA (Personal Information Administration) Web Application is an ideal way to do this. |
| External Directory | Data may be held in an external directory such as Microsoft’s Active Directory. Isode’s Sodium Sync product is an ideal solution for efficiently keeping data in M-Vault synchronized from an external source directory. |
| External Database or other repository | Where another data source is used, there are two basic options:
The second approach will usually be straightforward if the data to be loaded is not complex. |
User Authentication Requirements
Need to consider how users accessing the directory will authenticate:
| Authentication Method | Notes |
|---|---|
| None | An approach sometimes taken for white pages type services is to give read access to all user data to anyone who is able to access the directory. Tools access the directory without use of authentication. |
| Username/Password | Username/password will be used by Web applications using the directory for authentication, and by other applications using the directory for central authentication. The SASL support in M-Vault is often used to map between the “username” provided by the user and the directory entry providing the authentication check and additional information including authorization. |
| Directory Name/password | DN/password authentication is used in many directory applications for authentication to the directory. In environments where the user doesn't know (or need not know) their DN, often the DN of the user is found by searching the directory. |
| Strong Authentication | Strong authentication, sometimes in conjunction with signed operations and smart cards may be used in secure environments. |
Password Policy & Management
Where password authentication is used for users, consideration needs to be given of password policy and related issues. Full description of this is given in the Isode white paper Password Policy for Directories. Major questions to be addressed:
| Question | Notes |
|---|---|
| Should passwords be hashed? | Passwords may be stored in the clear in M-Vault, or using a hash mechanism (e.g., salted SHA-256). Where passwords are used only for authenticating Web applications (which will always get a username and clear password to authenticate against the directory), it is recommended to store passwords in hash form. In order to support authentication mechanisms such as SASL/DIGEST-MD5
that avoid exchanging clear text passwords (in M-Vault or in applications
relying on M-Vault for authentication), it is necessary to hold
the password in the clear. Where this is done, read access controls
should be used to minimize read access to passwords. |
| What controls on password policy are needed? | Should the directory enforce minimum password length and other password controls. |
| Is password ageing used? | Should users be forced to change passwords at intervals. If done, there are a number of related features such as grace login and password history to consider. |
| What operator support is needed for passwords? | What controls are needed for operators to reset passwords, disable accounts and related capabilities. |
| Are there users who should be exempt from password policy? | It is often desirable to exclude select users, such as "service accounts", from password policy. |
Administrator Authentication Requirements
Authentication requirements for administrators making changes to data held in the directory should be considered separately to user authentication, as administrators can often make substantial changes and so security requirements are higher.
| Administrator Authentication | Notes |
|---|---|
| Directory Name/Password | This can be used with Sodium and Web tools. |
| Strong Authentication | Isode recommends use of Strong Authentication for administrator access, including use of signed operations for changes. Sodium supports this. Further information can be found in the Isode whitepapers: |
Hardware Selection
In most deployments, hardware selection is straightforward. In most situations, it does not make sense to run more than one DSA on a server.
| Review Point | Notes |
|---|---|
| Applied Load | The expected applied load (searches updates etc.) should be examined. This will be important for detailed configuration, such as choice of search indexes. For most deployments, any reasonably new small server will suffice, and detailed hardware planning is not needed. If there are fewer than:
No specific server hardware considerations are needed. For systems
above any of these levels, we recommend to review hardware choice
with Isode in context of anticipated load. |
| Other Applications | If other applications are running on the same servers, consideration needs to be made of the load that these systems may cause. |
| Disk System | Speed and quality of disk is important for good system performance.
If there is a high level of updates, fast disks with a write-back
cache should be chosen. The write-back cache is important. For servers mastering data, RAID is recommended to protect against single disk failure. |
| Memory | M-Vault uses caching to improve performance. We recommend having at least 1Gbyte of memory for each million entries held. |
Failover Clustering & Read Redundancy
There are questions that need to be considered for providing high availability
services at a single location:
| Option | Notes |
|---|---|
| Read Redundancy | In order to provide high availability read access to data, use of additional servers containing shadow copies of the data. This approach is also used for very large systems when one server does not provide sufficient read performance. With a shadowed system, master and all the shadows can provide read access in normal operation. |
| Failover Clustering | In order to provide high write availability, fail-over clustering can be a sensible choice for servers mastering data. This will ensure continued operation in the event of processor failure. See: Failover Clustering. |
Server Location
The number and location of M-Vault servers/sites needs to be considered.
Factors:
| Location Factor | Notes |
|---|---|
| User Location | The first consideration on server location is the location of the users and applications that need to make use of services from the directory. In many cases, users will be grouped at a number of sites that make it clear as to where to locate servers (servers at each site). |
| Firewalls and groups | Directory users may be grouped in ways that prevent server sharing (e.g., high grade users are partitioned from other users). Additional servers may be necessary to support this type of configuration. |
| Network Failure modes | As part of the core server location, failure of networks should be considered. Applications that rely on directory should either have a local server, or redundant paths to one or more remote servers. |
Survivability and Disaster Recovery
A key design factor for many high reliability systems is to consider how the system will operate if various elements of the system get destroyed. For military systems, different planning may be needed for wartime and peace scenarios. Factors:
| Factor | Notes |
|---|---|
| Off site hot standby | Having an off site hot standby may be a useful component to support disaster recover. See: Off Site Hot Standby (Disaster Recovery) for more details. |
| Additional servers | The main approach to dealing with survivability is to have additional servers, so that things can continue to work in the event of some servers not being available. The number and location will depend on the disaster scenarios considered. |
Replication
The overall plan for replication should be considered as part of the design, as this may have impact on servers and server location:
| Replication Factor | Notes |
|---|---|
| Naming Context Choice | A naming context is usually a subtree within the DIT (Directory Information Tree). Naming contexts are the basic unit of grouping data for replication purposes. The planning should consider which naming contexts are used and on which server each naming context is mastered. |
| Naming Context Location | Each naming context will be replicated to selected servers. In general, not all data will be needed on all servers. This will depend on which applications need which data. This replication needs to be planned. |
| Chaining | Where data needs to be made available from servers where it is not replicated (e.g., for low volume use) directory chaining (using X.500 DSP) should be configured. |
| Replication Protocol | Replication should use X.500 DISP to get good performance and high resilience. This is discussed in the whitepaper: The Case for X.500 DISP |
| Replication Schedule | DISP provides a number of options for replication schedule. On demand incremental “push” replication should be used in most situations. Other options may be sensible in specialized situations such as constrained bandwidth. |
Replication with Partners
Large directories typically do not exist in isolation, and information needs to be shared with partners.
The points made in this section also apply to more distributed organizations where elements of the directory are more heterogeneous.
| Capability | Notes |
|---|---|
| Which replication approach to use | Some partner directories can use replication with X.500 DISP, and for others a more decoupled data sharing using Isode’s Sodium Sync product makes more sense. The choices and issues are discussed in the Isode whitepaper Replicating and Synchronizing Data Between Directory Servers. Policy on mechanism to access to data may also impact the approach taken. |
| Data filtering | Data will often be exchanged on a need to know basis, or there may be policy controls on what is shared. DISP and Sodium Sync both offer data filtering capabilities |
Server/Server Authentication
When directory servers connect together, choices will need to be made
on the authentication used.
| Authentication Mechanism | Notes |
|---|---|
| Server name only | This may be a pragmatic choice if links are not secure and trusted. |
| Password | This may be used over secure links |
| Strong Authentication | This is recommended. See the whitepaper Why Strong Authentication for Directory? |
PKI
Where strong authentication is used, a PKI is needed to support this.
Isode provides components to integrate with a PKI but does not provide
a CA (Certification Authority) product.
| Question | Notes |
|---|---|
| Which CA? | Isode’s Mini CA demo tool can be used for experimentation and might be suitable for very small deployments with low security requirements. In most situations, a third party CA product is needed. |
| Should CRLs be used? | CRLs should be used and configured in the Isode products, if there is any possibility of revoking certificates. |
Backup and Maintenance
The following backup and maintenance issues should be considered, and
may have hardware and component implications.
| Issue | Notes |
|---|---|
| System Backup | Directory configuration and binaries should be backed up as part of the general system backup. |
| Directory Data Backup | M-Vault provides online directory backup. This should be used for all servers holding master data. |
| Log file maintenance | Logfiles should be configured to roll over at appropriate intervals. Event and audit logs should be cleaned up and archived as appropriate on a regular basis, |
Operational Management
Day to day management of servers should be considered:
| Management Task | Notes |
|---|---|
| General Purpose Monitoring | If operator cover is provided using general purpose system management tools, the SNMP capabilities of Isode products should be used to integrate into this system. See the whitepaper SNMP and Isode Servers. |
| Directory Specific Monitoring | There is benefit to providing operator cover using special purpose tools that give better information on directory status than can be achieved using general purpose tools. Isode’s DConsole GUI is provided for this purpose, and handles both server and replication monitoring. |
Conclusions
This paper provides notes for planning a directory deployment. Isode welcomes feedback on this, and on additional information that would be useful in an update of this paper.
