Introduction to 389 Directory Server

http://www.openlogic.com/wazi/bid/262060/Introduction-to-389-Directory-Server


The Fedora Project's 389 Directory Server, an advanced and complete open source LDAP (Lightweight Directory Access Protocol) server, can satisfy every corporate demand for an alternative to popular commercial solutions such as Microsoft's Active Directory. It come bundled with a powerful, intuitive, easy-to-use graphical interface to facilitate the administration of directory servers.
This article assumes you have the fundamental understanding of LDAP and directory services. If not, the article OpenLDAP for Remote Authentication is a good introduction to the idea of LDAP and directory servers as a whole.

Installation and setup

To install the 389 Directory Server in CentOS 6 you must have the EPEL repository enabled. This repository allows you to install many additional packages besides 389 Directory Server. If you don't have it installed yet, run the command rpm -ivh http://ftp-stud.hs-esslingen.de/pub/epel/6/i386/epel-release-6-8.noarch.rpm, then run the command yum install 389-ds.noarch to install the directory server and its dependencies.
The installation provides you with a few essential packages and executables. dirsrv is the directory server itself; make sure that it is always started and stopped with the system by running the command chkconfig dirsrv on. dirsrv-admin handles administration; you should also run chkconfig dirsrv-admin on.
Another essential package is the graphical admin console, 389-console. If you have full a X environment on the server, you can start it with the command /usr/bin/389-console. Production servers usually don't have full X environments, but you can still run the console one of two ways.
The first option is to run the console on a local client and connect to the remote server with it. The project provides console installation packages for various platforms, including Windows (389-Console-1.1.6-i386.msi and 389-Console-1.1.6-x86_64.msi), from its official download page. In many Linux distributions the console can be installed directly from the official repository. In Debian- and Ubuntu-based distributions the package is under the name 389-console. If you choose to connect from a remote client, make sure that your connection to the server is secure, because sensitive information is passed.
The second option for using the admin console is to forward your X session over SSH. To do this you need a basic X environment set up on the production server, which you can install by running yum install xhost xorg-x11-server-Xorg xorg-x11-xauth dejavu-sans-fonts dejavu-serif-fonts. After that, set and export the shell variable DISPLAY with the command export DISPLAY=localhost:0. You should then be able to run remote X programs, including 389-console, over SSH. Establish an SSH connection first with the command ssh -X serveripaddress, where the -X argument enables forwarding.

Configuration

To start the initial configuration of the directory server, run the command /usr/sbin/setup-ds-admin.pl. It invokes an intuitive, text-based wizard that guides you through the whole configuration process. It configures both the 389 Directory Server and its admin management service.
The configuration wizard offers three installation types: express, typical, and custom. Start with the typical choice, which is good enough for a beginning.
The script first checks your server setup for possible problems. Make sure to resolve any warnings it displays after you complete the setup.
The wizard provides good explanations for all the options and helps you making the correct choices with autodetected default values. Here are a few hints for the most important options in their order of occurrence:

• Computer name – The configured hostname under which the server works. By default, the configuration script detects your server's hostname automatically. Make sure that this name is valid and resolves correctly for other hosts. If it doesn't, you will have problems, especially for services using encryption such as LDAPs (LDAP secured with encryption); encrypted services require proper resolving of the hostname and a certificate name match.
• User and group – The user and group privileges under which the directory server runs. It's important that these not be regular system users. The default values of user nobody and group nobody are suitable.
• Domain – Domains are used to distinguish different organizational structures in LDAP. You can leave the default option for the server's domain.
• Listening ports for the directory server – The wizard asks you to choose two listening ports. The first choice, for the port of the directory server, is by default the standard LDAP port, 389. Aha, so that's where the name of the 389 Directory Server came from! The second port you have to choose is for the administration console to connect to. You should leave the default, 9830.
• Directory server identifier – As the name suggests, this value identifies each instance of a directory server. This is essential when you have more than one instance of the directory server configured. The default option is to use your hostname. This option also determines where the files for the corresponding instance are stored. For example, if you choose server1 as the identifier, its configuration files will be placed in the directory /etc/dirsrv/slapd-server1.

One of the key questions the wizard asks is whether you want to register this software with an existing configuration directory server. Make sure to answer no, which instructs the setup script to continue through the complete setup.
After completing the configuration you have to configure your firewall. Usually the LDAP port (389) should be wide open to your internal network or servers' subnetwork so that servers can use the LDAP service. The administration port (9830) should be allowed only for the IP address of your admin station, if you're accessing it remotely, or not allowed at all if you run the admin console locally on the server.

Administration

To start using the 389 Directory Server console locally, run the command /usr/bin/389-console. You will be prompted for your admin user ID, password, and administration URL. The URL should look like http://localhost:9830/ if you are connecting locally to localhost.

As the left menu tree shows, the console lets you administer both the administration server and the directory server. Double-click on the server you want to manage in the menu tree.

The interface for the administration server lets you do everything from starting and stopping the service to configuring logging, SSL certificates, and encryption. All of its menus are intuitive and user-friendly.

The interface for the directory server gives you the most common controls and options for operations such as starting and stopping the server. It also allows you to easily back up and restore the directory information, which is useful because the usual methods of backing up and restoring LDAP information are not easy or straightforward.
The console for the directory server provides some advanced options. You can extend functionality through various plugins, set up SNMP agent for monitoring, configure complex replication, and even browse the LDAP directory data straight from the console.
For more information and complete guidance read Red Hat's guide to the commercially supported version of the directory server; it covers everything you can find in the freely available one.
Without a doubt, 389 Directory Server is the leader for open source directory management. It's the only complete solution that provides all the enterprise features you can find in similar commercial products.

TERIMA KASIH ATAS KUNJUNGAN SAUDARA
Semoga artikel ini bermanfaat bagi saudara. Jika ingin mengutip, baik itu sebagian atau keseluruhan dari isi artikel ini harap menyertakan link dofollow ke http://androidjapane.blogspot.com/2013/02/introduction-to-389-directory-server.html. Terima kasih sudah singgah membaca artikel ini.