Printout Header
LEX RSS Feed

LEX Online Manual Content

The LDAP Connections Dialog - Advanced

This topic describes the Advanced tab in the LDAP Connections dialog:


Connections dialog - Advanced tab



Objectlist Filter


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.



Save


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.



Load


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.

Loading pre-defined LDAP filters

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:

LDAP filters in a structured hierarchy




Authentication Type Autodiscovery


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.



Auth Type


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:

  1. Anonymous: A bind without any credentials/with empty credentials. Actually this is not a real SASL auth type, it's just a bind operation to the server without a real logon. Normally you don't need to choose this method explicitly because if you want to connect as an anonymous user to the server without credentials, you would configure this on the Server tab of the LDAP connection dialog. In this case the setting here is done automatically by LEX.

  2. Basic: This performs a 'Simple Bind' on the given LDAP server. It is the only authentication mechanism which is explicitly described in the LDAP protocol standard and almost every LDAP server implements it. However - there is a disadvantage for the Basic Auth: The username and password are transferred in clear text to the server. therefore this insecure method should only be used if the complete LDAP session is protected by LDAPS / LDAP over SSL.

  3. Digest: This performs a 'Digest MD5' authentication, which is supported b many LDAP server systems like OpenLDAP, Novell eDirectory, OpenLDAP and others. In Digest authentications, username and password are transferred encrypted to the server. Additionally, all the LDAP communication will be encrypted - even if you don't use SSL.

  4. DPA: This performs a 'Distributed Password Authentication' on the given LDAP server. It's a mechanism similar to the MSN auth and it's used in website authentication rather than for LDAP connections. So it's very unlikely that you will need this.

  5. External: This performs a certificate-based authentication to the LDAP server - for example with a token card or another hardware-based certificate solution. LEX cannot handle this by itself, you need specific drivers that intercept an external authentication attempt and provide the user certificate at this point.

  6. Kerberos: This performs an Kerberos authentication with a non-AD LDAP server which supports Kerberos. Internally a security API named GSSAPI (Generic Security Services Application Program Interface) is used for this.

  7. MSN: A Microsoft based authentication based on a MSN account (the Microsoft Network Authentication Service is needed for this). It's used in website authentication rather than for LDAP connections. So it's very unlikely that you will need this.

  8. Negotiate: This performs a negotiation about the mechanisms used for the authentication. This auth type is only used in environments where a real windows credential can be used to logon to the LDAP server - this means Active Directory. There is the choice between a Kerberos and a NTLM authentication, in almost every case Kerberos will be chosen by the internal negotiation process. This use the security API named GSS-SPNEGO (GSS API Negotiation). The good thing about the Negotiation auths: Username and password are transferred encrypted to the server. Additionally, all the LDAP communication will be encrypted - even if you don't use SSL.

  9. NTLM: This performs a 'NT LanManager' authentication, which is supported not only by Windows but also in other LDAP server systems, for example OpenLDAP. Normally, you have to provide the credentials like this: 'domain\username'. In NTLM authentications, username and password are transferred encrypted to the server.

  10. Sicily: This performs a Sicily authentication, a Microsoft proprietary method which is similar to SASL. The only technical authentication which can be performed with a Sicily auth is NTLM, and the only environment where it can be used is Active directory - so you wont ever use it because Negotiate would be the better choice by far.

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:

SASL meachnisms in the RootDSE entry

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.



Paged Results


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:

  • 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. If you know the exact MaxPageSize value for a particular server, then you can use this value as a Paged Result parameter.

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.



Adjust


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.



Automatic value handling for linked attributes


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':

Linked attribute handling

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.



Connectionless communication


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.



Ignore server certificate errors


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

Invalid Cert error message

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.

The standard LDAP connection is made with TCP on port 389 - or 636 if you want to use an LDAPS connection (LDAP over SSL - Secure Socket Layer, see annotations below).

Depending on the servers configuration, every other port number could be used for the LDAP communication. Only in Active Directory environments, the LDAP communication port is fixed to these values:

389    - Standard LDAP access
636    - Standard LDAP access over SSL
3268  - GC (Global Catalog) access
3269  - GC (Global Catalog) access over SSL

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).