个人工具

Quick HOWTO : Ch31 : Centralized Logins Using LDAP and RADIUS/zh

来自Ubuntu中文

跳转至: 导航, 搜索


目录

引言

许多认证数据库程序都被设计成允许用户在不同的计算机上使用同一组密码登陆。第一个这样的程序是 NIS 。但是它在传输中没有对密码进行加密处理,同时它还采用了端口映射守护进程,而端口映射使用的不可预知的TCP端口使得NIS难以通过防火墙。针对这些问题,LDAP(轻型目录访问协议)提供了一个基于X.500协议的替代品。

The X.500 standard defines how globally referenced directories of people should be structured. X.500 directories are organized under a common root directory in a tree hierarchy with different levels for each category of information, such as country, state, city, organization, organizational unit, and person. Designed to provide a simpler yet robust implementation of X.500, LDAP was originally used as the backbone of Microsoft's Active Directory Service and Novell's Novell Directory Services (NDS) products. LDAP can also interact with other login programs, such as Remote Authentication Dial-in User Service (RADIUS), which the network equipment of many ISPs uses to manage dialup Internet access.


It was later recognized that LDAP had features that could make it a desirable replacement for NIS in some scenarios. For example, it uses a single TCP port (389) for regular communication and another port (636) for encrypted transactions. LDAP also can interact with many login authentication, authorization, and accounting programs external to Linux and UNIX.

本章将首先介绍如何在Fedora Linux系统上安装和使用 LDAP。然后将解释如何使LDAP与RADIUS相互协作。

LDAP 的目录结构

就像X.500一样,LDAP的目录项目被安排成树形的结构。在根节点下,有代表国家、组织、单位和人员的分支。

在复杂的LDAP部署中,当你必须和其他公司的LDAP数据库交换信息时,你可能需要向互联网编号分配机构(IANA负责)申请一个正式的组织数量,以减少数据冲突。

情景

举例来帮助理解这些概念。比如说在一个小的机构里有一个IT部门,域名是exampe.com。它有许多Linux系统的服务器需要管理。

  • 公司希望对于所有的服务器都能有一种简单、安全的认证登陆方案。
  • 公司决定使用 example.com 作为它的LDAP数据库域名,这个域名由 example 和 com 两部分组成。
  • 这个数据库里只有一种成为 People 的组织单位,这也是 LDAP的默认情况。
  • 每一个人都有一些属性,比如用户名(User ID 或者 UID)、密码、Linux的主目录以及登陆接口。
  • 作为LDAP服务器并存放数据库的Fedora Linux 服务器的名字为 bigboy ,它的 IP 地址是 192.168.1.100。
  • 作为测试系统的LDAP 用户 Fedora Linux 服务器名字是 smallfry ,IP地址是 192.168.1.102。
  • 服务器 bigboy 用来测试的账户用户名是ldapuser。

下面是如何完成我们的工作的。

下载并安装 LDAP 软件包

大多数的RedHat 和 Fedora Linux 软件都能找到 RPM 格式的发行包。在寻找这些软件包时,请注意 FreeRADIUS 的 RPM 软件包通常以 openldap 开头,并且文件名的后部有该软件包的版本号,例如 openldap-servers-2.1.22-8.i386.rpm。(更多的关于下载和安装方面的细节,请参见第6章"Installing Linux Software")

请将下面这些LDAP 服务 RPM 包安装到您的 LDAP服务器上。

必须的LDAP服务器端软件包

下面的软件必须安装到您的 LDAP 服务器上。

openldap
openldap-clients
openldap-devel
nss_ldap
openldap-servers

必须的LDAP客户端软件包

下面的软件必须安装到您的 LDAP 客户端计算机上。

openldap
openldap-clients
openldap-devel
nss_ldap

配置LDAP服务器

工作的第一步是正确的配置LDAP服务器。你必须创建一个LDAP数据库,并向其中导入 /etc/passwd 文件。请仔细阅读下面的步骤。

创建数据库目录

Fedora LDAP 默认将所有的数据库放置在 /var/lib/ldap 目录下。例如,它将创建一个所有者是 ldap 的,名为 example.com 的文件夹。(用户 ldap 是在 RPM软件安装时自动添加到系统中的)

[root@bigboy tmp]# mkdir /var/lib/ldap/example.com
[root@bigboy tmp]# chown ldap:ldap /var/lib/ldap/example.com

创建 LDAP "root" 密码

只有 LDAP root 用户能够在数据库中新建、导入数据以及导出数据。这个用户需要加密过的密码。你可以通过 slappasswd 命令创建该密码,并将其使用到 LDAP 配置文件中。

[root@bigboy tmp]# slappasswd
New password:
Re-enter new password:
{SSHA}v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ
[root@bigboy tmp]#

编辑 slapd.conf 文件

现在 LDAP 服务的守护进程名字是 slapd ,它的配置文件为 /etc/openldap/slapd.conf。将这两个修改如下:

  • 默认的 bdb 格式数据库使用 example.com 的域名后缀,该域名后缀由 example 和 com 两部分组成。
  • root 用户的通用名称(CN),或昵称是 Manager, 域名元素(DC)是 example 和 com。
  • 加密 LDAP root 密码,并修改 LDAP数据库的位置。

在配置文件中修改如下:

database        bdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,dc=com"
rootpw          {SSHA}v4qLq/qy01w9my60LLX9BvfNUrRhOjQZ
directory       /var/lib/ldap/example.com

开启 LDAP 守护进程

服务命令使用选项 start 、stop 以及 restart 来控制 LDAP 服务 slapd 守护进程的运行。使用 start 选项以加载 slapd.conf 配置文件中的内容。


有些 LDAP 版本要求一个安装在 LDAP 数据库目录下的 DB_CONFIG 文件。在启动 LDAP 前,您可能需要从 /etc/openldap 复制一些模板文件的样本到 /var/lib/ldap/example.com 下。

[root@bigboy tmp]# cp /etc/openldap/DB_CONFIG.example /var/lib/ldap/example.com/DB_CONFIG
[root@bigboy tmp]# service ldap start
   Starting slapd: [  OK  ]
[root@bigboy tmp]#

将 /etc/passwd 文件转化成 LDIF 格式

服务器上 /etc/passwd 文件中的数据在导入到 LDAP 数据库中之前需要将它们转换成 LDAP Data Interchange Files (LDIF) 格式。您不需要把所有的用户导入到 LDAP 数据库中,您可以只导入您所需要的。

建立 ldapuser 测试账号

键入以下命令以建立测试账号 ldapuser。

[root@bigboy tmp]# useradd -g users ldapuser
[root@bigboy tmp]# passwd ldapuser
Changing password for user ldapuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@bigboy tmp]#

在 /etc/passwd 中提取有关记录

你需要使用 grep 命令从 /etc/passwd 文件中提取用户 ldapuser 的信息,并使用 > 字符将其保存到/etc/openldap/passwd.ldapusers 文件中。

[root@bigboy tmp]# grep ldapuser /etc/passwd > \
    /etc/openldap/passwd.ldapusers
[root@bigboy tmp]#

如果是第一次建立 LDAP 数据库,你还需要从 /etc/passwd 文件中提取系统 root 账号的信息,将其保存到 /etc/openldap/passwd.root 文件中。

[root@bigboy tmp]# grep root /etc/passwd > \
    /etc/openldap/passwd.root
[root@bigboy tmp]#

找到转换脚本文件

/etc/passed 文件的转换程序名为 migrate_passw.pl;你可以通过定位命令找到它。定位实用程序每晚更新它的数据库,所以可能找不到最新安装的文件。你可以使用 locate 命令来在计划任务前更新定位程序的数据库。

[root@bigboy tmp]# locate -u
[root@bigboy tmp]# locate migrate
...
/usr/share/openldap/migration/migrate_passwd.pl
...
[root@bigboy tmp]#

转换 ".ldapuser" 文件

你可以现在转换那些从 /etc/passwd 文件中提取出来的数据到可以导入到数据库中的 LDIF 格式。在本例中,将生成一个供一般用户使用的 /etc/openldap/ldapuser.ldif 文件,以及一个 root 用户使用的 /etc/openldap/root.ldif 文件。

[root@bigboy tmp]# /usr/share/openldap/migration/migrate_passwd.pl \
  /etc/openldap/passwd.ldapusers /etc/openldap/ldapusers.ldif
[root@bigboy tmp]#
[root@bigboy tmp]# /usr/share/openldap/migration/migrate_passwd.pl \
  /etc/openldap/passwd.root /etc/openldap/root.ldif
[root@bigboy tmp]#

修改 LDIF 文件

现在我们已经有了两个新的 LDIF 文件,下一步就是将这些数据导入到 LDAP 数据库中。作为这一步的预先准备,你必须做一些编辑来创建一个定义了组织单位的新的 LDIF 文件。

编辑用户 LDIF 文件

Fedora 的 migrate_passwd.pl 脚本创建名为 People 的组织单位的所有部分,但是所有人都是从属于 padl.com 域的。你现在必须把这两个 LDIF 文件中的每一个 "padl" 字符串更改为 "example"。一个文本编辑器就能很好的适应这件工作,例如,使用 vi 编辑器,在 : 提示符后,使用命令:

%s/padl/example/g

来执行全局的从字符串 padl 到 example 的替换。

在 slapd.conf 文件中,我们已经赋予了 root 用户一个通用名称(CN):Manager。我们现在需要把这个信息添加到 root 的 LDIF 文件中。在 UID 一行的下面插入一行:

cn: Manager

为 "example.com" 域建立 LDIF 文件

现在您从 /etc/passwd 创建的 LDIF 文件仅仅涉及到了用户部分,还没有定义 example.com 域的属性,同时也没有定义名为 People 的组织单位。我们将在第三个 LDIF 文件 /etc/openldap/example.com.ldif 中完成这些工作,这个文件的内容应该像下面列出的一样:

dn: dc=example,dc=com
dc: example
description: Root LDAP entry for example.com
objectClass: dcObject
objectClass: organizationalUnit
ou: rootobject
 
dn: ou=People, dc=example,dc=com
ou: People
description: All people in organisation
objectClass: organizationalUnit

向数据库中导入 LDIF 文件

使用 LDAP add 命令来把这三个 LDIF 文件导入到数据库中,其顺序首先是 example.com.ldif file,然后是 root.ldif,最后是 ldapusers.ldif

当提示输入密码时,输入您所创建的 LDAP root 密码。

[root@bigboy tmp]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
     -W -f /etc/openldap/example.com.ldif
[root@bigboy tmp]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
      -W -f /etc/openldap/root.ldif
[root@bigboy tmp]# ldapadd -x -D "cn=Manager,dc=example,dc=com" \
      -W -f /etc/openldap/ldapusers.ldif
[root@bigboy tmp]#

测试 LDAP 数据库

通过 ldapsearch 命令你可以查看 LDAP 数据库中的所有条目。这是一个测试刚才的操作是否都正确的好方法。

[root@bigboy tmp]# ldapsearch -x -b 'dc=example,dc=com' \
    '(objectclass=*)'
[root@bigboy tmp]#

配置 LDAP 客户端

Now that the LDAP server is configured properly, you can turn your attention to configuring and testing the clients. 现在,我们已经将 LDAP 服务器配置完毕,可以将注意力转到配置和测试客户端上来了。

Edit the ldap.conf configuration file 编辑 ldap.conf 配置文件

LDAP clients are configured using the /etc/openldap/ldap.conf file. You need to make sure that the file refers to the LDAP server's IP address for the domain example.com. The file should look like this:

LDAP 客户端的配置文件是 /etc/openldap/ldap.conf file。你需要确保该文件中指明的 LDAP 服务器的 IP 地址是 example.com 域中的LDAP 服务器地址。这个文件应该像这样:

HOST 192.168.1.100
BASE dc=example,dc=com

Edit the /etc/nsswitch file 编辑 /etc/nsswitch 文件

The /etc/nsswitch.conf file defines the order in which the Linux operating system searches login databases for login information.

/etc/nsswitch.conf 文件定义了 Linux 操作系统搜索登陆信息的数据库的顺序。

You want to configure it to first search its /etc/passwd file. If it doesn't find the user password information there, it goes to the LDAP server. The easiest way set this up is to use the /usr/bin/authconfig-tui command: 我们配置它先搜索 /etc/passwd 文件,如果操作系统在这里没有找到相应的用户密码信息,它将到 LDAP 服务器上继续查找。最简单的设置方法是使用 /usr/bin/authconfig-tui 命令。

  1. 执行 /usr/bin/authconfig-tui。如果命令行的语言设置不兼容的话,这个命令的输出可能是乱码。为了避免这样的问题出现,你可以在命令之前加上一段字符串 LANG=C,如下所示:
[root@smallfry tmp]# LANG=C authconfig-tui
  1. 选择LDAP。
  2. 填入 LDAP 服务器的 IP 地址,在我们这个例子中是 192.168.1.100。
  3. Give the base DN as dc=example,dc=com

填入基础 DN,这个例子里是 dc=example,dc=com

  1. 不要选择 TLS。
  2. 使用 MD5 以及 shadow passwords。

这时屏幕应该看起来是这个样子:

[*] Use Shadow Passwords
[*] Use MD5 Passwords
[*] Use LDAP                   [ ] Use TLS                 
                       Server: 192.168.1.100
                      Base DN: dc=example,dc=com

完成后,查看 /etc/nsswitch.conf 文件,确保它已经涉及了 LDAP。

Note: 在一些 Linux 发行版中,authconfig 命令取代了 authconfig-tui 命令。

在 LDAP 客户端上建立主目录

先前我们已经在服务器 bigboy 的 users 用户组中建立了一个名为 ldapuser 的用户。我们需要确保该用户在 LDAP 客户端 smallfry 上有一个主目录。在这一小节的例子中,我们将建立一个 ldapuser 为所有者的目录。正如你所看到的,服务器 smallfry 正确的从服务器 bigboy 上获得了用户 ldapuser 的信息,chown 命令没有提示 ldapuser 在服务器 smallfry上的 /etc/passwd 中不存在的的错误。

检查 /etc/passwd 文件中是否存在 ldapuser 账号

你可以通过 grep 命令查找 /etc/passwd 中是否存在 ldapuser。在这里,这个命令应该没有信息反馈(也就是没有查找到有关 ldapuser 的信息)。

[root@smallfry tmp]# grep ldapuser /etc/passwd
[root@smallfry tmp]#

在 LDAP 客户端上建立账号 ldapuser 的主目录

在这一阶段,你建立一个主目录,向里面复制一个 BASH 登陆配置文件,并将这个目录和其中所有的文件的所有者改为用户 ldapuser。

注意: 如果 chown 命令失败,则很有可能是因为错误的 LDAP 配置导致 LDAP 客户端不能从 LDAP 服务器上读取用户信息。

在某些情况下,你可能希望使用 NFS 挂载来为用户提供主目录,这将大大的减少这一步的工作量。使用 NFS 的益处及缺点在第29章涉及,"Remote Disk Access with NFS", and Chapter 30, "Configuring NIS",其中涉及了使用NFS 作为用户主目录的内容。

[root@smallfry tmp]# mkdir /home/ldapuser
[root@smallfry tmp]# chmod 700 /home/ldapuser/
[root@smallfry tmp]# ll /home
total 2
drwx------    2 ldapuser users        1024 Aug  4 08:05 ldapuser
[root@smallfry tmp]# cp /etc/skel/.* /home/ldapuser/
cp: omitting directory `/etc/skel/.'
cp: omitting directory `/etc/skel/..'
cp: omitting directory `/etc/skel/.kde'
[root@smallfry tmp]# chown -R ldapuser:users /home/ldapuser
[root@smallfry tmp]#

测试

You next need to do basic testing. For details, see which is covered in the "Troubleshooting LDAP Logins" section. 接下来就可以做基本的测试了。详细内容请参见 "LDAP登录的故障排除" 部分。

配置加密的LDAP通信

There are two commonly mentioned methods of encrypting Linux LDAP communications between clients and servers. One method is through the use of the external stunnel utility that protects the data using SSL. The other method also uses SSL, but it is natively supported in LDAP by using its Transport Layer Security (TLS) option and is therefore easier to implement. This section describes both methods.

有两种常用的方法加密Linux LDAP服务器和客户端之间的通讯。一种是利用外部的使用SSL的安全通道以保护数据。另外一种方法也是使用SSL,但是利用LDAP原生支持的TLS选项,所以更加容易实现。本节会介绍这两种方法。

使用 Transport Layer Security (TLS) 加密

TLS is an updated version of the Secure Socket Layer (SSL) protocol used by many web browsers to do shopping cart checkouts. Like most certificate based encryption schemes it allows a client and server to talk in a trusted manner without the use of a password.

TLS是SSL协议的升级版,众多浏览器用之保护网上购物。跟大多数基于证书加密的方案类似,它能做到让客户端和服务器无需密码就可以安全地交流。

TLS will require you to create a certificate authority (CA) for your organization. A CA is a server that will manage the issuance and authentication of new server certificates used by the LDAP server for TLS. In the example that follows, the CA and LDAP servers are the same device, but guidelines are also provided on how the functions can be assigned to separate servers.

TLS要求你为你的组织创建一个CA, CA是一台服务器,它能颁发和认证新的服务器证书给LDAP服务器用于TLS用途。在下面的例子中,CA和LDAP服务器都放在同一台设备上,然而我们也会给出一些指导,告诉你如何把两者放在不同的设备上。

Note: Unlike the stunnel encryption method described later, TLS runs encrypted on LDAP's TCP port 389.

Before we begin configuration it is important to understand how TLS works. This will be discussed next.

“注意”: 跟后面将要描述的用安全通道加密的方式不一样,LDAP TLS 方式跑在389端口。 在我们开始做配置之前,有必要了解一下TLS工作原理。下面对此进行讨论。

TLS 是如何通信工作的

There is a sequence of events that occur prior to the creation of an LDAP communication session using TLS. These include the following steps:

  1. Both the LDAP server and client need to be configured with a shared copy of a CA certificate beforehand.
  2. When the TLS LDAP connection is made, the client and server negotiate their SSL encryption scheme.
  3. The LDAP server then sends its public encryption key and its server certificate.
  4. The LDAP client inspects the server certificate to make sure that it hasn't expired and takes note of the name and key ID of the CA server that issued it. It then checks this CA information with all the CA certificates in its database to determine whether the server certificate should be trusted.
  5. If everything is valid, the LDAP client then creates a random "premaster" secret encryption key that it encrypts with the LDAP server's public key. It then sends the encrypted encryption key to the LDAP server.
  6. When public keys are created, a special "private" key is also simultaneously created. Anything encrypted with the public key can only be decrypted with the private key and vice versa. The server then uses its private key to extract the premaster key.
  7. The client and server then use the premaster key to generate a master secret that will be the same for both, but will never be transmitted so that a third-party cannot intercept it.
  8. The master secret key is then used to create session keys that will be used to encrypt all future communication between client and server for the duration of the TLS session.

Now that you understand the TLS process its time to start configuring secure LDAP.

配置 TLS 服务

We are about to create our own CA server to create and sign server certificates. This process is known as creating a self-signed SSL certificate as opposed to having a trusted third party organization, such as Verisign, doing it on your behalf. The latter method is most commonly used by public websites in which the CA certificates of many well known and trusted CA companies already come installed on your PC as part of your Web browser installation.

Configuration of the server isn't hard, but there are many steps. Let's go!

1. Install the openssl-perl package which will provide the CA.pl script that helps to automate a lot of the certificate generation steps.

[root@bigboy tmp]# yum -y install openssl-perl

2. The location of the CA.pl script will vary with each Linux distribution. Use the updatedb command to update your file locations database to reflect the new files installed with the package and then use the locate command to file the script, which in this case is located at /etc/pki/tls/misc/CA.pl.

[root@bigboy tmp]# updatedb
[root@bigboy tmp]# locate CA.pl
/etc/pki/tls/misc/CA.pl
/usr/share/man/man1/CA.pl.1ssl.gz
[root@bigboy tmp]#

3. Take a look at the contents of the CA.pl script. There is a CATOP variable that determines where CA.pl will place some of the certificate files. With Fedora Core 5, this defaulted to the ../../CA directory. You could edit this to be a specific directory, but the script will get overwritten the original values the next time you update the packages on your system. In this example we'll do most of our work in a newly created /etc/openldap/TLS/data/files directory which will place the CA files in the /etc/openldap/TLS/CA directory.

[root@bigboy tmp]# mkdir -p /etc/openldap/TLS/data/files
[root@bigboy tmp]# cd /etc/openldap/TLS/data/files
[root@bigboy files]#

4. This next step is very important. You need to know the hostname of your system, and it should also be reflected in DNS or the host files of all your TLS LDAP clients. Things will not work other wise. Here it is bigboy.my-web-site.org.

[root@bigboy files]# hostname
bigboy.my-web-site.org
[root@bigboy files]#

5. Now you will run CA.pl for the first of many times. Create your CA certificate using CA.pl with the -newca option. You will be prompted for a PEM encryption pass phrase, use the same phrase for all the following TLS steps. The script will also prompt you for company information, if you don't use the defaults, make sure the information matches each time you run the script. Don't provide any of the "extra" attributes.

Note: Make sure you place the correct hostname, not its IP address when you are prompted for it. The LDAP clients will only work if the hostname of the certificate matches the hostname, not IP address, of the server defined in their ldap.conf files.
Note: Take note of your PEM encryption pass phrase. Your server default to a 365 day expiry at which point you will have to regenerate them from the CA certificate. If you don't remember the phrase, you'll have to start all over again.
[root@bigboy files]# /etc/pki/tls/misc/CA.pl -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
........++++++
....................++++++
writing new private key to '../../CA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:
State or Province Name (full name) [Berkshire]:
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:bigboy.my-web-site.org
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for ../../CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            8f:e7:82:39:04:61:79:2b
        Validity
            Not Before: Jul  3 19:02:39 2006 GMT
            Not After : Jul  2 19:02:39 2009 GMT
        Subject:
            countryName               = GB
            stateOrProvinceName       = Berkshire
            organizationName          = My Company Ltd
            commonName                = bigboy.my-web-site.org
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                FA:B4:14:1E:63:37:43:05:96:3E:E1:D7:24:9A:38:84:17:E4:A2:80
            X509v3 Authority Key Identifier: 
                keyid:FA:B4:14:1E:63:37:43:05:96:3E:E1:D7:24:9A:38:84:17:E4:A2:80

Certificate is to be certified until Jul  2 19:02:39 2009 GMT (1095 days)

Write out database with 1 new entries
Data Base Updated
[root@bigboy files]#
Note: Your CA certificate will be named /etc/openldap/TLS/CA/cacert.pem. The private CA key used to generate all future server certificates will be named /etc/openldap/TLS/CA/private/cakey.pem. Guard this file carefully by making it only readable by the root user.

6. Run CA.pl again, but with the -newreq option to create a new server certificate signing request (CSR) and its associated server private key. Follow the same guidelines as before.

Your CSR will be named newreq.pem and its private key will be newkey.pem; both will be located in your current directory.

[root@bigboy files]# /etc/pki/tls/misc/CA.pl -newreq
Note: If the server certificate is going to be used on a different server running LDAP, then you'll have to use the hostname of that server when you are generating the request.

7. Run CA.pl one more time with the -sign option. The script will use the CSR information to create a server certificate signed by your CA certificate. You will be prompted for the CA private key's PEM pass phrase as a form of validation. Answer "y" whenever you are prompted to sign the certificate and commit it to the certificate database. Follow the same guidelines for the other prompts as before.

Your new signed certificate will be named newcert.pem.

[root@bigboy files]# /etc/pki/tls/misc/CA.pl -sign

8. The newkey.pem key file in its present form will always require the PEM password for it to be used with TLS. This can cause problems when it is used by programs like the LDAP slapd daemon that don't take advantage of a keyboard. You will have to use the openssl command to remove this requirement.

[root@bigboy files]# openssl rsa -in newkey.pem -out newkey.pem
Enter pass phrase for newkey.pem:
writing RSA key
[root@bigboy files]#

9. Copy the files to their final resting place in the /etc/openssl/cacerts directory.

[root@bigboy files]# cp newkey.pem /etc/openldap/cacerts/slapd-key.pem
[root@bigboy files]# cp ../../CA/cacert.pem /etc/openldap/cacerts/
[root@bigboy files]# cp newcert.pem /etc/openldap/cacerts/slapd-cert.pem
Note: If the server certificate is going to be used on a different server running LDAP, then you'll have to copy these files to the same locations on that server.

10. Alter your LDAP server's slapd.conf file to make the TLS entries map to the newly created PEM files.

#
# File: slapd.conf
#

TLSCipherSuite          HIGH:MEDIUM:+SSLv2:+SSLv3:RSA 
TLSCertificateFile      /etc/openldap/cacerts/slapd-cert.pem
TLSCertificateKeyFile   /etc/openldap/cacerts/slapd-key.pem
TLSCACertificateFile    /etc/openldap/cacerts/cacert.pem
TLSVerifyClient         allow

11. Change the permissions and ownership of the /etc/openldap/cacerts files so they are only readable by the slapd daemon that runs as the ldap user. Also secure the contents of the /etc/openldap/TLS directory from prying eyes.

[root@bigboy files]# chown ldap:ldap /etc/openldap/cacerts/*
[root@bigboy files]# chmod 600 /etc/openldap/cacerts/*
[root@bigboy files]# chown root:root /etc/openldap/TLS
[root@bigboy files]# chmod 750 /etc/openldap/TLS

12. Restart the LDAP daemon.

[root@zippy files]# service ldap restart

配置 TLS 客户端

Configuration of the client is much quicker as you will soon see. Here are the steps:

1. Run authconfig-tui and make sure your options match these screens.

-------------------Authentication Configuration -------------------
|                                                                 |
|  User Information        Authentication                         |
|  [ ] Cache Information   [*] Use MD5 Passwords                  |
|  [ ] Use Hesiod          [*] Use Shadow Passwords               |
|  [*] Use LDAP            [*] Use LDAP Authentication            |
|  [ ] Use NIS             [ ] Use Kerberos                       |
|  [ ] Use Winbind         [ ] Use SMB Authentication             |
|                          [ ] Use Winbind Authentication         |
|                          [ ] Local authorization is sufficient  |
|                                                                 |
|            ----------                      --------             |
|            | Cancel |                      | Next |             |
|            ----------                      --------             |
|                                                                 |
|                                                                 |
-------------------------------------------------------------------


------------------- LDAP Settings -------------------
|                                                   |
|          [*] Use TLS                              |
|  Server: bigboy.my-web-site.org__________________ |
| Base DN: dc=example,dc=com_______________________ |
|                                                   |
|         --------                  ------          |
|         | Back |                  | Ok |          |
|         --------                  ------          |
|                                                   |
|                                                   |
-----------------------------------------------------

2. Review the contents of /etc/ldap.conf and make sure they have the following entries. The host must match the hostname of the certificate.

#
# File: /etc/ldap.conf
#

host           bigboy.my-web-site.org
base           dc=example,dc=com
tls_cacertdir  /etc/openldap/cacerts
ssl            start_tls

3. Review the contents of /etc/openldap/ldap.conf and make sure they have the following entries. The host must match the hostname of the certificate.

#
# File: /etc/openldap/ldap.conf
#
BASE          dc=example,dc=com
HOST          bigboy.my-web-site.org
TLS_CACERT    /etc/openldap/cacerts/cacert.pem
TLS_REQCERT   allow

4. Copy the server's /etc/openldap/cacerts/cacert.pem file to /etc/openldap/cacerts/cacert.pem on the LDAP client.

[root@smallfry tmp]# scp -P 222 \ 
root@bigboy.my-web-site.org:/etc/openldap/cacerts/cacert.pem \
/etc/openldap/cacerts/cacert.pem

5. Test your configuration by logging into your LDAP client server via SSL with the ldapuser user's credentials.

TLS Maintenance

The server certificate (slapd-cert.pem) will expire annually and will have to be regenerated every year. The CA certificate (cacert.pem) is valid for three years before having to be regenerated and recopied to all your LDAP clients. You can change these defaults in the CA.pl file by editing the $DAYS variable for the server certificate and the $CADAYS variable for the CA certificate. Make sure that $CADAYS is greater than $DAYS. Here is an example of alternative values.

$DAYS="-days 365";      # 1  year
$CADAYS="-days 1825";   # 5 years

使用 stunnel 加密

The secure tunnel (stunnel) utility can be used to intercept regular LDAP communications and encrypt it over an SSL tunnel using the TCP port of your choice. Fortunately, stunnel is installed by default on Fedora Linux, making it even easier to use.

Note: Add the SSL encryption, only after basic LDAP has been proven to work without encryption. This makes troubleshooting much easier.

Here's how to encrypt LDAP with Fedora Linux:

配置stunnel LDAP客户端

First, you configure the LDAP client to use stunnel.

1. Edit the ldap.conf file. You have to trick the LDAP client into thinking that the LDAP server is actually running locally as a daemon, so you need to set the HOST entry to localhost. You then configure the stunnel utility to intercept this traffic and relay it to the real LDAP server.

HOST localhost
BASE dc=example,dc=com


2. Create an stunnel user with the useradd command.

[root@smallfry tmp]# useradd stunnel

3. Edit the stunnel.conf configuration file in the /etc/stunnel directory, configuring it as shown.

#
# File: /etc/stunnel (LDAP Client)
#

# Configure stunnel to run as user "stunnel" placing temporary
# files in the /usr/var/run/stunnel/ directory

chroot = /home/stunnel
pid = /stunnel.pid
setuid = stunnel
setgid = stunnel

# Configure logging
debug = 7
output = /var/log/messages
 
# Use it for client mode
client = yes
 
# Service-level configuration
[ldap]
accept  = 389
connect = 192.168.1.100:636

At the very end of the file, notice that traffic on the LDAP TCP port 389 is specifically redirected to the LDAP server on TCP port 636 over the secure tunnel.

4. Start stunnel with the stunnel command.

[root@smallfry tmp]# stunnel

5. Check the log files, especially the last 100 lines of the error log file /var/log/messages, to make sure there are no errors. If there are errors, double check your stunnel configuration file for mistakes.

[root@smallfry tmp]# tail -100 /var/log/messages

6. Make sure stunnel runs on the next reboot. The script /etc/rc.local is run at the end of every boot sequence. Use the locate command to find out where the stunnel program is and then place your stunnel command in /etc/rc.local as shown.

# Run stunnel for LDAP (Fedora file location)
/usr/sbin/stunnel


配置stunnel LDAP服务器

After you configure the client, you're ready to set up stunnel on the LDAP server.

1. Create an stunnel user using the useradd command.

[root@bigboy tmp]# useradd stunnel

2. Edit the stunnel.conf configuration file located in the /etc/stunnel directory. Configure it as shown.

#
# File: /etc/stunnel (LDAP Server)
#

# Configure stunnel to run as user "stunnel" placing temporary
# files in the /usr/var/run/stunnel/ directory
chroot = /home/stunnel/
pid = /stunnel.pid
setuid = stunnel
setgid = stunnel
 
# Some debugging stuff
debug = 7
output = /var/log/messages
 
# Use it for client mode
client  = no
cert = /usr/share/ssl/certs/stunnel.pem
key =  /usr/share/ssl/certs/stunnel.pem
 
# Service-level configuration
[ldap]
accept  =  636
connect =  389

There are a few differences between the client and server stunnel.conf files. The very bottom of the file shows that all traffic received on the secure LDAP port of 636 is redirected to the application listening on LDAP port 389. The file is configured for server mode and a special SSH certificate has been defined for the encryption process. You'll create the certificates next.

3. Go to the /usr/share/ssl/certs directory and create the certificate using the make command. Use all the defaults when prompted, but make sure you use the server's IP address when prompted for your server's Common Name or hostname.

[root@bigboy tmp]# cd /usr/share/ssl/certs
[root@bigboy certs]# make stunnel.pem
...
Common Name (eg, your name or your server's hostname) []: 192.168.1.100
...
[root@bigboy certs]#

Note: The certificate created only has a 365 day lifetime. Remember to repeat this process next year.

4. Modify certificate file permissions. The certificate needs to be read by root and the stunnel user. Use the chmod and chgrp commands to do this.

[root@bigboy certs]# chmod 640 stunnel.pem
[root@bigboy certs]# chgrp stunnel stunnel.pem
[root@bigboy certs]# ll /usr/share/ssl/certs
 -rw-r-----  1 root stunnel   1991 Jul 31 21:50 stunnel.pem
[root@bigboy certs]#

5. Start stunnel with the stunnel command.

[root@bigboy tmp]# stunnel

6. Check the last 100 lines of the error log file /var/log/messages to make sure there are no errors. If you find errors, double check your stunnel configuration file for mistakes.

[root@bigboy tmp]# tail -100 /var/log/messages

The key things to look for are the loading of the certificate, the binding of LDAP to the 636 secure LDAP port, and the creation of the temporary stunnel.pid file.

2004.08.02 08:50:18 LOG7[12102:3210052320]: Certificate: /usr/share/ssl/certs/stunnel.pem
2004.08.02 08:50:18 LOG7[12102:3210052320]: Key file: /usr/share/ssl/certs/stunnel.pem
2004.08.02 08:50:18 LOG7[12102:3210052320]: ldap bound to 0.0.0.0:636
2004.08.02 08:50:18 LOG7[12103:3210052320]: Created pid file /stunnel.pid

7. Make sure stunnel runs on the next reboot. The script /etc/rc.local is run at the end of every boot sequence. Use the locate command to find out where the stunnel program is and then place your stunnel command in /etc/rc.local.

#
# File : /etc/rc.local
#
# Run stunnel for LDAP (Fedora file location)
/usr/sbin/stunnel

The final step of the preparation is to create home directories for each user to use just like in the unencrypted LDAP example before this. After this is complete, you'll need to do some basic testing which is covered in the troubleshooting section.

LDAP登录的故障排除

You can never be certain about the functioning of any application unless you test it. LDAP is fairly complicated to install and should be as thoroughly tested as possible before you deploy it. Here are some steps you can take to help you sleep better at night.

除非你测试了你的程序,否则你永远也不能肯定它能工作。LDAP在安装的时候是相当复杂的,所以也应该在部署之前尽可能的全面测试。

检查 /var/log/messages 文件

第一步是检查你在 LDAP 服务器和客户端上得到的错误信息的类型。通过这种方法,可以得到很多有价值的信息。这方面的内容在第五章详细叙述,"Troubleshooting Linux with syslog"。

测试基本连接

首先,使用 TELNET 来诊断是否你的 LDAP 服务器的 389 (LDAP) 和 636 (LDAPS) TCP端口可访问。

不能连接的原因可能是由于在 LDAP 服务器和客户端之间的连接通路上有防火墙或者它们上面安装了防火墙软件。

导致不能连接的另外原因还可能有:LDAP 服务没有启动、服务器宕机、网络连接断开等。

使用 Telnet 进行故障处理在第四章涉及,"Simple Network Troubleshooting",在网络故障处理部分。

使用 ldapsearch 测试

在 LDAP 服务器和客户端上使用 ldapsearch 命令测试 LDAP 的配置是否正确。

[root@smallfry tmp]# ldapsearch -x -b 'dc=example,dc=com' \
      '(objectclass=*)'

如果 LDAP 配置正确的话,这个命令将在你的屏幕上列出数据库的所有内容。

使用SSH 或 Linux 控制台

作为可选的测试,可以尝试使用 ldapuser 用户登陆 LDAP 客户端系统。如果登陆失败,请尝试重启 LDAP 客户端上的 SSH 服务,使它重新读取包含新的 LDAP 信息的 /etc/nsswitch.conf 配置文件。这一步在所有的 Linux 版本中都不是必须的。

使用 tcpdump 命令

如果 LDAP 配置文件看起来是正确的,但是 LDAP 始终不工作,那么你可以尝试使用 tcpdump 命令来检查你的计算机系统间的通信是否正常。这个命令在第四章有概述,"Simple Network Troubleshooting"。如果不通信可能是由于不良的路由、错误的防火墙配置,或者可能是 LDAP 的服务在服务器上已关闭。


测试一般 LDAP

首先在 LDAP 服务器上,使用 tcpdump 命令来监听通过一般 LDAP 端口(TCP 端口 389) 的流量。然后在 LDAP 客户端上执行 ldapsearch 命令。

[root@bigboy tmp]# tcpdump -n tcp port ldap

如果所有的一切都配置正确的话,你应该能够看见在 LDAP 客户端和服务器之间双向流动的 LDAP 数据包。

注意: The insecurity of unencrypted LDAP client communication can also be demonstrated by using network packet capture. In this example, the tethereal command is used with the -x flag to view the ASCII contents of LDAP traffic between client and server. The username, password, UID (100), GID (503), shell (/bin/bash) and home directory (/home/ldapuser) of the ldapuser user can all be clearly seen in clear text. It is always a good practice to add an additional layer of security with LDAP TLS encryption which will eliminate this ASCII visibility. (这段话的意思就是说非加密的 LDAP 通信中的数据有被监听窃取的危险,建议使用 TLS 加密通信)

如果你正在使用 stunnel 方法,你应该设置 tethereal 的 TCP 端口为 ldaps

[root@bigboy ~]# tethereal -n  -x -i eth0  tcp port ldap
...
...
0050  69 64 3d 6c 64 61 70 75 73 65 72 2c 6f 75 3d 50   id=ldapuser,ou=P
0060  65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65   eople,dc=example
0070  2c 64 63 3d 63 6f 6d 30 82 01 04 30 11 04 03 75   ,dc=com0...0...u
0080  69 64 31 0a 04 08 6c 64 61 70 75 73 65 72 30 10   id1...ldapuser0.
0090  04 02 63 6e 31 0a 04 08 6c 64 61 70 75 73 65 72   ..cn1...ldapuser
00e0  75 73 65 72 50 61 73 73 77 6f 72 64 31 2b 04 29   userPassword1+.)
00f0  7b 63 72 79 70 74 7d 24 31 24 47 53 77 48 53 54   {crypt}$1$GSwHST
0100  4a 49 24 71 59 4d 65 66 47 32 4f 35 77 6a 7a 70   JI$qYMefG2O5wjzp
0110  77 42 2e 32 4b 70 58 48 31 30 19 04 0a 6c 6f 67   wB.2KpXH10...log
0120  69 6e 53 68 65 6c 6c 31 0b 04 09 2f 62 69 6e 2f   inShell1.../bin/
0130  62 61 73 68 30 12 04 09 75 69 64 4e 75 6d 62 65   bash0...uidNumbe
0140  72 31 05 04 03 35 30 33 30 12 04 09 67 69 64 4e   r1...5030...gidN
0150  75 6d 62 65 72 31 05 04 03 31 30 30 30 21 04 0d   umber1...1000!..
0160  68 6f 6d 65 44 69 72 65 63 74 6f 72 79 31 10 04   homeDirectory1..
0170  0e 2f 68 6f 6d 65 2f 6c 64 61 70 75 73 65 72      ./home/ldapuser
...
...
[root@bigboy ~]#

测试安全 LDAP

On the LDAP server, when using stunnel, use the tcpdump command to listen for traffic on the secure LDAP port 636 or ldaps. With TLS you would use the regular LDAP port 389 or ldap with the command. Run the ldapsearch command on the LDAP client and if everything is configured correctly, you should see packet flows such as this one.

[root@bigboy tmp]# tcpdump -n tcp port ldaps
tcpdump: listening on eth0
09:20:02.281257 192.168.1.102.1345 > 192.168.1.100.ldaps: S 1665037104:1665037104(0) win 5840 <mss 1460,sackOK,timestamp 74401362 0,nop,wscale 0> (DF)
09:20:02.281356 192.168.1.100.ldaps > 192.168.1.102.1345: S 1911175072:1911175072(0) ack 1665037105 win 5792 <mss 1460,sackOK,timestamp 20737195 74401362,nop,wscale 0> (DF)
...
...
[root@bigboy tmp]#
Note: You can also verify the lack of ACSII strings being sent with LDAP encryption using the tetheral example used previously. Remember to use ldap for TLS encryption and ldaps when using stunnel.
[root@bigboy ~]# tethereal -n  -x -i eth0  tcp port ldaps
...
...
0000  00 b0 d0 46 32 71 00 b0 d0 4e f2 18 08 00 45 00   ...F2q...N....E.
0010  01 3e 14 2c 40 00 40 06 a1 11 c0 a8 01 64 c0 a8   .>.,@.@......d..
0020  01 c8 90 ec 01 85 95 c1 c9 95 90 a3 67 01 80 18   ............g...
0030  08 88 3c 2c 00 00 01 01 08 0a 02 3e d3 b9 02 3e   ..<,.......>...>
0040  ea 23 17 03 01 00 20 a4 47 5e c4 54 87 66 a2 5a   .#.... .G^.T.f.Z
0050  5d ef 24 77 7f 9b c5 57 84 a1 b6 f0 10 ef 3e be   ].$w...W......>.
0060  bc 91 ec 31 a2 81 5e 17 03 01 00 e0 ee 34 fc 93   ...1..^......4..
0070  f9 b9 3f ba e7 fb 97 78 3e a0 25 09 77 bf c9 b0   ..?....x>.%.w...
0080  95 30 ca 6a e8 e7 7f cc a5 77 db e5 30 e6 34 ac   .0.j.....w..0.4.
0090  e3 d0 84 98 d5 97 1a b5 9f 2b 9c 11 41 b7 ae ed   .........+..A...
00a0  0e fc 54 52 89 fd 59 b0 77 42 d4 07 96 83 33 6f   ..TR..Y.wB....3o
00b0  fb 85 dd e7 90 dc 83 44 41 1f 8f 1d d3 29 60 28   .......DA....)`(
00c0  58 a7 22 8e 6e 16 01 5f fa f1 4f 69 31 78 1e 6c   X.".n.._..Oi1x.l
00d0  a4 23 9e 89 3a 9c 25 37 da 9d 27 03 d4 17 31 9e   .#..:.%7..'...1.
00e0  30 d8 25 d8 95 57 a3 7b 7f 77 20 7b f4 ee cd 7a   0.%..W.{.w {...z
00f0  9e 72 6f 21 80 2d d0 4c 66 f3 6f 40 e0 5d 31 43   .ro!.-.Lf.o@.]1C
0100  20 3c d2 2f 60 30 71 66 a4 7e 4a d2 3b b5 7c eb    <./`0qf.~J.;.|.
0110  11 15 06 49 ab 00 46 61 b3 a5 76 7e 2c 37 9d 88   ...I..Fa..v~,7..
0120  6b f9 5e 72 e7 f3 ad 1a 94 cb 81 40 3a 7b d5 cc   k.^r.......@:{..
0130  33 23 ad 82 46 29 a8 38 df 48 ba ea 23 87 15 4b   3#..F).8.H..#..K
0140  58 99 88 45 6a 54 e4 5a 54 81 4d bc               X..EjT.ZT.M.
...
...
[root@bigboy ~]#

LDAP Works but not When I Switch to LDAPS(LDAP工作但是我切换到 LDAPS时却不工作)

An stunnel LDAPS configuration will default to using regular LDAP if there is an error with the SSL keys. This could be due to:

  • Incorrect permissions and ownerships on the key file and/or certificates.
  • Incorrectly configured ldap.conf and slapd.conf configuration files.

With TLS there could be other causes:

  • The server names in the certificates may not match the host parameters in both of the client's ldap.conf files. A typical symptom of this is the ldapsearch command working when logged in as the root user, but LDAP based logins fail.
  • Incorrectly configured ldap.conf and slapd.conf configuration files.

Stunnel 不工作

Changes to the stunnel.conf file take effect only after stunnel has been restarted. Unfortunately, there is no stunnel script in the /etc/init.d directory to do this. You have to use the pkill command to stop it and the stunnel command to start it again.

[root@bigboy tmp]# pkill stunnel ; stunnel
[root@bigboy tmp]#

LDAP_BIND 错误

The LDAP bind utility is used for each login and can give failure errors that are usually not very descriptive. Two of the main ones that usually occur when running the ldapadd command are

Can't contact LDAP server (81): This is usually caused by not configuring the correct IP address in the LDAP client's ldap.conf file.
Invalid credentials (49): This is usually caused by incorrect dc= statements in the configuration files or in commands used

在Fedora Core 2中可能出现的 stunnel 错误

在启动 stunnel 时可能出现一个 cryptonet 错误。

Unable to open "/dev/cryptonet"

这是由一个 hwcrypto 软件包不兼容导致的。这个软件包用于基于硬件的加密。为保证 stunnel 工作正常,你应该卸载 hwcrypto。

[root@bigboy tmp]# rpm -e hwcrypto

Common LDAP Administrative Tasks

Here are some explanations of how to do many common LDAP tasks. They are all based on our sample organization with DNs of example and com.

Note: You need to always make sure that there are no entries for regular users in the /etc/passwd files of the LDAP clients. These should only reside on the LDAP server.

Starting and Stopping LDAP

You can use the chkconfig command to get ldap configured to start at boot:

[root@bigboy tmp]# chkconfig ldap on

To start, stop, or restart ldap after booting, use

[root@bigboy tmp]# service ldap start
[root@bigboy tmp]# service ldap stop
[root@bigboy tmp]# service ldap restart

Remember to restart the ldap process every time you make a change to the LDAP database file for the changes to take effect on the running process.

LDAP users changing their own passwords

LDAP users can modify their LDAP passwords using the regular passwd command.

[ldapuser@smallfry ldapuser]$ passwd
Changing password for user ldapuser.
Enter login(LDAP) password:
New password:
Retype new password:
LDAP password information changed for ldapuser
passwd: all authentication tokens updated successfully.
[ldapuser@smallfry ldapuser]$

Modifying LDAP users by user "root"

One easy way for the system administrator to manage LDAP users is to modify the regular Linux users' characteristics on the LDAP server in the regular way and then run a script to automatically modify the LDAP database.

The Modify LDAP User Script

You can use the very simple sample script /usr/local/bin/modifyldapuser to extract a particular user's information from /etc/passwd and import it into your LDAP database.

The script works by using the grep command to extract the /etc/passwd user record to a temporary file. It then runs the migrate_passwd script on this data and outputs the result to a temporary LDIF file. Next, the script replaces the default padl DC with the example DC and exports this to the final LDIF file. Finally, the ldapmodify command does the update, and then the temporary files are deleted.

#!/bin/bash
 
grep $1 /etc/passwd > /tmp/modifyldapuser.tmp
 
/usr/share/openldap/migration/migrate_passwd.pl \
   /tmp/modifyldapuser.tmp /tmp/modifyldapuser.ldif.tmp
 
cat /tmp/modifyldapuser.ldif.tmp | sed s/padl/example/ \
    > /tmp/modifyldapuser.ldif
 
ldapmodify -x -D "cn=Manager,dc=example,dc=com" -W -f \
    /tmp/modifyldapuser.ldif
 
rm -f /tmp/modifyldapuser.*

Remember to make the script executable and usable only by user root with the chmod command.

[root@bigboy tmp]# chmod 700 /usr/local/bin/modifyldapuser
[root@bigboy tmp]#

To use the script, modify the Linux user. In this case, modify the password for user ldapuser by running the modifyldapuser script using ldapuser as the argument. You will be prompted for the LDAP root password.

[root@bigboy tmp]# passwd ldapuser
Changing password for user ldapuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@bigboy tmp]# modifyldapuser ldapuser
Enter LDAP Password:
modifying entry "uid=ldapuser,ou=People,dc=example,dc=com"
[root@bigboy tmp]#

Adding new LDAP users

You can use the short script in this section to add LDAP users to your database. I'll also provide an example of how to use it.

Create an LDAP Add User Script

You can create a /usr/local/bin/addldapuser script based on the modifyldapuser script you created earlier. For example:

#!/bin/bash

grep $1 /etc/passwd > /tmp/changeldappasswd.tmp
 
/usr/share/openldap/migration/migrate_passwd.pl \
    /tmp/changeldappasswd.tmp /tmp/changeldappasswd.ldif.tmp
 
cat /tmp/changeldappasswd.ldif.tmp | sed s/padl/example/ \
    > /tmp/changeldappasswd.ldif
 
ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f \
    /tmp/changeldappasswd.ldif
 
rm -f /tmp/changeldappasswd.*

Add the User to the Database

Adding the user to database takes three steps:

1. Create the Linux user on the LDAP server.

2. Run the addldapuser script with the username as the only argument. This example imports a previously created Linux user named ldapuser. The script prompts you for your LDAP root password.

[root@bigboy tmp]# addldapuser ldapuser
Enter LDAP Password:
adding new entry "uid=ldapuser,ou=People,dc=example,dc=com"
[root@bigboy tmp]#

3. Create home directories for the user on all the LDAP client Linux boxes.

Remember that this script adds existing Linux users to the LDAP database. The creation of Linux users still requires the use of the adduser command.

Deleting LDAP users

Sometimes you want to get rid of users instead of add them. You can create a /usr/local/bin/deleteldapuser script to delete LDAP users from your database. For example

#!/bin/bash
 
ldapdelete -x -W -D "cn=Manager,dc=example,dc=com" \
     "uid=$1,ou=People,dc=example,dc=com"
 

To delete the user from the database, run the deleteldapuser script with the username as the only argument. This example below deletes a previously created Linux user named ldapuser. The script prompts you for your LDAP root password.

[root@bigboy tmp]# deleteldapuser ldapuser
Enter LDAP Password:
[root@bigboy tmp]#

LDAP Web Management Tools

Once you understand the principles behind LDAP management, you may want to use a graphical tool to help with further administration. If the tool misbehaves, at least you'll now know how to try to fix it behind the scenes from the command line.

The LDAP Account Manager (LAM), which is available at http://lam.sourceforge.net, is a well known, easy-to-use product. After you feel comfortable enough with the background tasks and concepts outlined in this chapter, you should give it a try.

Configuring RADIUS for LDAP

Many network equipment manufacturers use an authorization scheme called RADIUS to filter the types of activities a user can do. The Linux FreeRADIUS server can be configured to talk to a Linux LDAP server to handle login authentication services. In other words, the user logs into the equipment, which then sends a username/password combination to the RADIUS server, the RADIUS server queries the LDAP server to see if the user is a valid one, and then replies to the network equipment with the desired login privileges if the LDAP query is successful.

You'll have to refer to your manufacturer's manuals on how to configure RADIUS, but fortunately researching how the FreeRADIUS server interacts with the Linux LDAP server is much simpler. Here are the steps.

How To Download and Install The FreeRADIUS Packages

Most RedHat and Fedora Linux software products are available in the RPM format. When searching for the file, remember that the FreeRADIUS RPM's filename usually starts with freeradius followed by a version number, as in freeradius-0.9.1-1.i386.rpm.

Starting and Stopping FreeRADIUS

You can use the chkconfig command to get the FreeRADIUS daemon, radiusd, configured to start at boot:

[root@bigboy tmp]# chkconfig radiusd on

To start, stop, and restart radiusd after booting, use

[root@bigboy tmp]# service radiusd start
[root@bigboy tmp]# service radiusd stop
[root@bigboy tmp]# service radiusd restart

Remember to restart the radiusd process every time you make a change to the configuration files for the changes to take effect on the running process.

Configuring The /etc/raddb/radiusd.conf File

The /etc/raddb/radiusd.conf file stores the main RADIUS configuration parameters. You'll have to update some of the settings to allow LDAP queries from RADIUS.

1. Activate the use of the LDAP module in the authorize section of the file by uncommenting the word ldap.

authorize {
    ...
    ...
    #
    #  The ldap module will set Auth-Type to LDAP if it has not
    #  already been set
    Ldap
    ...
    ...
}

2. Activate the use of the LDAP module in the authenticate section by uncommenting the Auth-Type block for LDAP:

Auth-Type LDAP {
     ldap
}

3. Define the LDAP domain, LDAP server, and password methods to be used in the ldap block. In the example, the LDAP and RADIUS server is the same machine, so you set the LDAP server IP address to localhost.

ldap {
 
     # Define the LDAP server and the base domain name
 
     server = "localhost"
     basedn = "dc=example,dc=com"
 
     # Define which attribute from an LDAP "ldapsearch" query
     # is the password. Create a filter to extract the password
     # from the "ldapsearch" output
 
     password_attribute = "userPassword"
     filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
 
     # The following are RADIUS defaults
     start_tls = no
     dictionary_mapping = ${raddbdir}/ldap.attrmap
     ldap_connections_number = 5
     timeout = 4
     timelimit = 3
     net_timeout = 1
}

These configuration steps only cover how to configure RADIUS to interact with LDAP. You'll have to define the login attributes and privileges each user will receive and the IP addresses of the varius RADIUS clients. We'll cover these topics next.

Configuring The /etc/raddb/users File

The /etc/raddb/users file defines the types of attributes a user receives upon login. In the case of a router, this may include allowing some user groups to login to a device in a privileged mode, while allowing other only basic access.

One of the first entries in this file is to check the local server's /etc/passwd file. The very next entry should be one referring to your LDAP server with a fall through statement that will allow additional authorizations to be granted to the LDAP user further down the file based on other sets of criteria.

#
# First setup all accounts to be checked against the UNIX /etc/passwd.
#
DEFAULT Auth-Type = System
Fall-Through = 1
 
#
# Defaults for LDAP
#
DEFAULT Auth-Type := LDAP
Fall-Through = 1

Configuring The /etc/raddb/clients.conf File

You can define a shared secret password key to be used by the RADIUS server and its clients in the /etc/raddb/clients.conf file.

Passwords can be allocated for ranges of IP addresses in each network block using the secret keyword. The next example defines the password testing123 for all queries from localhost, but s3astar for the 192.168.1.0/24 network and shrtp3nc1l for the 172.16.1.0/24 network. All RADIUS clients have to peer with the RADIUS server from these networks using the correct password before logins are correctly accepted.

client 127.0.0.1 {
     secret = testing123
     shortname = localhost
}
 
client 192.168.1.0/24 {
     secret = s3astar
     shortname = home-network
}

client 172.16.1.0/24 {
     secret = shrtp3nc1l
     shortname = office-network
}

Troubleshooting And Testing RADIUS

You can now test the various elements of the RADIUS setup:

Server Setup

To test the server, run radiusd in debug mode to see verbose messages about the status of the RADIUS queries. These messages are much more informative than those provided in the /var/log/messages and /var/log/radius/radius.log files.

[root@bigboy tmp]# /usr/sbin/radiusd -X -A

After testing is complete, you must start the radiusd daemon in the normal manner using the command service radiusd start.

Linux Client Setup

For Linux clients, you can perform RADIUS queries with the radtest command. The arguments are the LDAP username, the LDAP user's password, the LDAP server IP address, an NAS port value (any value between 1 and 100 will work here), and the RADIUS client-server shared secret password key. Successful queries will show an Access-Accept message.

A successful test from the RADIUS server looks like this.

[root@bigboy tmp]# radtest ldapuser "ldapuser-password" \
  localhost 2 testing123
...
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=99, length=20
...
[root@bigboy tmp]#

A successful test from a Linux RADIUS client looks like this:

[root@smallfry bin]# radtest ldapuser "ldapuser-password" 192.168.1.100 2 s3astar
...
rad_recv: Access-Accept packet from host 192.168.1.100:1812, id=51, length=20
...
[root@smallfry bin]#

In this case, freeradius was installed solely for the purposes of testing the shared secret password key from another network. This is a good troubleshooting tip to verify remote client access before deploying network equipment.

Cisco Client Setup

Here is a sample snippet of how to set up a Cisco device to use a RADIUS server. You can find full coverage of Cisco authentication, authorization, and accounting (AAA) setup using RADIUS on Cisco's corporate Web site at www.cisco.com.

aaa new-model
aaa authentication login default radius enable
aaa authentication ppp default radius
aaa authorization network radius
 
radius-server host 192.168.1.100
radius-server timeout 10
radius-server key shrtp3nc1l

The important thing to note in relation to our setup is that the radius-server statements define the RADIUS server's IP address and the shared secret password key.

Errors With Fedora Core 2

The interaction between LDAP and RADIUS on Fedora Core 2 seems to be plagued with a segmentation fault error that you can see on the RADIUS server when running in debug mode. The error looks like this:

ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection 
rlm_ldap: (re)connect to localhost:389, authentication 0
rlm_ldap: bind as / to localhost:389
 Segmentation fault

The only solution I have found is to install the Fedora Core 1 versions of the RADIUS and LDAP RPMs and to edit the /etc/yum.conf file to prevent them from being automatically updated to newer versions.

Conclusion

LDAP is rapidly becoming a defacto standard for remote authentication and authorization of users, not only in the realm of Linux, but also in that of Windows where it is a key component of Active Directory. Usage of LDAP is also becoming increasingly widespread in wireless networking systems. For example in hot spots, ISPs will sacrifice data security for the sake of convenience by not using encryption, but will use LDAP to restrict access to the Internet to people who have purchased pre-paid access codes with a predefined lifetime.

Chapter 32, "Controlling Web Access with Squid", covers the use of the Linux Squid application to cache Web content, restrict Web access by the time of day and via password prompts. Although it is beyond the scope of this book, you should know that you can use LDAP can to complement the functionality of Squid in larger implementations.