- user management; templates and user classes make creation of users easy
- delegation of routine administration tasks
- data storage via LDAP - clients can directly bind to the LDAP database server
- flexible directory and name services - manages NIS, DNS, static DHCP entries, Samba users, LDAP → LDAP transformations, file based databases like /etc/passwd, /etc/group, /etc/hosts, ...
- single account / password across multiple systems and applications
- software distribution - manage software packages in your systems' native package format like RPM, DEB, SUN PKG
- service configuration (e.g. sendmail, bind, ntp, ...) via template mechanism
- customizable actions on events like e.g. account creation, password change, host configuration change, ... where actions include home directory creation, service restart, execution of arbitrary commands on target system and many many more
The Director is currently mainly deployed on Linux systems and therefore supports Linux best. Most Unix systems are not directly supported but the Director will work. There is some limitted functionality for Windows machines, too.
The Node Director requires an LDAP accessible database engine, such as the free OpenLDAP or the SUN / Netscape Directory Server. Virtually, any directory server that implements LDAP v2 or v3 and allows custom schema extensions should do, the development team uses OpenLDAP, and the Director has been successfully tested with the Sun Java System Directory Server 5.2.
The Director is in no means meant as a mere frontend for editing arbitrary data in LDAP accessible directory trees. It rather is a system management software storing its information via LDAP in RFC-compliant objects. The difference is that when you work with the Director you will never care about LDAP specific things like attributes, DNs, object classes, whatever (unless you want, of course). You will work with lists (e.g. of users) and forms (e.g. a single user account).
Anyway, the data is stored in an LDAP tree. While the Director comes with a number of means of updating name services like DNS, the system password/account database, Samba, etc. clients can directly bind via LDAP to the data store and access account / host records (e.g. via nss_ldap).