Overview

Before LDAP there was NIS...

Before centralized directory such LDAP existed, there was a system on UNIX called NIS.

This system was in fact a kind of authentification files shares (such /etc/passwd for users or /etc/groups for groups) and other informations as mail routing or share folders mapping.
In order to manage this system, several interfaces exists.One of them is Webmin.
Webmin is a web interface which acts directly on the files. It also contains an extensive list of plugins to manage a Linux system via a web interface.

With this tools, Linux server management is easier, but there is a caveat : Webmin must be installed on each server.  Webmin can also be used to manage the contents of an LDAP tree, but it is limited to groups and users.


When LDAP is more and more used

Because IT infrastructure are growing up and complexifying, Information storage with LDAP technology is more and more used. We thus find information, other than users and groups, such as the configuration of DNS / DHCP, access rules for systems such as FreeRADIUS or Pykota. Given the multiplicity of types of data managed, an interface such as Webmin or integration LDIF file from the command line to populate the LDAP tree quickly shows its limits :

  • multiplicity of webmin services;

  • writing tedious openldap command (LDIF file);

  • careful use of tools such as ldapbrowser or Apache Directory Studio.

FusionDirectory addresses this issue of content management directory by providing:

  • a modular web interface as needed and asked to complete only the necessary information (no need to interfere at the level of schemas or information to be written in several places);

  • OpenLDAP schema for the manipulation of information BUT based on pre-existing schemas;

  • a subsystem for managing services that are not interoperable with LDAP via a client-server system.

In other word, FusionDirectory is for LDAP what Webmin is to flat file.

User interface

FusionDirectory is only a web interface in front of Directory using LDAP v3 protocol.
hanks to this, the user only see the informations stored inside the directory not the container, attributes names or other technical informations which could complexify informations and configuration management


Schemas

FusionDirectory use his own schemas, but they are mainly used for FusionDirectory internal usage or for non-LDAP applications.
FusionDirectory try to use the already existing schema such as inetOrgPerson, posix each time it can …

FusionDirectory is intended for system administrators who manage lots of machines and user accounts. There is no minimum or maximum size for the number of account or computer to manage. We just need the LDAP directory (which stores the information) to be properly sized.

The system administrator problem

Actually an it infrastructure is composed of several key elements :

  •  users (name, firstname, password, email, acces right)
  •  groups of users (precise list of pre existing users)
  •  servers (description, IP address, type of service running)
  •  workstations (description, IP address, software list, licences)
  •  ip telephony (phone number, voice mail)
  •  web services (email, customer care …)

 In such an information system, the manager faces a complex problem who is :

How to get the right information at the right place at right time ?

Creating computer account is a good example:

 The new entrant needs a computer account, but very often the it service is the last service to know about it.

  •  How to create a computer account in a hurry ?
  •  Where is all the data necessary to create it ?
  •  How can I be sure that all systems have been configured correctly for this person ?
  •  How to maintain consistent information in all components of an information system ?
  •  How to tell what computer station will be assigned to him ?
  •  What are is need for software or network resources ?

 The answer to these questions is to use a single repository for identity of the various elements of the information system.

 Indeed, the use of such a system ease the work of the administrator:

  •  The system administrator does not need to put the information on X systems at risk of making mistakes.
  •  The administrator completed once the information on this directory, and it is the X systems who seek and retrieve information they need.

 

The interest of a Directory

The Directory of identities in an information system should be structured with the least possible redundancy of information to be easily searchable by applications.

This need to manage information in a unique way and with a standardized application has resulted in the creation of a type of server called “server directory”.

This server contains only the data. Only one storage platform contains the various components of an information system. It allows the creation modification and deletion of these data by third-party applications.

Also known as LDAP, directory servers because it is the standard LDAP that is used for the presentation of identity to other services.

 

The services associated with a directory infrastructure

As stated above, a directory serves as a basis for organized storage for the content of an information system.

This directory can supply all services required to operate the information system as long as the service has the ability to natively use this directory.

We can also mention the following services that may be associated with this directory

  • DNS / DHCP for network access client
  •  user / groups for people's access to a resource data
  •  Antivirus / spam email for verification
  •  phone list for phone number and setup positions corporate telephone
  •  a web-type address book with a user-friendly names names and phone number of a company

 

The daily management of a directory

The keyword in the management of a directory by a director is ” simplicity ”

A directory must be managed by persons not proficient in the information system as a whole.

When an account is created, the creator does not have to intervene in other locations to create other things such as email account, home directory or even the account on the intranet. This is the directory that deals with the spread of the data by making it available to third parties services.

 

Existing directory management tools

In terms of directory management there are 2 types of tools

 

 

FusionDirectory considers the role of an LDAP server to be an organized storage.
FusionDirectory can be used with any type of LDAP server provided that it knows how to communicate in LDAP V2 or V3 as:
 
  • ApacheDirectory from the apache Foundation
  • eDirectory from Novell
  • 389-Directory From Fedora project
  • Sun Directory from Sun Microsystem
 

Content protection of LDAP tree

FusionDirectory adds entries in the directory, an attribute (gosaACL) for limiting access to an LDAP record,or even attributes to users from the web interface.
 
Those ACLs are only used by FusionDirectory and are not intrusive to other applications using the directory server.
These ACLs allow fine grained control to who can use FusionDirectory.
These ACLs can be assigned to roles. We may have a role:
 
  •   user : it can connect to FusionDirectory with his login / password to change is data only when permitted by the admin.
  •   Local administrator : this role will be able to manage users and groups and also a branch.
  •   global administrator : this role has the right to do everything.
  •   human resources : this role can only create users from template to optimize the flow of arrival of new people.


Access to multiple LDAP trees

FusionDirectory is a web interface running by profile.
It is therefore possible to have a single FusionDirectory instance and access multiple LDAP servers with different profiles.
In the case of an information system in multiple locations with separate directories, a single interface will manage them all.


FusionDirectory Triggers

FusionDirectory incorporates a series of triggers that can launch a specific action based on a task FusionDirectory must run.
These triggers are associated with a content type (LDAP user, group, server, password, service (etc. ..) and the triggering action (create, edit, delete, change password … )
This system is very useful when certain actions should be followed on arrival or departure of a person in the company For example, when creating a user, a script generation form can be executed automatically with information from the LDAP server. This can be useful for generating badges with photo, a form of access to the canteen or sending an email to warn of the actual arrival of the person.
This system is also convenient when we want to deploy the account of that person on an application does not support LDAP (FusionDirectory can also transmit the password) Another example is when a user leaves, you must:
 
  •  archive and delete his mailbox
  •  archive and remove its network space
  •  delete him from third party applications not connected to LDAP. All of this can be easily done by shell scripts (at least in UNIX environment) and run automatically after the suppression of the person by the administrator in FusionDirectory


The interaction with non-LDAP applications

FusionDirectory stores information of a service or a server on an LDAP server.
How about when this service does not have the opportunity to interact with LDAP? This question can be solved by creating:
 
  • LDAP schema suitable for application to the LDAP server
  • a plugin for its management in FusionDirectory
  • a plugin for the client installed on the server (client as a module FusionInventory)

Architecture diagram

Here is a diagram detailing the operation for servers

  • samba
  • DNS server
  • Webserver

 

The common steps

  • Step 1 : The user connects to the server via a web interface FusionDirectory. The user account already exists in the LDAP server.
  • Step 2 : For each write or read in the directory, the web application FusionDirectory connects to the LDAP server as a user with sufficient rights to delete, modify or create any object. The connection is done through LDAP v3. All connections settings and display parameters of FusionDirectory are stored in /etc/FusionDirectory/FusionDirectory.conf

 

Web application case

The application has been configured to authenticate each user through the LDAP. The web application has the name of the LDAP server, the search filter and possibly a service account.

  • Step 1 and 2 : The administrator created a user account with the POSIX extension (which allows the filling of the password for a given account)
  • Step 3 : The user connects to the web application provides a login / password
  • Step 4 : The web application confirm or reject the connection of the user on the application by querying LDAP directory.

 

Samba server case

The server contains the Samba network drives belonging to the user and possibly the domain controller.

  • Step 1 and 2 : The administrator as added the samba setting for the user account (converting the unix password in windows password, definition of access rules, UNC path ..)
  • Step 5 : The user requests access to the Samba server.
  • Step 6 : The Samba server retrieves information about the requesting user on the LDAP server and uses it to allow access and direct the user to the appropriate shared directory.

 

case of DNS system with bind software

The DNS server provided among other things, the equivalence between IP addresses and names of qualified servers. For that he needs to consult a table of equivalence IP ⇒ name and name ⇒ IP. FusionDirectory allows the manipulation and storage in the LDAP configuration of the DNS server bind.

  • Step 1 : Via the web interface, the administrator says DNS records.
  • Step 2 : Data is written to the LDAP server .
  • Step 7 : synchronization of regular equivalence tables from the local content of the LDAP server is done via a script (ldap2zone) running on the DNS server. Running this script every time you change DNS settings on the LDAP server can be implemented through triggers. *
  • Step 8 : the client accesses the DNS server by the application in its classical version 9, can bind directly query the LDAP server

 

General remarks on the use of FusionDirectory

In this framework, the roles between FusionDirectory, the LDAP server and server tiers are well defined:

  •  FusionDirectory reads / writes to the LDAP, the server application or third application read the LDAP
  •  FusionDirectory is not essential to the operation of servers and / or applications.
  •  FusionDirectory is essential for a use of data in a friendly way.

 The 3 examples above are not the only applications, because other services use the same principle as the mail server Postfix to route messages or the server dhcpd for assigning dynamic IP addresses.