In this article, I would like to explain how LDAP proxy is a way to migrate “unmigratable” applications.
The subject matters especially for critical legacy applications which have to be changed in the context of a Novell Migration.
So let’s start the step-by-step tutorial for OpenLDAP proxy.
Index
Migrating Novell eDirectory to Active Directory
Over the last few years more and more companies and organizations have moved from Novell eDirectory to Microsoft Active Directory.
In most cases the aim of the migration is to shut down the old directory service completely. At the same time all functions are to be transferred to the new directory service.
Unfortunately there are sometimes legacy applications in place which are critical to the production. These applications were especially designed for eDirectory.
Let’s assume that you have those kinds of legacy applications running. In other words, you are not able to migrate them to your new Active Directory. So there must be a way to settle things. This article will show you how to use a LDAP proxy to migrate these applications to AD.
Initial Situation
Recently a customer wanted to migrate hundreds of legacy applications from eDirectory to Active Directory in no time. Unfortunately those applications authenticated against the old system only. To adjust all these applications manually was no option due to time constraints. However, we knew that all of them used the same DNS record for accessing eDirectory.
Changing DNS record impossible!?
The first idea that struck our specialists’ mind was to test whether the DNS record can be authenticated against the Active Directory directly. This didn’t work for the following reasons:
Some of the reasons it did not work:
- Anonymous access: First, the applications do an anonymous bind to find the DistinguishedName of the user. Next, they run a simple bind with the DistinguishedName and the password you entered. But the customer didn’t want to grant public anonymous access to the company’s AD.
- No Searchbase: With eDirectory it is possible to do a LDAP query without a fixed searchbase. That is why the applications just passed an empty string.
Solution with OpenLDAP proxy
The OpenLDAP proxy is the solution to both problems at once. OpenLDAP allows Anonymous Binds by default, but it doesn’t need changes in your Active Directory. Even though the access to a proxy works anonymously, the actual bind against the Active Directory is proceeded by a service account. This makes it easy to control who accesses “anonymously” the Active Directory.
Additionally, Open-LDAP allows you to set a “Default Searchbase”. This one will be used automatically if no search base is transmitted.
Preparing OpenLDAP
OpenLDAP is an open source LDAP solution and can be downloaded for free. To set it as a proxy is fairly easy. You just need the following few resources:
- Linux server
- Openldap Package for Linux
- Active Directory
- Service Account in Active Directory (no special rights needed if you just want to read data)
FirstAttribute AG – Microsoft Consulting Partner for
Migration and Active Directory
Looking at the Test Environment
The IP 192.168.1.11 refers to the first domain controller (DC) of the test domain “Sanctuary”. The DC runs on a notebook (in a virtual machine) and is located in the local network.
The Linux server has the IP 192.168.1.1 and is Gateway and DNS server at the same time. (see screenshot).
Implementing the Solution
For the test environment I used ArchLinux because I already had set up a server on a Raspberry Pi at home. The installation should be pretty much the same for all Linux distributions.
[root@piserv1 ~]# pacman -Sy openldap
If you want to configure LDAP proxy you have to change the „splad.conf“ file. But first you should do a backup of the file.
[root@piserv1 ~]# mv /etc/openldap/slapd.conf /etc/openldap/slapd.conf.backup
So you will create a new „slapd.conf“ with this content:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
loglevel none
modulepath /usr/lib/openldap
moduleload back_ldap
sizelimit 500
tool-threads 1
defaultsearchbase “<dn of my domain>”
backend ldap
database ldap
suffix “<dn of my domain>”
uri ldap://<IP or DNS name of my domain>:389
rebind-as-user
idassert-bind bindmethod=simple
binddn=”<dn of my service user in AD>”
credentials=”<password of my service user in AD>”
mode=none
idassert-authzFrom “*”
[root@piserv1 ~]# nano /etc/openldap/slapd.conf
After saving the file you need to delete all data from the directory /etc/openldap/slapd.d/ :
[root@piserv1 ~]# rm -r /etc/openldap/slapd.d/*
Warning: This will delete all directories and all datababases on the OpenLDAP!
Next you set up a new configuration with the command“slaptest”:
[root@piserv1 ~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
As you executed the last command in root mode you have to register the user „Idap“ as owner of all files in the directory “/etc/openldap/slapd.d”:
[root@piserv1 ~]# chown -R ldap: /etc/openldap/slapd.d/
To activate the proxy you have to restart the „slapd“ service:
[root@piserv1 ~]# systemctl restart slapd
That’s it. Your proxy is now ready to use.
Testing
To test the solution you can use the tool “ldp.exe”. For a connection to a LDAP directory you click “Connection” and “Connect…”
Next you type in the IP of your proxy:
You see a link to an OpenLDAP directory:
Next you run a bind by clicking on „Connection“ and „Bind…“. For the authentification method you have to choose “simple bind”:
Important: With a simple bind you always have to type in the DistinguishedName of the user!
Now the authentification works just fine:
If you want to browse the directory you click „View“ and „Tree…“:
Enter the DistinguishedName of the domain like this:
Finally you can browse the directory:
This of course work with every LDAP browser, like i.e. Softerra LDAP browser:
Same routine with Softerra. The anonymous access works as well:
Conclusion
This is just a brief overview of the possibilities LDAP proxies offer. There are even more tricks that help you to migrate to Active Directory – even if it seems impossible to migrate the applications.
Stick to the plan and you finally have a fair chance. You can easily resolve your legacy application issues with Active Directory migration.
This article shows you LDAP proxy as one way for “unmigratable” applications. I hope this can help you a bit and to give your search of a solution for legacy applications in an AD migration a glimmer of hope.
FirstAttribute AG – Microsoft Consulting Partner for
Migration and Active Directory
Leave a Reply
<p>Your email is safe with us.<br/>Information about our <a href="https://activedirectoryfaq.com/contact-us/">data protection policies</a></p>