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 ValuesThis topic describes the Advanced tab in the LDAP Connections dialog:
You can enter a filter string here which is used for filtering the object list in the LEX main window. In the default configuration, LEX shows all objects in the object
list panel which are returned from the server. However, you can configure a filter which
is applied to the request. So if you want for example that only group objects are shown in
the list, you could display then groups in an entire subtree (a combination of setting the
correct filter and configuring the appropriate object
list scope).
If you don't enter any filter, the LDAP filter (objectClass=*) will be used for the connection, which means that objects of all classes (= ALL objects) will be shown in the list.
Even if you do not specify a filter here, you can configure the object filtering later in the application options.
You can save the current filter string into a text file, which can be loaded easily later on if you need it again. LEX stores the appropriate filter
files in the Profile and Filter Storage Path in
the subdirectory 'LDAPFilter' as text files.
You can load a previously saved filter here. LEX stores the appropriate filter
files in the Profile and Filter Storage Path in
the subdirectory 'LDAPFilter' as text files. When you use the pull down menu of this button, LEX searches this subdirectory for files and gives you the possibility to immediately load the filters without any further dialog action. Even if you never saved an LDAP filter before, there should be some filter examples which were installed together with the application.
You can structure your filter set into different categories by just saving the filters in different sub directories. LEX detect these sub directories with the filter files and shows them as a sub menu structure:
If you choose this selection for the authentication method, LEX tries to detect the correct mechanism automatically. In this detection process, LEX tries first to connect to the server with the authentication method 'Negotiate' to ensure that the user credentials are preferably transferred not in clear text over the network. If this connection attempt fails, LEX retries to connect with 'Basic' authentication. Please note that in this case the user name and password could be sniffed on the wire because they are not encrypted (unless you use SSL for the connection). Read the next topic for more information about these two authentication methods.
This approach can establish a connection in most environments, only if your server is configured to use one of the other authentication methods available for LDAP bind operations, you have to use the Auth Type parameter configurations - see the next topic for details.
You can determine the specific method which is used to authenticate the LDAP connection. The LDAP standard allows to use SASL authentication (Simple Authentication and Security Layer) mechanisms between the client and the server. This is an extensible framework to allow different authentication techniques when logon with specific credentials to an LDAP server.
The following choices are available in LEX:
So what auth type is best to choose for an existing LDAP server?
When you are in an Active Directory environment, then use Negotiate, because this is a modern and secure Kerberos authentication with the domain controller and your communication will be encrypted - no matter if you use SSL or not. If you want to have a look at the LDAP communication with a network sniffer, then use Basic instead.
If you want to connect to an ADAM / AD LDS server and you want to use the credentials of an ADAM object (no real window credentials), then you should use Digest because your username/password will be encrypted and your LDAP communication will be encrypted as well. Other authentication mechanisms which protects the user/password data and encrypts the data are not supported by ADAM / AD LDS.
On an other
LDAP server you should try to detect what authentication type is supported. Often the server publishes this information in his RootDSE entry - you can try to read it with the RootDSE button in the Server tab of the LDAP Connection dialog. Many servers have a supportedSASLMechanisms parameter which lists the supported mechanisms:
Some of the basic relations between the LDAP protocol and the SASL authentication layer is described in the RFC 4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms.
You can enter a value for the so called 'Paged Result' object search here. This is important because the normal object list is a result of an LDAP search operation.
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 (for example ADO) you use for searching. Such a limitation on the server's side is called 'MaxPageSize'.
Especially ADS domain controllers and Exchange 5.5 servers have an active
MaxPageSize 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.
The Paged Result value 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 your script you only have to ensure that the Paged Result
parameter is activated and set accordingly:
Important Information: 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 Paged Result value is higher than the detected value, then the detected value from the directory becomes the new page result value.
In Active Directory environments, you can use the Adjust button to detect the MaxPageSize limit of the regarding server and configure the correct Paged Result setting. 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.
Of course this is not possible if you are configuring a new connection where LEX does not know yet if the LDAP server is an Active Directory domain controller. But if you have an active connection and you re-open the LDAP Connection dialog (for example with the menu option Connection - Connect), you see the settings of your current connection. Then you can use the adjust button to automatically set the correct Page Result setting - after this you could save this settings to a connection profile.
You can activate this button if there are pairs of linked attributes in the regarding directory server. This could be attributes which have a backlink relationship to each other. So if you write an attribute on an object with a DN, the other (linked) attribute of this referenced object has to be written with the DN of the first object. A widely used example of such a relationship is the pair 'memberOf for users / member for groups':
If the
Automatic value handling for linked attributes is activated, LEX can evaluate the lists of linked attribute pairs, and can change the values on both sides accordingly if you access one of the linked attributes. It's similar to the memberOf overlay extensions for OpenLDAP, with the difference that LEX can handle this as an LDAP browser at the client side.
You can configure the list of linked attributes for different directory server types on the application option menu 'Linked Attributes'.On this topic, you get a detailed description of the different types of relationship for linked attributes.
Normally, you should set the Automatic value handling for linked attributes parameter in Novell eDirectory and Microsoft Active Directory environments, cause these directory servers works with backlinks and back references between DN attributes.
You can activate this button if you want to use UDP (User Datagram Protocol) as the basic transport protocol for your LDAP session. This is very dependent on the server's configuration, UDP is very seldom used for LDAP communications.
Normally LDAP servers use TCP (Transmission Control Protocol) for LDAP sessions.
This option is needed when you try to establish a LDAPS connection (LDAP over SSL) to a server but the server certificate is invalid for some reasons. Normally the connection attempt would fail in this case, but you can choose to ignore the certificate issue and nevertheless connect to this server.
At least you can have a SSL encrypted LDAP session even there is a certificate issue. But you should never forget that you cannot trust the identity of the server. Remember that the reason certificates exist is to prove the identity of the opposite communication partner!
If you encounter a certificate error message in the connection process
and choose Ignore or Ignore Always, LEX activates
this option for the connection / in the regarding connection profile.
Other details to the LDAP communication over SSL connections can be found in the topic LDAPS / LDAP over SSL, especially about the certificates which are used in the SSL communication.
If you are not sure if your server listens on the particular port, or if you reach this port through firewalls, you can check this easily by using a simple TELNET client. Although no real telnet connection can be established, a telnet client should indicate that the server is answering if you try to connect it on a particular port, for example like this:
C:\>telnet server 389
On a standard windows telnet, the screen should be cleared and turn black if the server answered on this port. If the command just times out, then you didn't reach the server.
Another easy trick to check if the server is basically reachable is to use the RootDSE button (read the following annotations to get more information about this).
