CommuniGate Pro: Directory
DNs are used to build object name trees, with the rightmost attribute specifying
the most generic name, and the leftmost attribute specifying the unique object name itself.
The leftmost attribute is called Relative Distinguished Name (RDN) - it provides a unique name for the object among all objects with DNs having the same parent DN.
CommuniGate Pro Directory supports two types of storage units:
Initially, the CommuniGate Pro server creates one Local Storage Unit Main that contains the entire directory. You may add additional storage units using the WebAdmin Interface:
The diagram below shows a directory stored in one Local Unit Main:
The diagram below shows the same directory stored in 2 Storage Units, with the entire o=MyCompany subtree stored in a separate Storage Unit LDAP1:
Click the Directory link in the left frame of the CommuniGate Pro Server WebAdmin Interface. The Directory Storage Units page opens. You need to have the Directory access right to open this page.
The <root> string is used to specify the name of the default Storage Unit (i.e. the Storage Unit that stores the root of the Directory Tree).
To create a new Storage Unit, type a name for the new unit (this name will be used for administrating only), the Distinguished Name (DN) for the subtree that should be stored in that unit, and click the Add Remote Unit or Add Local Unit button.
Open the Directory WebAdmin page and click the name of a Local Storage Unit. The unit Settings page opens.
Each Local Unit has its own Schema. See the Schema section for more details on Unit Schemas.
When a user tries to read or modify the Directory data, the binding DN is used to check the Directory Access Rights.
When a user accesses the Directory from a CommuniGate Pro Web User Interface
session, the binding DN is the DN of the user Account record:
See the Directory Integration chapter for the details.
When the Directory is accessed using the LDAP module, the client can authenticate itself using the CommuniGate Pro Account name and the Account password. In this case, the binding DN is the DN of the Account record.
Before converting the user account name into the account Directory record DN, the user account Server Access Rights are checked. If the account has the Directory access right, the special "master" bind DN is used instead of the user account record DN. Clients with the "master" bind DN have unlimited Directory access rights.
Any Directory DN can be used for LDAP binding. The directory record with the specified DN must exist, the record should contain the userPassword attribute, and the attribute value must match the supplied password string.
If a client has not authenticated itself, the special anyone bind DN is used.
Open the Directory Access Rights page to set the Access Right records:
Each Access Right record has:
The Up and Down buttons allow you to move the records in the table, increasing and decreasing record priorities.
When a client requests to perform a search, read, modify, or any other operation on a record or a subtree with a certain DN, the Access Right records are checked from top to the bottom. The server looks for an Access Right record that:
When such an Access Right record is found, the record type specifies if the operation is allowed or prohibited. If no Access Right record is found, the operation is prohibited.
If the client binding DN is "master" (see above), all operations are allowed.
When a client requests a "read"-type operation, the procedure is repeated for all attributes the client wants to retrieve. If the operation is prohibited for all specified attributes, the read operation fails. Othwerwise, the operation is peformed, and the attributes the client has a right to retrieve are returned to the client.
If a client requests a "search"-type operation, the procedure is repeated for all attributes used in the search filter. If the search operation is prohibited for at least one of those attributes, the search operation fails.
If a client requests a "rename"-type operation, the procedure is used twice: to learn if the client has a right to delete the original Directory record, then to learn if the client has a right to create a Directory record in the new location.
Special strings can be used in the Bind DN field:
To create an Access Right record, enter the record name, target DN, and bind DN into the last empty element of the Access Rights table and click the Update button. Use the Up buttons to set the record priority.
To remove an Access Right record, delete the record name and click the Update button.
Sample Access Right record:
Sample Access Right record:
The Browser page includes the DN field:Use this field to type the DN of the Directory record/subtree you want to view and click the Go button. Click the Up button to remove the leftmost DN element and open the parent Directory record.
The next panel displays the Directory record with the specified DN:If the record with the specified DN could not be retrieved, this panel will contain the error message.
The next panel displays all record children.
Use the poup menu to limit the number of records displayed on in the subtree panel.
To search for specific records, enter an LDAP filter string (in the RFC 2254 format) into the Filter field and click the Display button.
The table elements display children RDNs and object classes.
Click the child element RDN link to open the child record in the Directory Browser.