Identifying Directory Management Tasks

Identifying Directory Management Tasks

The skills and techniques required to manage an LDAP-based naming server are a combination of those of an experienced Solaris OE system administrator and database administrator. Some of the tasks are routine, such as adding and deleting users, while others are less frequently performed, such as setting up replication. The following is a list of common tasks that you are likely to perform:

• Directory Data Backup and Recovery

• Provisioning Users and Groups

• Managing Client Profiles

• Restricting User Access

• Managing Replica Servers

• Monitoring the Directory Service

• Extending the Directory Schema

• Troubleshooting Problems

Directory Data Backup and Recovery

Your directory server contains both configuration and user data. Configuration data is consulted by the directory server when the directory server initializes, by the administration server, and possibly by other Sun ONE applications that might be running. User data is placed in one or more directory databases and is referenced by your LDAP-aware applications. Both types of data should be backed up regularly.

Although you might be deploying directory data replication, there is a potential that corrupted data can be propagated from one server to another. Accidental deletion of data can occur, in which case the data would be deleted on replicas as well. Therefore, it is prudent to back up your directory data regularly.

The frequency of backups depends on how frequently your data changes. Configuration data tends to be relatively static and does not require as frequent backups as user data. If the directory is used solely for naming service data, most updates would likely occur when users are added or removed, and when passwords are changed. The frequency of this activity depends on how dynamic or stable your user population is.

Directory data backups can occur while the directory server is online or offline. Offline backups are faster, but directory data is not accessible while the backup is performed. Online backups do not require the directory server be taken offline, but are slower and can only take a snapshot of what the directory data looks like at a single point of time. If updates are performed while an online backup is being performed, they may or may not be backed up.

Data recovery can either be performed offline or online. As for backups, the offline method is faster. The online recovery is slower, but does not have a significant impact on overall directory server performance.

The Sun ONE Directory Server 5.2 software ships with tools for doing both offline and online data backup and recovery. These procedures are described in "Directory Data Backup and Recovery" on page 406.

Provisioning Users and Groups

Managing users and groups is perhaps the most common task for system administrators. New user accounts need to be created and deleted when a user joins or leaves the organization. Users are typically placed in groups so they can share resource access rights with other similar users. Likewise, they need to be added or removed from groups when they join or leave.

Provisioning users and groups in an NIS or NIS+ environment is relatively straightforward. This is because user account data is consistent for all users. Only the POSIX-defined fields need to be addressed. These are:

• Login name

• Password

• User Identifier (UID)

• Group Identifier (GID)

• GECOS

• Home directory

• User shell

Because of the extensibility of LDAP, it is likely that much more information about users will be maintained in the directory. For example, an LDAP entry for a user at Sun might look like this:

Sample User Entry

 cn=A Rose (5550),ou=people,dc=example,dc=com inetuserstatus=active manager=cn=Billy Smith (11350),ou=people,dc=example,dc=com seaprincipalid=FYYMqeyCWAN777mm5aIW seaprincipaltype=H mailhost=bonzo.example.com sn=Rose employeetype=Employee nickname=Ave employeenumber=5555 datasource=NetAdmin telephonenumber=x51212/[phone] objectclass=top objectclass=person objectclass=organizationalPerson objectclass=inetOrgPerson objectclass=emailPerson objectclass=NameViewPerson objectclass=mailRecipient givenname=Avery departmentnumber=0123456 host=uday.example.com maildeliveryoption=mailbox roomnumber=10 globallocation=usa100 l=BURLINGTON, UNITED STATES countrycode=US cn=A Rose cn=Avery Rose cn=Avery S. Rose cn=A Rose (5555) reportsto=12345 

There is so much more user information stored than what POSIX defines, so standard Solaris OE provisioning tools are not adequate because the tools are not aware of site-specific attributes that might have been added. In most cases you will want to create your own user provisioning scripts or tools. Tips for doing so are presented in "Managing Users and Groups" on page 432. Details on how to add custom or site-specific attributes can be found in "Extending the Directory Schema" on page 440.

Another aspect of provisioning users is creating a home directory for them. In most cases this will be an NFS-mounted directory that is mounted using the automounter. The automounter depends on a naming service for data, so home directory mount points need to be specified in LDAP.

The notion of group membership takes on a new meaning with LDAP as a naming service because two types of groups exist:

• POSIX groups

• LDAP groups

The POSIX groups are used to determine file access rights, and work the same way as if they were maintained in NIS or NIS+. LDAP groups only pertain to directory resources. That is, access to data maintained by the directory. While the Solaris OE does not care about LDAP groups, you might want to take advantage of LDAP groups for administrative purposes. For example, you could assign LDAP group membership to system administrators responsible for managing naming service data. There is no relationship between POSIX and LDAP groups, so provisioning tools must treat these as separate entities.

Password Management

Another aspect of user management is managing the password policy of users. That is, establishing policies such as how often users are required to change their passwords. Password management can be set on the directory server or by setting the attribute values defined in the shadowAccount object class. In the latter case, password management works the same as with NIS/NIS+.

Managing Client Profiles

Client profiles are the mechanism you use to modify how a particular client host interacts with the LDAP naming service. You can group several hosts together by furnishing them with the same profile. There are several parameters that can be adjusted to affect the behavior of a naming service client. These include:

• Listing of preferred and alternate servers

• Search path for naming service data

• Timeout limits

• Object class and attribute mapping

• Service Search Descriptors (SSDs)

• Authentication method

A single client profile is created when you run idsconfig to configure your directory server. In many cases you will want to create additional profiles to take advantage of the flexibility they provide. "Managing Client Profiles and Proxy Agent Accounts" on page 412 discusses how to create new profiles and propagate them to clients .

Managing Proxy Agent Credentials

Related to client profiles are the credentials used to authenticate a client to a directory server. This information is kept in the local /var/ldap/ldap_client_cred file. If the proxyagent password is changed, the file needs to be updated. See "Managing Client Profiles and Proxy Agent Accounts" on page 412 for details.

Restricting User Access

For security reasons, it is often desirable to limit user access to particular systems. For example, you might only want certain users or groups of users to be able to log in to mission-critical servers. There are several ways to do this with the LDAP naming service. These include:

• Implementing netgroups

• Implementing client profiles containing Service Search Descriptors (SSDs)

• Object class and attribute mapping

• Setting directory server access control instructions (ACIs)

Another aspect of restricting access to systems is controlling what functions can be performed by a particular user. This is done through Role-Based Access Control (RBAC). While this is not unique to LDAP, the data that RBAC relies on must be mapped to specific LDAP object classes and attributes.

"Deploying RBAC with LDAP" on page 439 describes procedures for restricting actions and deploying RBAC.

Managing Replica Servers

After you set up and configure your initial directory server, you will want to create replicas. Besides the initial setup of replicas, there are several other management issues. These include:

• Enabling SSL

• Changing Replication Agreements

• Monitoring Replication Status

• Decommissioning Replicas

• Rebuilding Replicas

There are several tools and techniques for managing replicas, covered in "Managing Directory Data Replication" on page 417.

Directory Server Monitoring

To assure your directory service is running smoothly, it is wise to monitor it to detect problems before your users encounter them. There are several tools and technologies available that do this to varying degrees. These include:

• Service Availability Manager (SAM) add-on to Sun Management Center 3.0 (SunMC)

• BMC Patrol

• Java Management Extensions (JMX) agent

• Simple Network Management Protocol (SNMP)

• Directory Console Performance Counters

• Access Log Viewer

Monitoring tools can be used to send alarms if malfunctions are detected , or to monitor resource usage. The SAM add-on to SunMC periodically performs a predefined search on the directory and measures the response time. If the response time exceeds a pre-established value, an alarm is sent to SunMC where it is processed .

SNMP agents work in a similar fashion except they communicate using the SNMP protocol. More sophisticated monitoring can be accomplished with third-party tools such as BMC Patrol.

Another aspect of monitoring is making sure the directory is tuned properly and that clients are not having problems connecting. Lots of useful information can be obtained from the Directory Console performance counters. Information about access issues, such as permission problems, can be obtained by examining the directory server access log.

Procedures and techniques for using these tools is found in "Using logconv.pl" on page 427.

Extending the Directory Schema

A major enhancement of an LDAP-based naming service over NIS and NIS+ is the ease of extending the data stored in it. One of your goals of migrating to LDAP is probably to consolidate information about users, so you will most likely want to add user data that goes beyond the basic information contained in the passwd NIS maps and NIS+ tables. To do this, you can use standard LDAP object classes or create your own.

The standard LDAP schema defines object classes such as inetOrgPerson that defines many attributes that describe information about an employee. However, with the rapid communication technology changes that are occurring, more and more information needs to be stored. For example, an employee might now have a mobile phone, home ISP email address and pager number in addition to their home phone number and office phone and email address.

Details on what schema definitions are available and how update the schema is fairly well documented in the Sun ONE Directory Server software documentation. A quick overview and tips on how to update the schema is provided in "Extending the Directory Schema" on page 440.

Troubleshooting Directory Server Problems

Tied in with monitoring your directory server, is how to isolate problems once they are detected. Programs like snoop are useful, but cannot be used if data encryption is used. Log files are helpful and can be enhanced by turning on process tracing. Troubleshooting tips are presented in "Troubleshooting Tips" on page 260, and error codes likely to be encountered are described in Appendix B, "LDAP v3 Result Codes". Appendix C, "Using snoop with LDAP" provides guidance on how to effectively use snoop to diagnose problems.