Best Practice LDAP
Copyright © 2016 Lexmark. All rights reserved.
Lexmark is a trademark of Lexmark International, Inc., registered in the U.S. and/or other countries. All other trademarksare the property of their respective owners. No part of this publication may be reproduced, stored, or transmitted in anyform without the prior written permission of Lexmark.
Table of Contents
1 What is LDAP? .................................................................................................... 2
2 LDAP and SAPERION ......................................................................................... 2
2.1 Preliminary Notes ............................................................................................ 2
2.2 Procedure for LDAP Synchronization ............................................................ 3
2.2.1 Establishing a Connection to the LDAP Server ............................................. 3
2.2.2 Logging in to the LDAP Server ....................................................................... 3
2.2.3 SSL Authentication .......................................................................................... 5
2.2.4 Recursive Run-Through from BaseDN ........................................................... 5
2.2.5 Generating Groups and Organizational Units ............................................... 6
2.2.6 Updating User Administration ....................................................................... 6
2.3 Single Sign-On ................................................................................................. 7
2.3.1 Procedure for Single Sign-on to Active Directory .......................................... 7
2.3.2 Setting Up Single Sign-on for ADS ................................................................ 7
2.4 INI Entries ....................................................................................................... 8
2.4.1 [LDAP Sync] Section ...................................................................................... 8
2.4.2 [LDAPMapping.User] Section ......................................................................... 8
2.5 Important Information .................................................................................... 9
2.5.1 Changing the Password of a Synchronized User ........................................... 9
2.5.2 Synchronizing with ADS ................................................................................. 9
2.5.3 Multi-client-capable Systems .......................................................................... 9
2.5.4 Global Search .................................................................................................. 9
2.5.5 Using Filters .................................................................................................... 9
3 Glossary ............................................................................................................... 10
3.1 DIT (Directory Information Tree) ................................................................... 10
3.2 DN (Distinguished Name) ............................................................................. 10
3.3 LDIF (LDAP Data Interchange Format) ......................................................... 10
3.4 RDN (Relative Distinguished Name) ............................................................. 11
3.5 SASL (Simple Authentication and Security Layer) ......................................... 11
3.6 X.500 ................................................................................................................ 12
2
Best Practice LDAP
1 What is LDAP?
LDAP (Lightweight Directory Access Protocol) is an application protocol based on the client/server
model that allows the requesting and modification of information of a directory service via the TCP/IP
network. A directory or directory service is a distributed hierarchical database in the network.
LDAP describes the communication between the so-called LDAP client and the directory server from
which object-related data, such as personal data or computer configurations, is retrieved.
This means that the directory can include an address book, for example. If a user then searches for a
particular mailing address, they trigger the action "searching for the mailing address xyz." The e-mail
client formulates a corresponding LDAP request to the directory that provides the address information.
The directory formulates the reply and transmits this to the client.
In administrative language, the term LDAP server has come to be used for a directory server that
exchanges data via the LDAPv3 protocol and whose data structure complies with LDAP specifications.
The protocol provides all functions that are required for such communication:
+ Login to the server
+ Formulation of the search query
+ Modification of the data
The current LDAP specification is RFC 4511. Implementations that are newer than RFC 2251 take into
account the replication of data between different directories.
2 LDAP and SAPERION
2.1 Preliminary Notes
LDAP is a method of accessing a directory service.There are several LDAPs, such as Active Directory,
SUNOne etc. SAPERION sees exactly what an LDAP browser (e.g., jxplorer) sees.
Please consider the following characteristics:
Standard ports
+ The standard port for LDAP is 389. If another port is used, this must be specified explicitly. If, e.g.,
you search beyond domain limits in an active directory ("Global catalog"), "3268" must be entered
after the server address for the appropriate port.
+ The standard port for LDAPS is 636. If another port is used, this must be specified explicitly.
Certificate
Following certificate formats are supported:
2 LDAP and SAPERION 3
+ PEM
+ DER
LDAP systems
Following LDAP systems are supported:
+ OpenLDAP
+ Windows Domain
2.2 Procedure for LDAP Synchronization
i The following requirements apply to all LDAP systems. If all of them are met, synchronization is
possible (without single sign-on).
The SAPERION user administration is synchronized according to the following procedure:
1. Establish connection to the LDAP server
2. Log in to the LDAP server
3. Recursive run-through from BaseDN
4. Generate groups and organizational units
5. Update user administration
i The following example illustrates a synchronization with OpenLDAP. The registration data to be
used depends on the LDAP system used (e.g., eDirectory, Active Directory).
Establishing a Connection to the LDAP Server
In order to establish a connection to the LDAP server, the IP address that has to be used for the
registration data must be known. The standard port is Port 389. The port only has to be specified if it
deviates from the standard port.
i When using certificates, the name of the certificate file can be specified here.
Logging in to the LDAP Server
In order to log in to the LDAP server, the following data must be specified alongside the IP address of
the LDAP server:
+ User (DN)
+ Password
+ BaseDN
The user must exist in the LDAP directory and have the right to search the directory. The user is specified
as DN or distinguished name (e.g., "cn=admin,dc=nodomain"). An object in the LDAP directory is
uniquely identified using the DN.
4
Fig. 2–1: LDAP Directory
The unique field "UID" which is mapped to a unique field in the LDAP schema, must exist in the schema
extension of the SAPERION user administration. The "UID" parameter ensures that, after a change was
made to the DN of an AD user (e.g., moved into another OU), the SAPERION user's ID does not change
during a user synchronization. This is important for ACLs.
There is another attribute, "GUID," for use with single sign-on under Active Directory, which acts
independently of "UID."
Fig. 2–2: LDAP Assignment
In Active Directory, a unique field, e.g., "ObjectGUID", can be used.
2 LDAP and SAPERION 5
Fig. 2–3: LDAP Login
The BaseDN (=Context) is the start container in the LDAP from which users should be looked up. In
the above screenshot, this could be the "development" organizational unit, for example. In this case,
"ou=development,o=saperion" must be given as the BaseDN.
SSL Authentication
The following requirements have to be met for using SSL authentication:
+ SSL certificate must exist
+ the publisher of the certificate must also exist as certificate.
When you have selected the authentication "SSL" in the LDAP login dialog you have to enter the path to
the appropriate publisher certificate in the field "Certificate".
Fig. 2–4: Enter SSL certificate
! The certificates have to be reachable for all installations that are using the certificates, e.g.,
Adminclient, Java Core Server. The path to the certificates are saved in the central PROGRAM.INI
at the Core Server. In a multi-server system the PROGRAM.INI on the servers have to be adapted
possibly.
Recursive Run-Through from BaseDN
Based on BaseDN (Context), all users that correspond to the filter condition are recursively gathered.
Particularly in the case of large LDAP directories, it is recommended to use filters, as otherwise the
synchronization process can take a considerable amount of time.
6
Fig. 2–5: LDAP Synchronization
In the example, only users that have the value "Berlin" in the attribute "I" (location) are transferred, in
other words all users from Berlin.
Generating Groups and Organizational Units
During the synchronization, the individual groups are evaluated. As part of this process, specific fields
are used to check which users are members of these groups. The relevant field that is evaluated depends
on the LDAP server used. The following fields are possible:
+ member (e.g., Domino, OpenLDAP)
+ uniqueMember (e.g., SunOne)
+ memberUID (e.g., OpenLDAP)
If a user that is a member of a group meets the filter criteria, the corresponding group is generated in
the user administration of SAPERION.
i In Active Directory, users are evaluated immediately. This means that the system checks users
to see which groups they are members of. These groups are then generated in the user
administration of SAPERION (if the user meets the filter criteria).
Must-Do's
In order to ensure that groups from the LDAP are synchronized, the switch
IncludeGroupMembers=TRUE must be set ([LDAP Sync] section).
When setting the filter condition, keep in mind that a user may only be a member of a maximum of 50
groups. If a user is a member of more than 50 groups, the synchronization fails.
When synchronizing groups, keep in mind that the user's primary groups are not always synchronized.
This usually refers to the "Domain Users" group. No permissions should be assigned on the basis of
these groups.
Updating User Administration
Using the unique field, the SAPERION user administration is checked to determine whether the user
already exists. If not, the user is created.
2 LDAP and SAPERION 7
i If the "Only synchronize existing users" checkbox is enabled for the synchronization, a unique
"UID" field is also required by LDAP.
Deleting Users
During synchronization, users are only deleted from the SAPERION user administration if the "Only
synchronize existing users" method is selected and the "Allow deletions" box is ticked.
Users disabled in the ADS are also provided with the note "Account disabled" in SAPERION. If the user
is reactivated in the ADS, the ID is also removed from SAPERION.
2.3 Single Sign-On
Currently only available for Active Directory. During registration, the core server receives domain +
username as a login parameter. The core server sends a request to the domain controller (DC) to
determine whether this user exists in the domain. If this is the case, the DC returns the DN of the user.
Now the core server searches its user database to determine whether this user exists. If so, the single
sign-on protocol is executed.
In order to execute a single sign-on, a schema mapping must first be performed. The LDAP property
"ObjectGUID" must be mapped to the "GUID" field that is to be inserted.
i The "GUID" attribute is not linked with the "UID" attribute and is only effective for Single sign-on.
The matching ID of the user is now mapped to the field by means of user synchronization. This ID is
globally unique and fully secures an allocation of the user.
For single sign-on registration, the user must be integrated into the domain in such a way that they can
receive all account information from the domain controller. The tool "GetUserName.exe" provided by
SAPERION can be used for the test. After startup, the GUID of the registered user must be displayed
here. If the user then attempts a single sign-on, the user's DN and "ObjectGUID" are determined on
the client and are transmitted to the core server. The core server then checks whether the information
corresponds with the information known to it and only then permits login. Due to the uniqueness of the
"GUID", it is not possible to attempt to manipulate it using an account of the same name.
Procedure for Single Sign-on to Active Directory
1. On the client computer, the distinguished name of the registered user and the Windows "GUID"
("ObjectGUID") allocated to the user are identified via WIN-API.
2. In order to identify the "GUID", the client computer must be able to communicate with the domain
controller. Name and GUID are sent to the Core Server.
3. The Core Server searches for the user in its user administration. In cases there is a schema extension
with the "GUID" field the content of "GUID" and "ObjectGUID" are compared. If the comparison
is positive, registration is successful.
Setting Up Single Sign-on for ADS
In order to be able to synchronize with ADS via LDAP, the unique field "UID" must be mapped onto the
"ObjectGUID" field in the LDAP in the schema extension of SAPERION.
8
The following steps are required for this:
1. Create the "XSUSR_Schema" system table by double-clicking the field beside "User" in the "Table"
column of the schema extension.
2. Add the "GUID" field which must be unique.
3. Map the field in the schema extension with "ObjectGUID". This ID is globally unique and fully
secures an allocation of the user. The "ObjectGUID" remains constant throughout the existence
of the user.
2.4 INI Entries
[LDAP Sync] Section
In the section [LDAP Sync] are the following entries:
[LDAP Sync]
SynchedWithOS=
IncludeGroupMembers=TRUE
Count=1 Number of LDAP server
Server1=
Parameters of the [LDAP Sync] section
Parameter Description
SynchedWithOS Means that the "Synchronized with operating system" checkbox is disabled when creating
new users via LDAP synchronization.
FALSE is set by default.
IncludeGroupMembers Means that the users' groups are also transferred during synchronization with LDAP (ex-
cept Active Directory). This option is turned off by default.
Count Contains the list of LDAP servers.
[LDAPMapping.User] Section
LDAP assignment for users (schema extension).
EMail=mail
Language=preferredLanguage
Passwd=userPassword
Description=description
uid=ObjectGUID
guid=ObjectGUID
DisplayName=(EXIST uid)?uid:(givenName + " " + sn)
2 LDAP and SAPERION 9
2.5 Important Information
Changing the Password of a Synchronized User
The administrator of a SAPERION system can change the password of a synchronized user. To do so,
the user must simply disable the "Synchronize with operating system" and "Synchronize with LDAP"
checkboxes. This behavior is therefore deliberate. If the option to change the passwords of synchronized
users is to be eliminated, the following procedure is recommended:
+ Set an ACL for the users in question.
+ Specify a technical SAPERION user to receive permissions for this ACL.
+ Two independent administrators have partial knowledge of the password of this technical
SAPERION user.
+ The technical SAPERION user is protected by the same ACL.
i The technical user and their ACL must also be protected by the created ACL.
Synchronizing with ADS
For synchronization with ADS, a field should be mapped that is also completed by default.
Multi-client-capable Systems
In the case of multi-client-capable systems, synchronization must always take place in the context of a
client.
Global Search
If "Global Search" is ticked, no container objects are transferred from the BaseDN (Context) as groups.
Otherwise, the containers encountered in the tree will be transferred as groups.
If no BaseDN is specified, the search begins with the context of the login parameter.
During the global search, only users that already exist in the LDAP are searched and synchronized. New
users are not transferred, neither are groups. During this process, all objects below the BaseDN are
synchronized in one go.
Using Filters
+ The filters must be constructed in such a way that the attribute is always compared with the value.
Example
"l=Berlin"
+ "MemberOf" requires particular attention as "MemberOf" is of type distinguished name (DN). No
wildcard searches, only direct string comparisons, are possible in Active Directory (AD) by default.
A database index can always be constructed in the Active Directory to implement the wildcard
search.
10
Disadvantage: In the case of large Active Directories, the performance of the Active Directory itself
may be impaired.
3 Glossary
3.1 DIT (Directory Information Tree)
The hierarchical tree structure is known as a Directory Information Tree (DIT), which maps the entire
name space hosted by a server.
3.2 DN (Distinguished Name)
The distinguished name is a globally unique name for an entry in the OSI directory based on X.500. The
distinguished name is a unique identifier in the scanned database.
Example
UID=admin, dc=structure-net, dc=de
3.3 LDIF (LDAP Data Interchange Format)
Is a file format based on ASCII that is used to exchange data and supports the synchronization of data
with the help of an LDAP server.
Example
dn: dc=saperion, dc=de
objectclass: organization
objectclass: top
o: Structure Net
l: Berlin
postalcode: 10623
streetadress: Steinplatz 2
dn: ou=Sales, dc=saperion, dc=de
objectclass: organizationalunit
ou: Sales
description: Verkauf
telephonenumber: +49 30 600610
facsimiletelephonenumber: +49 30 600610
dn: ou=Development, dc=saperion, dc=de
objectclass: organizationalunit
ou: Development
description: Entwicklung
telephonenumber: +49 30 600610
facsimiletelephonenumber: +49 30 600610
dn: ou=Support, dc=saperion, dc=de
objectclass: organizationalunit
3 Glossary 11
ou: Support
description: Support
telephonenumber: +49 30 600610
facsimiletelephonenumber: +49 30 600610
dn: UID=admin, dc=structure-net, dc=de
objectclass: person
objectclass: organizationalperson
objectclass: inetorgperson
cn: admin
cn: Systemverwalter
cn: SAPERION
sn: SAPERION
UID: admin
mail: [email protected]
l: Berlin
postalcode: 10623
streetadress: Steinplatz 2
telephonenumber: +49 30 600610
facsimiletelephonenumber: +49 30 600610
3.4 RDN (Relative Distinguished Name)
Relative name of an object in a (LDAP) directory service. The RDN is comprised of one or more
name-value pairs. The so-called distinguished name is formed by stringing together the individual RDNs
in the various hierarchy levels of a root node right through to the entry's RDN. This distinguished name
is a unique identifier in the entire database.
The distinction between the RDN and DN is important. If the DN appears like an absolute path between
the root of a file system and the corresponding file, then the RDN is like the file name itself.
Example
UID=admin
3.5 SASL (Simple Authentication and Security Layer)
SASL is a framework for authentication used in various Internet protocols. In October 1997, it was defined
as RFC 2222. It was replaced by RFC 4422 in July 2006.
SASL provides the application protocol with a standardized method of negotiating communication
parameters. Usually, only one authentication method is negotiated; however, it can also be stipulated
that this occurs after switching to an encrypted transport protocol first, such as TLS. The SASL
implementations on the client and server agree on one process and this can then be used transparently by
the application. This standard considerably simplifies the development of secure application protocols.
The developer must simply use an existing SASL implementation instead of carrying out an entire
process for authentication and data encryption themselves.
SASL is used with SMTP, IMAP, POP3, LDAP and XMPP among others.
12
3.6 X.500
X.500 is a recommendation for a directory service from the International Telecommunication Union
(ITU) as part of the X series (Data Networks and Open System Communications). The recommendation
first appeared in 1988. This does not involve a technical implementation, but rather refers to the
framework for designing a directory service. X.500 was made public and has been implemented in
different ways; many manufacturers offer their own implementation for the administration of their
infrastructure.
In keeping with the open approach, there are no fixed requirements as regards the information to be
stored. Instead, the framework is generally based on objects and connections between them.