Control what objects are displayed in web interface

Users will never see directory objects they don't have the permissions to view. However, you might want to additionally restrict which objects are displayed in the web interface.

In this tutorial you will learn how to hide specific types of objects, how to hide objects that don't match your criteria, and how to allow users to view only objects located in a specific organizational unit or container.

Configure user permissions

By default, all users have the right to view all objects in all domains managed by Adaxes.

To allow users to view only the objects they need, first, adjust their permissions. For details, see Hide directory objects from users.

Configure criteria for displaying objects

You can configure the web interface to never display objects of a certain type, even if the signed in user has the permissions to see them. For example, you might want to hide all computer and printer objects, and display only user accounts, contacts, and groups.

On top of that, you can specify detailed criteria for each visible object type. For example, you might want to hide disabled user accounts, accounts whose name starts with an underscore, distribution groups that don't have the word Department in their name, and so on.

How to show only the objects that match certain criteria { #filtercriteria}

Open Adaxes web interface configurator.
In the top left corner, select the web interface you want to customize.
In the left navigation menu, click Browsing.
In the Object types section, clear the checkboxes next to the object types you want to hide from the web interface.

To display an object type that is not listed by default, scroll to the bottom of the list and click Add type.

For information on how to configure the web interface to manage objects of a custom type, see Manage directory objects of a custom type.

Applying criteria

To display only the objects that match your criteria, select the Criteria checkbox next to an object type.

Configure criteria in the dialog that opens.

Example 1 – Microsoft 365 and distribution groups

Example 2 – Microsoft 365 and distribution groups that contain Department in their name

To add a compound criteria item that combines several conditions together, click the arrow button next to Add, and then click Add compound.

Example 3 – Enabled user accounts whose name doesn't start with an underscore

Example 4 – Only users from a specific department

Example 5 – Only enabled user accounts from the same department as the signed in user

You can configure the criteria so that it will be different depending on the signed in user. This is achieved with the help of value references, e.g. %department%, %company%. They will be replaced with corresponding property values of the signed in user.

Example 6 – All direct and indirect subordinates of the signed in user

If you need to use identical criteria for several object types, you can copy and paste it by pressing the arrow button next to Edit criteria.

Screenshot

You can also specify common criteria for all object types. Only objects that match their type-specific criteria and common criteria will be displayed in the web interface.

If you want an object type to be displayed as a container in the directory tree, enable the corresponding checkbox in the Container column.

Restrict top level nodes

You can allow users to view only the objects located in particular organizational units or containers. For example, you may want users to only see objects located in their own organizational unit and in the Groups organizational unit.

How to set the top level nodes

Open Adaxes web interface configurator.
In the top left corner, select the web interface you want to customize.
In the left navigation menu, click Browsing.
In the Navigation section, select the Top level nodes checkbox.
Add top level nodes in the dialog that opens.

If you add multiple top level nodes with the same name, you can change their display names to allow the users to distinguish between them. The display names are changed only in the web interface.

A top level node can be dynamic. In other words, it can be different for every signed in user. For example, it can be the OU where user's account resides or an OU named like the user's department. Dynamic top level nodes are added using templates.

How to add dynamic top level nodes

In the Top level nodes dialog, click Add.
In the dialog that opens, click the Template button.
Specify a template to generate the distinguished name of the top level node. To make the top level node dynamic, you need to use value references in the template, e.g. %department%, %adm-ParentDN%. They will be replaced with the corresponding property values of the signed in user.

To insert a value reference, click the button.

Example 1 – Allow users to view only their own organizational unit

Use the %adm-ParentDN% value reference. It will be replaced with the DN of the organizational unit where the signed-in user resides.

Example 2 – Allow users to view an OU named as their department

Use a template similar to this:

OU=%department% staff,%adm-DomainDN%

The %department% value reference will be replaced with the value of the user's Department property, and %adm-DomainDN% will be replaced with the distinguished name of the user's domain.

For example, if a user from the Marketing department in the example.com domain signs in to the web interface, the top level node for that user will be OU=Marketing staff,DC=example,DC=com.

For more details on how to allow users to view only a part of the directory structure, see Limit access to the directory structure.