LDAP servers

Lightweight Directory Access Protocol (LDAP) is an Internet protocol used to maintain authentication data that may include departments, people, groups of people, passwords, email addresses, and printers. LDAP consists of a data-representation scheme, a set of defined operations, and a request/response network.

The scale of LDAP servers range from big public servers such as BigFoot and Infospace, to large organizational servers at universities and corporations, to small LDAP servers for workgroups that may be using OpenLDAP.

This document focuses on the institutional and workgroup applications of LDAP.

This section includes:

l Components and topology l LDAP directory organization l Configuring the FortiGate unit to use an LDAP server l Example — wildcard admin accounts – CLI l Example of LDAP to allow Dial-in through member-attribute – CLI l Troubleshooting LDAP

Components and topology

LDAP organization starts with directories. A directory is a set of objects with similar attributes organized in a logical and hierarchical way. Generally, an LDAP directory tree reflects geographic and organizational boundaries, with the Domain name system (DNS) names to structure the top level of the hierarchy. The common name identifier for most LDAP servers is cn, however some servers use other common name identifiers such as uid.

When LDAP is configured and a user is required to authenticate the general steps are:

1. The FortiGate unit contacts the LDAP server for authentication.
2. To authenticate with the FortiGate unit, the user enters a username and password.
3. The FortiGate unit sends this username and password to the LDAP server.
4. If the LDAP server can authenticate the user, the user is successfully authenticated with the FortiGate unit.
5. If the LDAP server cannot authenticate the user, the connection is refused by the FortiGate unit.

Binding

Binding is the step where the LDAP server authenticates the user. If the user is successfully authenticated, binding allows the user access to the LDAP server based on that user’s permissions.

The FortiGate unit can be configured to use one of three types of binding:

l anonymous – bind using anonymous user search l regular – bind using username/password and then search l simple – bind using a simple password authentication without a search

You can use simple authentication if the user records all fall under one domain name (dn). If the users are under more than one dn, use the anonymous or regular type, which can search the entire LDAP database for the required username.

If your LDAP server requires authentication to perform searches, use the regular type and provide values for username and password.

Supported versions

The FortiGate unit supports LDAP protocol functionality defined in RFC 2251: Lightweight Directory Access Protocol v3, for looking up and validating user names and passwords. FortiGate LDAP supports all LDAP servers compliant with LDAP v3, including FortiAuthenticator. In addition, FortiGate LDAP supports LDAP over SSL/TLS, which can be configured only in the CLI.

FortiGate LDAP does not support proprietary functionality, such as notification of password expiration, which is available from some LDAP servers. FortiGate LDAP does not supply information to the user about why authentication failed.

LDAP user authentication is supported for PPTP, L2TP, IPsec VPN, and firewall authentication.

However, with PPTP, L2TP, and IPsec VPN, PAP (Packet Authentication Protocol) is supported, while CHAP (Challenge Handshake Authentication Protocol) is not.

LDAP directory organization

To configure your FortiGate unit to work with an LDAP server, you need to understand the organization of the information on the server.

The top of the hierarchy is the organization itself. Usually this is defined as Domain Component (DC), a DNS domain. If the name contains a dot, such as example.com, it is written as two parts separated by a comma: dc=example,dc=com.

In this example, Common Name (CN) identifiers reside at the Organization Unit (OU) level, just below DC. The Distinguished Name (DN) is ou=People,dc=example,dc=com.

LDAP object hierarchy

In addition to the DN, the FortiGate unit needs an identifier for the individual person. Although the FortiGate unit GUI calls this the Common Name (CN), the identifier you use is not necessarily CN. On some servers, CN is the full name of a person. It might be more convenient to use the same identifier used on the local computer network. In this example, User ID (UID) is used.

Locating your identifier in the hierarchy

You need to determine the levels of the hierarchy from the top to the level that contain the identifier you want to use. This defines the DN that the FortiGate unit uses to search the LDAP database. Frequently used distinguished name elements include:

• uid (user identification) l pw (password) l cn (common name)
• ou (organizational unit) l o (organization) l c (country)

One way to test this is with a text-based LDAP client program. For example, OpenLDAP includes a client, ldapsearch, that you can use for this purpose.

Enter the following at the command line: ldapsearch -x ‘(objectclass=*)’

The output is lengthy, but the information you need is in the first few lines:

version: 2

#

# filter: (objectclass=*) # requesting: ALL

dn: dc=example,dc=com dc: example objectClass: top objectClass: domain

dn: ou=People,dc=example,dc=com ou: People

objectClass: top objectClass: organizationalUnit … dn: uid=tbrown,ou=People,dc=example,dc=com

uid: tbrown cn: Tom Brown

In the output above, you can see tbrown (uid) and Tom Brown(cn). Also note the dn is ou=People, dc=example, dc=com.