Printout Header

LEX Online Manual Content

The LDAP Connections Dialog - Server

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

Connections dialog - Server tab


You have to enter here the network name or address of the LDAP server you want to connect to. If you enter a server name here and the connection fails, you can check with the PING utility if your name can be resolved into a valid IP address.


You have to enter the communication port which is used for the LDAP connection.

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


This button can only be used if you entered a server name and communication port before. Then you can examine the RootDSE entry values, which are showed in an attribute window:

RootDSE entry of a Microsoft Active Directory LDAP server

RootDSE is the abbreviation for Root Directory Service Entry. This is a special pseudo object which holds general information about the LDAP directory and server. This information is stored in text attributes in the RootDSE. Normally the RootDSE entry can be read even for anonymous clients.

Common details you can evaluate in the RootDSE are the name spaces which ar published by the server, the manufacturer/version of the server software, the extensions/controls which are supported by the server and so on.

The RootDSE and its structure are described in RFC 4512 - LDAP: Directory Information Models. On the LDAP description of the SelfADSI tutorial web site, you can find detailed explanations about the technical access on the RootDSE entry in general.

Some important values of the supportedCapabilities and supportedControl attributes:


This function can help you find LDAP servers in your environment if you don't know the server's name or address. It only works for two kinds of LDAP directories and only under certain conditions:

  • Microsoft Active Directory (as a domain member): LEX can find AD domain controllers if your station is currently member of a domain and any domain controller of this domain can be contacted. In this case, LEX reads the structural forest information from the Configuration Partition. As a result, you can pick an LDAP server from a complete list of all domain controllers in the forest. Even the information about sites, root domain controllers and global catalogs are visible. The domain controller which you currently use as the logon server is marked in the 'Current Logon' column.

    Detection of LDAP servers

  • Microsoft Active Directory: If your station is NOT member of an Active Directory domain, then LEX tries to search domain controllers with DNS (there has to be a SRV service record in the appropriate DNS zones for every AD domain controller). All DNS domain name suffices which are configured somewhere in your machine's TCP/IP configuration is used for that. You can enter an additional DNS domain name in the Server text box, LEX will try to search the regarding information in this domain name as well. Please note that LEX can only request SRV records for a given namespace if the responsible DNS server allows the transfer of zone information to your LEX station.

  • Novell eDirectory: LEX tries to detect some Novell NetWare server names in your local registry - assuming that one of these servers could be an active LDAP server. Please note that this method is very basic and can only work on machines where an Novell Client is installed. The following registry keys will be evaluated:
    HKEY_LOCAL_MACHINE\SOFTWARE\Novell\NWGINA\Login Screen\DefaultBinderyServer
    HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login\History\Preferred Servers\


If you want to use LDAP over SSL / LDAPS, you have to activate this option. In this case, all the LDAP communication between your machine and the LDAP server is encrypted with Secure Socket Layer (SSL) techniques.

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.

User / Pass

You can enter the credentials for the LDAP connection here. The process of logon to an server is called 'bind' in LDAP terminology. So we have to make a bind operation before we can access the directory content.

LDAP bind credentials are often requested to be distinguished names, for example:


In most cases this is the distinguished name of a user object which is stored in the regarding directory. But there are also server which have to be authenticated with distinguished names that have nothing to do with the directory content.

Once again, the situation in Active Directory environments is slightly different. Among the distinguished name syntax for a credential, you can also use the windows specific logon names, for example:

(the 'old' NetBIOS name, you can try it even without the domain name)
(the 'modern' user principal name UPN)

LDAP bind operations can be performed without credentials, this is called an anonymous bind. Depending on the servers configuration, it could be allowed to access the directory without any user id and password. This is important for directories which operates as public 'yellow pages' or address books for email systems. You can read interesting details about this in the SelfADSI Tutorial topic LDAP Bind as Anonymous.

Use current creds

If you activate this option, you use your current Windows credentials for the LDAP bind authentication. So you don't have to enter any user names and passwords. Please note that the Windows credentials can probably used only in Active Directory environments. Other LDAP server will in all likelihood NOT accept your current credentials.

Anonymous bind

If you activate this option, the connection will be established as an anonymous user. LDAP bind operations can be performed without credentials, this is called an anonymous bind.

Depending on the servers configuration, it could be allowed to access the directory without any user id and password. This is important for directories which operates as public 'yellow pages' or address books for email systems. You can read interesting details about this in the SelfADSI Tutorial topic LDAP Bind as Anonymous.


You have to enter the distinguished name of the LDAP container which provides the hierarchical base for the browsing tree in the LEX main window. Typically you will browse an entire LDAP hierarchy, a so called 'directory namespace'. An LDAP server can hold one or several name spaces which. So what you need then is the distinguished name of the namespace's root container.

A distinguished name (DN) has always a syntax which is similar to these:



There is a detailed description about distinguished names in the SelfADSI Tutorial.


Normally LDAP announce the namespaces they hold for everyone in the RootDSE entry. If you use this button, LEX tries to read this entry from the server and detect all the possible distinguished names which can fit as the LDAP Base DN for the connection. If some values are found, the Fetch Base DN dialog appears with a list where you can pick the desired DN from:

Automatic Fetch of Namespaces

Please note that not only the published namespaces from the RootDSE are visible in the list, but also other important LDAP bases, for example the Configuration and Schema partition DNs in Active Directory environments, or the SubSchema entry where all the directory schema information is bundled into one singe object.