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 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
- An Argonaut module for the client installed on the server