Connecting LDAP to your EnterpriseOne environment increases the speed and efficiency of your systems. Here are answers to the common questions surrounding this implementation.
Lightweight Directory Access Protocol, or LDAP for short, was an early 90's open source project led by Tim Howes of the University of Michigan- the same institution which just implemented the first-ever automated shuttle service on campus. As of today, there are many versions of LDAP including OpenLDAP, ApacheDS, OpenDJ, 389 Directory Server, and more. There are even tools built on the protocol, such as Microsoft’s Active Directory, which sits on top of LDAP like HTTP sits on top of TCP. People sometimes think that one either uses LDAP or they use Active Directory, but not both. This is not the case.
LDAP stores information about user authentication, authorization, computers, printers, servers and other IT assets. You could think that this information is stored in a centralized database, but that would technically be incorrect because, as the name implies, the data is actually stored in a lightweight directory. The primary advantage of LDAP is that its storage approach doesn't contain any rows, tables or other database attributes, though it does store data. Unlike the relational data storage of a database however, LDAP stores data in a hierarchical format. This makes it much faster than storing data in a relational database.
In order to access this data, a process is made available on an IT asset to interact with your domain controller. In geek speak, the IT asset uses port 389 to send an information request to a Directory System Agent (DSA).
Each application used in coordination with EnterpriseOne (E1) requires the validation of a user ID and digital signature. Since these queries can quickly become a processing bottleneck, E1 can instead leverage LDAP which allows it to offload user validation workloads and gain significant performance improvement. If you are a company suffering from performance issues, this is a low hanging fruit. In addition, companies that use LDAP for many applications can also use it for JDE, thereby eliminating the need for both administrators and users to add, delete and make regular password changes in both places.
Active Directory (AD) is a creation of Microsoft and requires a domain controller. AD leverages a newer network authentication protocol called Kerberos.In addition to providing active directory functionality, it also provides LDAP services. Sweet right?
Obviously, since it's a Microsoft product, AD is used mostly in Windows environments, whereas LDAP can work outside of the Windows world with systems like Unix and Linux. This interconnectivity makes AD a very valuable resource to technical applications like Oracle’s EnterpriseOne (E1).
If you are not a savvy networking geek, you may have some confusion about this initiative. For example, you may see that E1 works with LDAP, and you know that your company uses AD. So you may spend some time researching if E1 works with directly with AD, but the search results don’t really give an answer. Well, I'm here to tell you that AD does indeed work with E1. As mentioned earlier, AD is built upon LDAP, and this is the protocol you will use to get E1 to talk to AD.
Enabling LDAP with E1 has nothing to do with Single Sign On (SSO). SSO is strictly about providing access to applications via a portal, so let’s save that for another day.
The first thing you should know about this initiative is that it's nothing like an E1 implementation. Whew! There'll be no need to visit a doctor and beg for anxiety pills! In fact the E1/LDAP integration is relatively simple, with the changes needed being made offline and only taking effect once you restart the E1 servers.
Additionally, most people want to know how long it will take to get an E1/LDAP integration up and running. On average, it takes a couple of meetings and a quiet weekend in which the E1 servers can be shut down. But since each environment is different, it really depends upon how many users, domains exist, and which type of data you want to sync, so it could take a bit longer.
It is also important to note that the maintenance of users is not as easy as just deleting them from E1. Since the users are being maintained in AD, they need to be deleted in there. Once you do delete them in AD, you must understand that they do not automatically get deleted in E1.
Never fear though, Oracle offers a work around to clean them out.
Steps to Clean Up Deleted Users
If you do not wish to disable the LDAP, Oracle also offers you an LDAP bulk synchronization UBE (R9200040) and instructions for using it. You can also add this task to the job scheduler or use a third-party application, which makes process this very easy.
In addition, you must note if LDAP is managing roles and, if you delete a role, that it will get deleted from E1 the next time the user logs into the software.
The security kernel uses the below information:
As far as user training goes after the E1/LDAP integration, your users will need to be educated that they will no longer be able to change their passwords via the E1 'change password' field. Instead, they will need to contact the help desk to get this accomplished, which keeps higher levels of security and compliance for the organization.
The are many benefits to implementing LDAP in E1, including improving overall system performance and reducing complexity when managing users across multiple applications. With a relatively short and painless integration process, we think it's an E1 initiative well worth undertaking.
Let us know if you have questions or need assistance with your E1/LDAP integration, or any other E1 initiative. We're here to help!