Reload Attribute Info
Compare this Object with another
Add New Attribute
Add Attribute Element to an Array
Remove Attribute
Show only Attributes that have Values
Show Friendly Object Names
Show Distinguished Name in Novell Notation
Show Hex Output for Hex Values
Show Multivalued Attributes
Set Attribute List Filter
Show Attribute Names and ValuesIn this dialog, you can configure some LDAP settings according the connection and the LDAP related information output.
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:
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
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:
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.
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:
This option is only available if LEX could evaluate the directory schema of the regarding LDAP server correctly.
Default configuration: Active
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:
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:
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
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.
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
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:
HKLM\System\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias
Default configuration: Active
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:
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
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:
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.
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:
Default configuration: In the default configuration, no DN attribute is shown in a short friendly name output in the attribute lists.
