The Lightweight Directory Access Protocol, or LDAP for short, is one of the core

protocols that was developed for directory services. According to Chron.com, LDAP is
used to distribute lists of information organized into directory information trees, which
are stored within an LDAP database. However, in order to access information stored
within an LDAP database, the user must first authenticate their identity. What is LDAP
authentication? Continue reading for the answer to this question, and to learn how the
JumpCloud® Directory-as-a-Service® platform can deliver LDAP authentication as a
cloud-based service.
Origins of LDAP
LDAP authentication follows the client/server model. In this scenario, the client is
generally an LDAP-ready system or application that is requesting information from an
associated LDAP database and the server is, of course, the LDAP server. The server
side of LDAP is a database that has a flexible schema. In other words, not only can
LDAP store username and password information, but it can also store a variety of
attributes including address, telephone number, group associations, and more. As a
result, a common LDAP use case is to store core user identities.
In doing so, IT can point LDAP-enabled systems and applications (for example) to an
associated LDAP directory database, which acts as the source of truth for
authenticating user access. So, how does LDAP authentication between a client and
server work? In short, a client sends a request for information stored within an LDAP
database along with the user’s credentials to an LDAP server. The LDAP server then
authenticates the credentials submitted by the user against their core user identity,
which is stored in the LDAP database. If the credentials submitted by the user match
the credentials associated with their core user identity that is stored within the LDAP
database, the client is granted access and receives the requested information. If not,
the client is denied access to the LDAP database.
While LDAP authentication has certainly proven to be effective, the amount of time
required to implement and customize LDAP-based infrastructure to meet a modern
organization’s identity management needs can be significant. Historically, LDAP has
also been an on-prem implementation, requiring dedicated servers that must to be
integrated into an organization’s overall identity management infrastructure (which has
also historically been on-prem). This type of setup can be difficult to achieve, especially
for smaller or cloud-forward IT organizations. After all, most modern organizations
would like to shift their entire on-prem identity management infrastructure to the cloud.
However, as more organizations replace their traditional on-prem infrastructure with
cloud alternatives, the question becomes, “How do I provide LDAP authentication
without anything on-prem?”

Adding a few more questions from technical side.

 LDAP - Is integration with LDAP available ? Does software provides facility for
Single Sign on .
>> We do not have any LDAP readily available but it is feasible. It will be customization
based on the LDAP service chosen by the organization. If this is limited to HRMS
integration for the moment, we can estimate for that alone separately.

LDAP:

LDAP user authentication is the process of validating a username and

password combination with a directory server such MS Active Directory

LDAP directories are standard technology for storaging user, group and
permission information and serving that to applications in the enterprise.

Authenticating users with an LDAP directory is a two-step process.

uid=alice,ou=people,dc=wonderland,dc=net

In order to authenticate a user with an LDAP directory you first need to obtain
their DN as well as their password.
With a login form, people typically enter a simple identifier such as their
username or email address. You don’t expect them to memorise the DN of
their directory entry. That would be impractical.
To solve this issue a DN resolution comes in. It takes the user’s name or
email, then runs a search against the name or email attributes of all user
entries to find the matching entry DN. Directories employ highly efficient
indexing and caching, so these searches are typically very fast.
 The directory attributes to search for are defined in the searchFilter
configuration parameter. The default LdapAuth configuration searches the
UID and email attributes. The %u placeholder is substituted with the user
identifier entered in the login form:
ldapAuth.dnResolution.searchFilter = (|(uid=%u)(mail=%u))

Two important things to observe when configuring DN resolution and creating

new user entries in the directory:
 The attributes – username, email, etc – with which users login must be
unique. If two entries are found to have the same identifying attribute, e.g.
email, authentication will be promptly denied.
 Make sure every user who is expected to login has a defined attribute for the
identifying attribute. For example, if users are going to login with their email
address, make sure all accounts have a defined email attribute. Else
authentication will fail.

Step 1 – Resolving the username to a directory

entry attribute
User entries in a directory are identified by a distinguished name (DN) which
resembles a path-like structure starting at the directory root (the rightmost
segment):