This section describes the overall structure of the server configuration, which uses Spring.
There are several options to configure ApacheDS. For instance you can practically do everything programmatically if you embed the server in a Java component.
For this guide we assume a standard installation of ApacheDS run standalone, and the default mechanism to configure this deployment option is (in almost all cases) changing the file server.xml, which is located in the conf directory of your ApacheDS instance. The file is composed of bean definitions, because configuration in ApacheDS 1.5 is done with the help of the Spring Framework.
Despite the fact that the default server.xml shipped with the product is somewhat long, a quick look with the help of the Spring IDE displays that the structure is rather simple:
Most configuration tasks can be accomplished by modifying the properties of existing bean definitions, or (e.g. for a new partition) by adding new beans of certain types and wiring them to the configuration.
Note that the picture above does not show all properties available in the configuration. Only those are visible for which the default server.xml contains a value. There are more, and in case of absence the default value is chosen. Feel free to browse the file to get an impression about further options – several other features controlled by properties are commented out.
Future versions of Directory Studio will support creation and manipulations of these configurations files. Stay tuned.
Apache Directory Server has many different configuration parameters. This page summarize all the possible parameters, and what are the default values for all of them.
The global structure is given here :
We have currently 16 possible interceptors we can use in the server. It's important to understand that some of them are mandatory, and other can be activated or disabled. The interceptors order is also very important : most of them can't be moved up or down, without severely impact the server behaviour.
Here is the list of the mandatory interceptors, and the order in which they should appears in the configuration file :
The following table represents the same interceptor in the order they must appear :
Most of all the interceptors don't take any paramter. The only possible configuration is to enable or disable them, simply by adding or removing them from the list of interceptors. Here is the list of those interceptors :
Here is an example of configuration where the aciAuthorizationInterceptor is enabled :
<defaultDirectoryService ... ... <interceptors> ... <aciAuthorizationInterceptor/> ...
Set<Authenticator> : The list of supported Authenticators. Currently, we have Anonymous, Simple and Strong authenticators. We can just list the associated beans in the server.xml file. Here is a sample of such a configuration :
<defaultDirectoryService ... ... <interceptors> ... <authenticationInterceptor> <s:property name="authenticators"> <s:set> <!-- Define a new Simple authenticator with a cache of 50 elements --> <s:bean id="simpleAuthenticator" class="org.apache.directory.server.core.authn.SimpleAuthenticator"> <s:constructor-arg value="50"/> </s:bean> <!-- Define a Strong authenticator --> <s:bean id="strongAuthenticator" class="org.apache.directory.server.core.authn.StrongAuthenticator"/> </s:set> </s:property> </authenticationInterceptor> ...
The possible values are : AnonymousAuthenticator, SimpleAuthenticator and StrongAuthenticator, out of which the SimpleAuthenticator has a possible parameter, the cache size (an integer value)
This interceptor manage the replication. It has many parameters, most of them being defined in a specific clas : ReplicationConfiguration. Let's describe those parameters.
Each instance has a name, which allows multiple instances of the server to be present on the same machine, but with possible replication between them.
First, let see an example :
<defaultDirectoryService ... ... <replicationInterceptor> <configuration> <replicationConfiguration logMaxAge="5" replicaId="instance_a" replicationInterval="2" responseTimeout="10" serverPort="10390"> <s:property name="peerReplicas"> <s:set> <s:value>instance_b@localhost:1234</s:value> <s:value>instance_c@localhost:1234</s:value> </s:set> </s:property> </replicationConfiguration> </configuration> </replicationInterceptor> ...
Here, we have set 2 replicas (instance B and C), the current instance is listening on port 10390, and we have modified the default values for logMaxAge, replicationInterval and responseTimeout.
The ReplicationConfiguration bean contains those parameters :
The peerReplicas parameter is a composite one.
This is the list of remote replicas. Each replica is defined by a name, a host address and a port. The syntax must be :
The ADS server can support more than one kind of Partition, but the default is to use JDBM. Here is the associated configuration for this underlying partition.
The main class managing the backend where entries are stored and indexed.
Six kind of parameters can be configured. Here is a table presenting each of them. Only one is a composite parameter, the JdbmIndex list, which is the list of indexes we can set for this partition
Here is an example of a partition configuration
... <jdbmPartition id="example" suffix="dc=example,dc=com" cacheSize="100" optimizerEnabled="true" syncOnWrite="true"> <indexedAttributes> ... </indexedAttributes> </jdbmPartition> ...
We have created the example partition, described by the "dc=example,dc=com" DN, with a cache of 100 objects.
Each JdbmIndex represent an index set on a specific attributeType. Using index is vital in LDAP if one want to get some performance boost. As a LDAP server is mainly used for reads, index all the AttributeType you will use to retrieve entries from the base.
Here are the parameters you can configure on an index
 Many indexes must be set on technical attributes. Right now, only OID are used for those technical attributeTypes. In a close future, we will remove them from the indexed attribute list, unless one wants to set another cache size for them
Here is an example of indexed attribute configuration for a partition
... <jdbmPartition id="example" suffix="dc=example,dc=com" cacheSize="100" optimizerEnabled="true" syncOnWrite="true"> <indexedAttributes> <jdbmIndex attributeId="220.127.116.11.4.1.18060.0.4.1.2.1" cacheSize="100"/> <jdbmIndex attributeId="18.104.22.168.4.1.18060.0.4.1.2.2" cacheSize="100"/> <jdbmIndex attributeId="22.214.171.124.4.1.18060.0.4.1.2.3" cacheSize="100"/> <jdbmIndex attributeId="126.96.36.199.4.1.18060.0.4.1.2.4" cacheSize="100"/> <jdbmIndex attributeId="188.8.131.52.4.1.18060.0.4.1.2.5" cacheSize="10"/> <jdbmIndex attributeId="184.108.40.206.4.1.18060.0.4.1.2.6" cacheSize="10"/> <jdbmIndex attributeId="220.127.116.11.4.1.18060.0.4.1.2.7" cacheSize="10"/> <jdbmIndex attributeId="ou" cacheSize="100"/> <jdbmIndex attributeId="uid" cacheSize="100"/> <jdbmIndex attributeId="objectClass" cacheSize="100"/> </indexedAttributes> </jdbmPartition> ...
We have define two indexes for the ou and uid attributeType, on top of the technical attributeTypes (all the OIDs), and the ObjectClass, obviously. The cache size is small (from 10 objects to 100 objects).
This is the directory service managing all the stored information for many protocols, including LDAP, KDC, DNS and ChangePassword.
All the supported protocols (except DHCP) are derived from the AbstractProtocolService, and all of those protocols but NTP inherit from the DirectoryBackedService.
It means that we have some common configuration shared by all the protocols. Here is the table of the AbstractProtocolService class shared parameters :
In some case, we want a protocol to be accepting connection only on UDP or only on TCP, or on both but with a different port. In these cases, we are using the following parameters, in place of the three parameters IpBackLog, IpPort, NbThreads :
And here are the DirectoryBackedService shared parameters :
Each protocol have its own configuration. The following paragraphs will describe those configurations.
Some documentation is available here
The ChangePassword server has the following parameters :
 Encryption types values
We have two sets of parameters : some are simple, some are composite. We will expose the full list first, then a description for every composite parameter the composite parameters are bold).
Those parameters are defined when using SASL Authentication.
This is a list of parameters describing the supported SASL mechanisms. Currently, the following mechanisms are supported :
The configuration file will be something like :
<ldapService> ... <!-- The list of supported authentication mechanisms. --> <saslMechanismHandlers> <simpleMechanismHandler mech-name="SIMPLE"/> <cramMd5MechanismHandler mech-name="CRAM-MD5" /> <digestMd5MechanismHandler mech-name="DIGEST-MD5" /> <gssapiMechanismHandler mech-name="GSSAPI" /> <ntlmMechanismHandler mech-name="NTLM" ntlmProviderFqcn="com.foo.Bar"/> </saslMechanismHandlers> ...
The specific parameters for each of those handlers is described here.
This parameter is used when the GSSAPI and DIGEST-MD5 authentication handlers are used (see RFC 2831). It contains the possible Quality of Protections :
Here is an example of configuration in the server.xml file :
<ldapService> ... <!-- The desired quality-of-protection, used by DIGEST-MD5 and GSSAPI. --> <saslQop> <s:value>auth</s:value> <s:value>auth-int</s:value> <s:value>auth-conf</s:value> </saslQop> ...
This parameter lists the realms serviced by this SASL host, used by DIGEST-MD5 and GSSAPI. It contains a list of host name.
Here is an example in the server.xml file :
<ldapService> ... <!-- The realms serviced by this SASL host, used by DIGEST-MD5 and GSSAPI. --> <saslRealms> <s:value>example.com</s:value> <s:value>apache.org</s:value> </saslRealms> ...
This parameter is used to list the supported extended operations. This is a highly technical parameter, and you are not likely to change it, except if you want to remove some of the extended operations for some reasons.
The syntax is simple : it's a list of all the supported classes implementing extended operations. Here is an example in the server.xml file :
<ldapService> ... <!-- the collection of extended operation handlers to install --> <extendedOperationHandlers> <startTlsHandler/> <gracefulShutdownHandler/> <launchDiagnosticUiHandler/> <!-- The Stored Procedure Extended Operation is not stable yet and it may cause security risks.--> <!--storedProcedureExtendedOperationHandler/--> </extendedOperationHandlers> ...
As you can see, the last extended operation is commented, it won't be available into this instance of the LDAP server.
Currently, the available extended operations are :
There is no specific parameter for the NtpServer. The AbstractProtocolService parameters have to be used in order to configure this server. Here is an example of configuration :
<NtpServer ipPort="60123" nbThreads="8"/>
We have a running NtpServer on localhost, waiting for incomming connection on port 60213, for TCP and UDP transports. 8 processing threads for each of the transport connectors will be used to process the incoming requests.