Printout Header

LEX Online Manual Content

Application Options - LDAP Settings

In this dialog, you can configure some LDAP settings according the connection and the LDAP related information output.

Application options: LDAP Settings

LDAP Connection Timeout

This is the timeout for establishing the connection to an LDAP server. So if you are in the LDAP Connections dialog, and you click on the Explore button or you double-click on an LDAP connection profile entry, this is the time interval (in seconds) which LEX uses to try to reach the regarding server. If the server doesn't answers on the given TCP port, the following error message appears:

LDAP server connection error

Attention: The value discussed here is only the timeout for the initial server contact. This is NOT the client-side request timeout for single requests after you have a connection to an LDAP server established. LEX uses a very long timeout for single requests (=24h). So if the server is reachable but very slow, or you want to see a very large list of objects, you maybe have to wait longer than this interval.

Default configuration: 5 seconds

LDAP searches with paged results

In an LDAP search request you have always to reckon with servers which enforce a limit for the count of search results for a single request. You perform for example a search request for all user objects in an entire OU structure, but you only receive 500 users in the servers answer although there must be over 2000 users in the regarding OU. The server always returns only a limited number of directory entries, no matter how often you perform the search and no matter what interface or tool you use for searching.

Especially ADS domain controllers and Exchange 5.5 servers have an active search limit by default (1000 for Active Directory, 100 for Exchange 5.5). Read more about the AD configuration of this 'MaxPageSize' limit in the SelfADSI Tutorial article about this topic.

To overcome these server-side limits and get all the existing objects, you have to perform an LDAP search where the search property 'Paged Results' is configured. This is a parameter which instructs the server to give the results in packets, each of them not bigger than the parameters specifies, and that as long until really all the result entries are retrieved by the requesting client. This technique is handled directly within the LDAP protocol (specified in RFC 4511), in the LDAP searches with paged results parameter you only have to ensure that the paged result parameter is activated and set accordingly:

  • A paged result value of 0 means that the search is to be performed without the paged results mechanism.
  • If a paged results search is performed, then the paged results value has to be lower than the MaxPageSize value on the server. A defensive value of approx. 100 should fit for the most LDAP servers which uses a MaxPageSize limit. In Active Directory environments, a default MaxPageSize value of 1000 is used. If you know the exact MaxPageSize value for a particular server, then you can use this value as a paged result parameter.

In Active Directory environments, you can use the Adjust button to detect the MaxPageSize limit of the regarding server. This value is stored in the AD configuration context in the object CN=Default Query Policy,CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services.

Default configuration: The value which was set in the LDAP connection profile or specified manually in the LDAP Connections dialog. When you are connecting to an Active Directory server, LEX tries to detect the MaxPageSize automatically at the beginning of the connection . If you didn't specify a paged result value or if your page result value is higher than the detected value, then the detected value from the directory becomes the new page result value.

Use directory schema to request object attributes

If an LDAP client wants to retrieve ALL the existing attributes of an object, it has to include a list in the LDAP request where all the attribute names are specified explicitly. Otherwise the server might return only a subset of the attributes. There might be some 'operational attributes' for example, which are considered to be used only internally by the directory server.

Normally LEX uses the directory schema to know all about the attributes which can be stored in the directory and which can be associated to a given object class. Therefore LEX can request a complete list of the attributes for a certain object class. But if you want to know the set of attributes the server would return in a general request without explicit attribute list, then you have to deactivate this parameter. It might be important for developers of LDAP scripts to know which attributes are in some kind of local attribute cache by default and which attributes have to requested from the server explicitly.

You can easily identify the attributes which are only returned by a directory server if requested explicitly by two different ways:

  1. Deactivate the Use directory schema to request object attributes parameter and configure the LEX main window to show the attribute list panel. You can see now the list of attributes (without the use of the schema) of a certain object. Now go again to the application options and activate the Use directory schema to request object attributes parameter - and press F5 in the attribute list. All attributes which are displayed red now are the attributes which are only returned if they are explicitly requested.

  2. When you have activated the Use directory schema to request object attributes parameter, go to an object and select it for comparison by using the menu option Tools - Select for Compare(Left side). Open a second LEX main window instance (for example by using the menu option Connection - New LEX) and deactivate the Use directory schema to request object attributes parameter. Then you can go to the same object and select it as the second comparison object with the menu option Tools - Compare with... . Then you see a object compare window where the same object is shown twice: On one side with all the attributes from the schema evaluation, on the other side only with attributes which are automatically returned fro the server without explicit request.

This option is only available if LEX could evaluate the directory schema of the regarding LDAP server correctly.

Default configuration: Active

Expand multivalued attributes in object list to a comma separated list

If a you choose an attribute to be displayed in the object list as a additional column, the multi valued attributes are displayed normally as a compressed information line:

Attribute syntax output as OID numbers

If you active this setting, all multivalues are shown with their values (one single line per object), separated with semicolons between the single array values:

Attribute syntax output as OID numbers

Please not that a comma separated value output can lead to very long column output which is not easy to handle, and can lead to significant performance decline. Just imaging that a long user list is shown with the users group memberships as the full expanded data column, each user haviong about dozens of group memberships...

Default configuration: Inactive

Translate the LDAP syntax OIDs in readable names

If a valid schema evaluation could be performed, LEX can show the attribute syntax (or data type) for all attributes in attribute lists. Technically, these syntaxes are represented by OID numbers (object identifiers), which are described in RFC 4517 'LDAP Syntaxes and Matching Rules'. With this option, you can choose whether the pure OID number of an attribute type is shown or the readable name.

Attribute syntax output as OID numbers

In the screenshot, you see the OID numbers instead of the readable attribute type names. This option is only available if LEX could evaluate the directory schema of the regarding LDAP server correctly.

Default configuration: Active

Convert date and time values in local machine time

Most LDAP directory servers store any date and time value in attributes as UTC (the Coordinated Universal Time), regardless in what time zone the involved LDAP clients and servers are. This parameter lets you choose whether the time values in attributes are converted by LEX to the local time of the machine where LEX is installed.

You should deactivate this parameter only if you want to see all time value attributes in our environment as UTC, or if your server don't use UTC but local time values (a conversion wouldn't have sense in this case).

LEX reads the deviation from UTC for the workstation out of the following registry key:

Default configuration: Active

Dont sort attributes and show names when values are loading

Normally, LEX reads the attributes in an server response and sort them according to the sort settings in the given attribute list. No matter what the current sort criterion is - attribute names or values for example - you don't see the 'real' order in which the attributes are returned by the server. To see that specific information, you can activate this parameter.

Another effect of activating the parameter is that LEX shows the name of the current attribute which is retrieved by the server. The name is shown in the status bar on the left bottom side:

Attribute name output during server response

So if you have difficulties in reading LDAP attributes, or if the attribute list is very slow, then you can use the Dont sort attributes and show names when values are loading parameter to identify the attribute which causes the trouble.

Default configuration: Inactive

Distinguished Names with RDN output

In this parameter, you can configure a list of RDN Attributes, which are shown as short names (=> Relative Distinguished Names, RDN) when the friendly name output is active. You see the Choose Short RDN Output Attributes dialog, where you can add/remove attribute names to/from the list:

Configuring friendly name output in the attribute list

When you choose the friendly name output generally, all distinguished names in object lists are displayed as short RDNs for better readability. But in attribute lists, this could be confusing because you expect the real attribute value in these lists. Therefore only attributes which has be configured to be shown as short RDN names in the friendly name output will be presented in this way.

There is no distinguished name attribute for which the friendly name output is activated by default.

No default RDN output in attribute lists

Maybe a good candidate for this would be the member and the memberOf attributes, this could make the group membership display more clearly. Here the result of setting the attribute "member" to be displayed with short RDN output in attribute lists:

RDN output in atribute lists for single attributes

Default configuration: In the default configuration, no DN attribute is shown in a short friendly name output in the attribute lists.