Best Practice LDAP - Kofax · PDF file2 Best Practice LDAP 1 What is LDAP? LDAP (Lightweight...

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.


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.


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.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


ou: Development

description: Entwicklung



dn: ou=Support, dc=saperion, dc=de


3 Glossary 11

ou: Support

description: Support



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



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.

Best Practice LDAP - Kofax · PDF file2 Best Practice LDAP 1 What is LDAP? LDAP (Lightweight...

Documents

Transcript of Best Practice LDAP - Kofax · PDF file2 Best Practice LDAP 1 What is LDAP? LDAP (Lightweight...