21 Apr 2015
April 21, 2015

ApacheDS Install

April 21, 2015 Apache, Blog 0 Comment

Installing ApacheDS

You can acquire the Apache DS download and installation instructions from http://directory.apache.org/. There are versions available or all major platforms and the documentation is very good. For my installation I have used version 2.0.0-M19 for Linux, which is the latest version available at the time of writing, April 2015.

Once you have downloaded and installed ApacheDS we will need to make some configuration changes for use as and example. To do so, we now need to download and install an LDAP client so we can administer our ApacheDS LDAP sever. To do this, we will use the ApacheDS Eclipse-based admin tool called Apache Directory Studio (ADS), which can be downloaded here: http://directory.apache.org/studio.

In this example, I will be using ADS for Windows installed on my Windows desktop. This set of steps is just an example to show how easy it is to setup ApacheDS as your LDAP Server.

I uploaded the installation to /var/apps/installs/ApacheDS on my CentOS 7 Virtual Machine running in Virtual Box

I then ran the following RPM command to install the software

rpm -ivh ./apacheds-2.0.0-M19-x86_64.rpm


Preparing… ################################# [100%]
Updating / installing…
1:apacheds-2.0.0_M19-1 ################################# [100%]


When we issue a find command to locate apacheds we can see the location of the install

find / -name apacheds



The structure of the folder is as follows:

Consult the documentation on the site for more information about the ApacheDS file-structure: https://directory.apache.org/apacheds/advanced-ug/5.1-layout.html

You need to ensure that you have JRE available I installed Open JDK by using yum install java

We then need to do a little work to figure out how to run apacheds. Firstly we need to ensure that ApacheDS knows where java is located. I have used OpenJDK, using a yum install.

yum install java

This command will install OpenJDK, which is sufficient for our needs.

We now need to edit the wrapper.conf file which defines where the JRE is located.

The wrapper.conf is located in /var/lib/apacheds-2.0.0_M19/default/conf/

We need to add a line that defines the location of java. I have used the command which java

And it reports that java is found in the location: /usr/bin/java

  • Edit the wrapper.conf file as follows:

Note: Use which java to determine path to java

The default configuration loaded is located here, but we will not be looking into this ldif file as we will create our own directory partition using Apache Directory Studio.

  • We also need to open up the firewall on our Linux Server (CentOS 7) for the LDAP protocol
firewall-cmd –zone=public –add-port=10389/tcp –permanent
  • Restart the firewall
firewall-cmd –reload
  • Using the following command in CentOS 7 we can start ApacheDS
/etc/init.d/apacheds-2.0.0_M19-default start

Note: To stop change start to stop

  • We can then issue a netstat command to verify that ApacheDS is listening
netstat -an | grep 10389


tcp6 0 0 :::10389 :::* LISTEN

We can now install Apache Directory Studio and connect to your new LDAP Directory.


  • Download and install Apache Directory Studio (ADS) on to a Windows Desktop (this mimics how you would administer in the real world. We will connect remotely to the LDAP server and then configure our directory to suit our needs.

Once loaded, ADS will present a welcome page.


Close the welcome screen and create a new connection to our new ApacheDS LDAP server which will allow us to administer the LDAP directory.

  • From the main menu choose File-New
  • Select LDAP Connection

Click Next

On the New LDAP Connection screen, fill in the Connection name, Hostname and Port as shown below.

  • Click on the Check Network Parameter button to test the network connection to the LDAP server.
  • Once you have a successful connection, then click Next

On the next screen, we will enter uid=admin,ou=system into the Bind DN or user field, and enter secret into the Bind password field. These are the default values for the default instance that we are connecting to.

Note: By default Apache DS provides a default instance, and that instance has a default partition of data i.e. an LDAP directory which we are connecting to.

Open the connection to the running LDAP server

Once connected we will see the default partition in the LDAP browser as sown below


The default partition is called dc=example, dc-system as shown above. We can see the admin user which we used to log into the LDAP server i.e. uid=admin, ou=system,dc=example,dc=com. Now we will create a new partition, then restart the server to take effect


Adding a new partition

We do not want to sue the default example partition, instead we will create our own. We do this for two reasons.

  1. At the time of writing, there are no succinct articles on the internet that show how to do this using the level of detail we are covering here in this guide. Especially how to use Apache DS as an LDAP sever for WAS.
  2. It is more akin to a production setup, when we use our own directory.


It is not recommended that you do not use the default tree starting at dc=example,dc=com. The reason is that with this tree, is the uid=admin,ou=system user is a special admin user user created in the default instance, and though can be used as an LDAP Bind user by WebSphere, Application Server it is not a good idea to use the directory’s admin user. By creating a new tree, we can understand more about how our tree design affects LDAP configurations in WAS. So, with this in mind we are going to create a new partition called dc=themiddlewareshop,dc=com as shown in the screen capture below. It will have one LDAP Bind account called uid=wasldapbind, a group called wasadmins, a group called wasdeployers, a group called applogin and four users. Three users are people and one user will be wasadmin, which is a special account for WAS to use as the Primary Administrator ID for Global Security/LDAP configurations.


Below is a table of the data we are creating on our directory i.e. our users, and groups.

DN (Distinguished Name) Role/Description
dc=themiddlewareshop,dc=com Partition name
ou=groups,ou=system,dc=themiddlewareshop,dc=com This is a group organizational unit for categorizing our groups
ou=users,ou=system,dc=themiddlewareshop,dc=com This is a group organizational unit for categorizing our users
uid=wasldapbind,ou=system,dc=themiddlewareshop,dc=com The user WAS will use to connect to the LDAP server i.e. LDAP Bind.
uid=wasadmin,ou=users,ou=system,dc=themiddlewareshop,dc=com Special non “Person/Security” account which WAS will use as the primary administrative account
uid=bobjackson+cn=Bob+sn=Jackson,ou=users,ou=system,dc=themiddlewareshop,dc=com User
Group of users that can log into a test application
Group of users who can deploy applications.
Limited WAS administrative capability
cn=wasadmins,ou=groups,ou=system,dc=themiddlewareshop,dc=com Group of WAS admins, with Full administrative capability


Table of Group membership we wish to create.

Group CN Members (UIDs) Object Class
applogin uid=davidcharles
wasdeployers uid=bobjackson inetOrgPerson
wasadmins uid=wasadmin Account


Creating the partition

Follw these steps to create the new partition

  • Right-click on the LDAP Server Connection


Click the Partitions tab, or click the Advanced Partitions configuration link

  • In the partitions page, fill in the ID with “The Middleware Shop” and the Suffix field to be “dc=themiddlewareshop,dc=com“, then click then close the page, by clicking the close “X” on the left-hand-side top corner, tab as shown in the image below.
  • Save the changes

  • Close the connection, so that we can restart the LDAP server.

The LDAP server must be restarted for partition changes to take effect.

  • Issue the stop command
  • Then, once stopped, issue the start command

Now we can log back in to the LDAP server using ADS. We will see a new partition in the LDAP Browser.

In LDAP, an object class defines the collection of attributes that can be used to define an entry. The LDAP standard provides these basic types of object classes:

  • Groups in the directory, including unordered lists of individual objects
    or groups of objects
  • Locations, such as the country name and description
  • Organizations in the directory
  • People in the directory

For instance, the commonName, or cn, attribute is used to store a person’s name. For example, a person named Bob Jackson might be represented in a directory as:

cn=Bob Jackson or cn=Bob, sn=Jackson or commonname

We are now going to manually populate the contents of this directory. First we will add the OUs. Then progress with adding users, then group and populating groups.

Creating OUs

  • Right-click on the new partition and select New->New Entry

On the Entry Creation Method screen, choose Create entry from scratch, and then click Next to continue.

On the New Entry Screen, type “o” to drill down to objects with names starting with “o” and select organizationalUnit, then click Add.


Click Next, then type ou in the RDN (Relative Distinguished Name) field. Then type system in the corresponding value field


Click Next


We can see that the objectClass is organizationalUnit. We can now add entries beneath this RDN to create further hierarchical RDNs. Hence the term LDAP tree.

Click Finish

The result will be a new ou (ou=system) added to the partition tree, as seen below


Now add two other ou’s called Groups and Users underneath system. Follow the same process as above.


Directly under the System OU, we will add a user called wasldapbind, this user is explained in the table of names we looked at earlier.

Adding Users

  • We use the same right-click to create a new entry

In the Object Classes screen you will need to select two object classes from the left-hand-side list of object classes. Scroll or search for inetOrgPerson and click the Add button to populate the right-hand Selected object classes list as show below. Essentially we are defining a schema of required attributes needed to define users.





Click Next to progress to the Distinguished Name screen. In this screen you will fill in attribute details required to populate a new user entry. In the RDN section, we can now add entries for fields such the cn, sn and uid attributes as defined by the assigned objectClass, then populate these attributes accordingly.

Enter uid in th RDN field and wasldapbind in the value field as shown above, then click next.


In this example, I did not want to provide a cn, and sn entry, but since they are mandatory objectClass attributes, we can add “” for null.

If you fill out the cn and sn fields, then you will need to specify them in the LDAP Bind in WAS. To make it simpler, I shorten the DN (Distinguished Name) a bit by adding nulls.

Now we wish to create the three people, to do this we select the users OU and add the following new entries that use the inetOrgPerson objectClass.

uid=bobjackson+cn=Bob+sn=Jackson,ou=users,ou=system,dc=themiddlewareshop,dc=com User

Below is a view of the process followed for each user

  • Create a new entry
  • Apply the inetOrgPerson objectclass
  • Fill out the uid, cn, and sn attributes


In the example image above, we have just done is create a user (person object) called Bob Jackson with a uid attribute with the value of bobjackson which we will use as a Bob’s username in WebSphere.

Click Finish to Save

Once the new entry has been added, we edit the entry to add a password.

Right-mouse click on a new grid row

Type user in the Attribute type field to search for attributes matching user as seen below

Click Next, then Finish, and you will be presented with the following Password Editor screen:

Type bobjackson as the password and click OK.

Repeat this action for the other two users.

The result being:


We have essentially created three new users (people). Before we finish, we need to add a special user known as an account user. This is asecurity ID that will be used by WAS as the Primary Administrative ID when we set up LDAP in WAS.

  • Add a new entry, but this time select the account, and simpleSecurityObject objectClasses as shown below


Fill in the uid attribute with the value wasadmin


Click Next, to automatically prompted to add a password. Set the password to wasadmin.

Click OK, then Finish

The resulting LDAP tree should now look like the following image

We have completed adding users, now we need to look at how to create groups and assign users to these groups.

Creating a Group

Groups are simple to create, all we do is add a new entry to the appropriate OU, assign an appropriate objectClass for example groupOfNames then we assign the group a CN.

Create a new entry in the Groups OU, and assign the groupOfNames objectClass.

Click Next and fill out the cn attribute for example wasadmins

Click Next and Browse to add members


Click Finish, and the result should look something like below

Repeat this process until you have completed this table of groups and memberships

Group CN Members (UIDs)
applogin uid=davidcharles
wasdeployers uid=bobjackson
wasadmins uid=wasadmin

The resulting tree will look like the image below


We have now completed setting up our partition for use with WAS LDAP configurations learning how to use role-bases mappings in the console and also later applications.

LDIF Contents

It is possible to import and export LDIF files (.ldif) from Apache Directory Studio. This is very convenient for you to import existing trees. You could in fact create the above partition by creating a file using the contents from the file below.

Note: I have provided this file for download as part of the packaged guides.

For informational purposes, the exported LDIF file of the dc=themiddlewareshop,dc=com tree is as follows:

version: 1
dn: uid=maryroberts+cn=Mary+sn=Roberts,ou=users,ou=system,dc=themiddlewaresh
objectClass: top
objectClass: inetOrgPerson

objectClass: person

objectClass: organizationalPerson

cn: Mary

sn: Roberts

uid: maryroberts

userPassword:: e1NTSEF9QlhKV01MekFDdHpxa204YW5iZmFRenhvS0hUbkN4WWZxcS9qZHc9P



dn: uid=bobjackson+cn=Bob+sn=Jackson,ou=users,ou=system,dc=themiddlewareshop


objectClass: top

objectClass: inetOrgPerson

objectClass: person

objectClass: organizationalPerson

cn: Bob

sn: Jackson

uid: bobjackson


dn: ou=groups,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: organizationalUnit

ou: groups


dn: dc=themiddlewareshop,dc=com

objectclass: top

objectclass: domain

dc: themiddlewareshop


dn: uid=wasadmin,ou=users,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: simpleSecurityObject

objectClass: account

uid: wasadmin

userPassword:: e1NTSEF9K3N0aC9LcHNxc2NZOUw1U3owc3NmYVo0MXFUa0o3RjNxbmRmSlE9P



dn: ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: organizationalUnit

ou: system


dn: cn=wasdeployers,ou=groups,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: groupOfNames

cn: wasdeployers

member: uid=bobjackson+cn=Bob+sn=Jackson,ou=users,ou=system,dc=themiddleware



dn: cn=applogin,ou=groups,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: groupOfNames

cn: applogin

member: uid=davidcharles+cn=David+sn=Charles,ou=users,ou=system,dc=themiddle



dn: ou=users,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: organizationalUnit

ou: users


dn: cn=wasadmins,ou=groups,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: groupOfNames

cn: wasadmins

member: uid=wasadmin,ou=users,ou=system,dc=themiddlewareshop,dc=com


dn: uid=wasldapbind,ou=system,dc=themiddlewareshop,dc=com

objectClass: top

objectClass: inetOrgPerson

objectClass: person

objectClass: organizationalPerson

cn: “”

sn: “”

uid: wasldapbind


dn: uid=davidcharles+cn=David+sn=Charles,ou=users,ou=system,dc=themiddleware


objectClass: top

objectClass: inetOrgPerson

objectClass: person

objectClass: organizationalPerson

cn: David

sn: Charles

uid: davidcharles

userPassword:: e1NTSEF9TUhsNGpsYmJacnVCZ01MTWVmOWlmeEtlRUNBMndTc3lZVHJiMXc9P




Leave a Reply