9、 使用SASL

OpenLDAP客户端和服务器能够通过简单认证和SASL框架(在RFC2222中详细描述)来认证用户。本章描述了如何在OpenLDAP中使用SASL。

SASL可以和几种工业标准的认证机制一起工作。包括Kerberos V4，GSSAPI，已经其他的一些摘要机制。标准的OpenLDAP提供的客户端工具，比如ldapsearch(1)以及ldapmodify(1)，默认情况下将试图使用SASL来向slapd(8)服务器认证用户。基本的认证服务可以让LDAP管理员在几个步骤中设置好，允许用户以他们的LDAP条目的身份向slapd服务器进行认证。通过另外几个步骤，用户和服务可以利用SASL的授权机制，允许他们认证自己，然后，切换他们的身份到其他的用户或者服务。

本章假设您已经阅读过了Cyrus SASL系统管理指南，该指南和Cyrus SASL软件包一起提供（在/doc/sysadmin.html）。

注意，下面的文本中，术语“用户”来描述一个通过一个LDAP客户端（比如ldapsearch(1)）连接到LDAP服务器的人或者应用程序实体。也就是说，术语“用户”不只是使用LDAP客户端的个人，还有不同过用户的直接控制而发起LDAP客户端操作的应用程序实体。比如，一个使用LDAP来获取存放在一个LDAP服务器中的信息的电子邮件服务器就是一个应用程序实体。

9.1、 SASL安全考虑

SASL提供了多种不同的认证机制。本部分简要列出安全方面的考虑。

一些人正机制，比如PLAIN和LOGIN，没有提供比LDAP的“简单”认证更高的安全性。和“简单”认证一样，除非您有足够的安全保护措施，不应该使用这种机制。推荐这种机制只是和传输层安全（TLS）一起使用。本文档将不再讨论使用PLAIN和LOGIN机制。

DIGEST-MD5机制是LDAPV3中强制要求实现的认证机制。虽然DIGEST-MD5和可信第3方的认证系统（比如Kerberos或者公用密钥系统）比较起来，没有提供足够强度的安全，但是，它的确提供了一个能够防护多种攻击的保护措施。和CRAM-MD5 的机制不同，它防止了选择明文攻击。DIGEST-MD5比脆弱的甚至是危险的使用明文口令的机制要好得多。和DIGEST-MD5比较，CRAM-MD5要差一些。下面会讨论使用DIGEST-MD5。

KERBEROS_V4认证机制使用了Kerberos IV来提供安全的认证服务。还有基于GSSAPI的认证机制，主要用来和Kerberos V一起使用。Kerberos被认为是一个安全的，分布式的认证系统，并且适合于小规模和大规模的企业。下面会讨论使用KERBEROS_V4和GSSAPI。

EXTERNAL机制利用了底层网络服务（比如TLS）提供的认证服务。当和TLS 基于X.509的公用密钥系统一起使用时，EXTERNAL机制提供了高强度的认证机制。在“使用TLS”一章中将讨论使用EXTERNAL。

还有其他的强度认证机制可以选择，包括OTP（one time passwords）和SRP（secure remote passwords）。这些机制在本文档中没有讨论。

9.2、 SASL认证

运行基本的SASL认证需要几个步骤。第1步是配置slapd服务器环境，让它可以和客户端的程序使用您站点的安全系统进行通信。这通常包括设置一个服务密钥，一个公用密钥，或者其他形式的秘密。第2步的重点在于将认证身份映射到LDAP的DN，这取决于目录中的条目是怎样组织的。下一部分将给出一个使用Kerberos V4作为示例机制来完成第1个步骤的解释。将您的站点配置为使用验证机制的步骤是很相似的。但是，本章没有提供SASL中包含的每一种认证机制的指南。再下一个部分则描述了将认证身份映射到DN的步骤。

9.2.1、 GSSAPI

本部分描述了使用和OpenLDAP一起使用SASL的GSSAPI机制和Kerberos V。假设已经部署了Kerberos V，并且您熟悉系统的操作，而且，您的用户已经被培训过使用系统。本部分还假设您已经通过阅读Configuring GSSAPI和Cyrus SASL (和Cyrus SASL一起提供，位于doc/gssapi文件)，并且熟悉了使用GSSAPI的机制，并且，成功的试验过Cyrus提供的样例服务器和样例客户端程序。有关Kerberos的更多的信息，可以从http://web.mit.edu/kerberos/www/获取。

为了和slapd(8)一起使用GSSAPI，必须首先创建一个服务密钥，该密钥应该具有一个服务所运行的域中的主机域的ldap主题词。比图，如果您在directory.example.com上运行slapd，并且您的域是EXAMPLE.COM，您需要创建一个服务密钥，该密钥使用下面的主题词：

ldap/[email protected]

当slapd(8)运行的时候，它必须有权访问该密钥。通常情况下，可以将该key放置到一个keytab中。比如：/etc/krb5.keytab。

为了使用GSSAPI认证机制来认证目录，用户在运行LDAP客户端之前首先获得一个Ticket Granting Ticket（TGT）。当使用OpenLDAP客户端工具的时候，用户可以通过在命令行中指定-Y GSSAPI选项来要求使用GSSAPI认证机制。

为了认证和授权，slapd(8)和一个没有映射的认证DN相关联，该DN的格式如下：

uid=principal,cn=GSSAPI,cn=auth

如果用户的主题词在同一个域中，该域从主题词中删除。继续我们的示例，一个具有Kerberos主题词[email protected]的用户将具有下面的DN：

uid=kurt,cn=GSSAPI,cn=auth

主题词ursula@@FORIEGN.REALM将具有下面的DN：

ursula@@FORIEGN.REALM

9.2.2、 KERBEROS_V4

该部分描述了和OpenLDAP一起使用SASL KERBEROS_V4认证机制。假设您已经熟悉了Kerberos IV安全系统的工作过程，并且您的站点已经部署了Kerberos IV。您的用户应该熟悉认证策略，并且知道如何从一个Kerberos ticket cache中接受证书，以及如何更新将要到期的证书。

客户端程序在连接到您得LDAP服务器的时候，需要能够获取一个会话密钥，这允许LDAP服务器知道用户的身份，并且允许客户端知道，它正在连接一个正确的服务器。如果使用了加密层，会话密钥同样可以用来帮助实现握手。

Slapd服务器运行叫做“ldap”的服务，并且服务器需要一个带有服务密钥的srvtab文件。支持SASL的客户端程序将获取一个带有该用户的ticket granting ticket(TGT)的“ldap”服务ticket，并且该ticket匹配OpenLDAP服务器的主机名。例如，如果您的域叫做EXAMPLE.COM，并且slapd服务器运行在主机directory.example.com上，服务器上的/etc/srvtab文件将具有一个服务密钥：

[email protected]

当一个LDAP客户端使用KERBEROS_IV向目录进行验证的时候，它将请求一个相同主题的会话密钥。要么从ticket cache，要么从Kerberos服务器获取一个新的。这就要求该TGT在cache中是可用的并且是正确的。如果不存在或者已经过期，SASL将打印出下面的信息：

ldap_sasl_interactive_bind_s: Local error

当获取了服务ticket之后，它将被传递给LDAP服务器用来证明用户的身份。服务器将使用SASL库调用，从服务ticket中解析出身份和域信息，并将它们转换成一个如下格式的验证请求DN：

uid=,cn=,cn=,cn=auth

因此，在我们上面的例子中，如果用户名称是“adamson”，认证请求DN将是：

uid=ADAMSON,cn=EXAMPLE.COM,cn=KERBEROS_V4,cn=AUTH

这个认证请求DN可以被放到ACL中的或者groupOfNames的“member”属性中。因为它是合法的LDAP DN格式。下一部分将阐述如何将该DN映射到个人自己的LDAP条目的DN。

同时注意在该示例中，因为是Kerberos，显示了DN中的部分被使用公司的Kerberos域进行填充。几个其他的认证机制不使用域的概念，因此，认证请求DN中的“,cn=”部分不会出现。

9.2.3、 将认证身份映射到LDAP条目

slapd服务器中的认证机制将基于底层使用的认证机制，使用SASL库调用来获得已认证用户的用户名。该用户名是在认证机制的名字空间中。不是在LDAP空间中。正如上面的部分所显示的，用户名被重新格式化为如下格式的一个认证请求DN：

uid=,cn=,cn=,cn=auth

或者：

uid=,cn=,cn=auth

取决于认证机制是否使用了“域”的概念。

这并不意味着您应该将上述LDAP条目增加到您的LDAP数据库中。如果您对于每一个将要在LDAP中验证的人都在LDAP目录树中有一个LDAP条目，并且该树不是以cn=auth开始。但是，如果您的站点用户名和LDAP中该用户的条目之间有一个清晰的映射，您可以配置您的LDAP服务器自动映射一个用户的验证用户名到他们的验证DN。

LDAP管理员将需要告诉LDAP服务器，如何映射一个认证请求DN到一个用户的认证DN。这可以通过在slapd.conf(5)文件中增加一个或者多个saslRegexp指令来实现。该指令使用两个参数：

saslRegexp     

认证请求DN和使用正则表达式函数regcomp()和regexec()，与相比较。如果匹配，它将被使用重写。如果有多个saslRegexp指令，只使用第一个匹配的认证身份。从输出的字符串应该是用户的认证DN，使用合法的LDAP DN格式。它也可以是一个LDAP URL，在下面的部分讨论。

search pattern可以包含在regexec(3C)中列出的任何正则表达式字符。主要的需要注意的“.”，“*”，和“()”。

本质上，“.”匹配任何字符，“*”匹配1个或者多个字符，“()”中的字符被记住用来给使用。

将产生用户的最后的验证DN。任何验证请求DN中匹配的“()”中的部分被保存在变量“$1”。变量$1可以出现在中，并且将被验证请求DN中的字符串替换。如果中有多个“()”，将使用变量$2，$3，等等。

比如，假设用户的验证身份是如下所示的DN字符串：

uid=ADAMSON,cn=EXAMPLE.COM,cn=KERBEROS_V4,cn=AUTH

该用户的实际LDAP条目是：

uid=ADAMSON,ou=PERSON,dc=EXAMPLE,dc=COM

slapd.conf(5)中的saslRegexp指令应该如下所示：

saslRegexp

  uid=(.*),cn=example.com,cn=kerberos_v4,cn=auth

  uid=$1,ou=person,dc=example,dc=com

一个更加宽松的规则可以这样写：

saslRegexp

  uid=(.*),.*cn=auth

  uid=$1,ou=person,dc=example,dc=com

如果要设置更加宽松的搜索模式，一定要小心。因为可能会错误的允许个人作为一个他们不应该有访问权限的DN通过认证。最好写几个严格一点的指令，而不要写一个宽松的可能会有安全漏洞的指令。如果您的站点只有一种验证机制，并且不使用或者只使用一个域，您可能可以在验证身份和LDAP的DN之间使用一个单一的saslRegexp指令进行认证。

有一些站点将个人的DN扩展到LDAP树的多个区域，比如，有一个ou=accounting树和一个ou=engineering树，并且个人信息分布在它们之间。或者，在认证身份中没有足够的信息来区分DN，比如，如果上面的人员的LDAP条目如下所示：

dn: cn=mark adamson,ou=person,dc=example,dc=com

objectclass: Person

cn: mark adamson

uid: adamson

在这种情况下，认证身份中的信息只能被用来查找用户的DN，而不能直接从中产生用户的DN。对于这些情况以及其他的情况，saslRegexp指令中的需要用来产生一个LDAP URL，如下面的部分所描述的。

9.2.4、 为个人DN执行搜索

当在认证信息中没有足够的信息来直接产生个人的认证DN时，slapd.conf(5)中的saslRegexp指令将需要产生一个LDAP URL。该URL将被用来对LDAP内部的数据库执行搜索，以找到该人员的验证DN。

一个LDAP URL，和其他的URL相似，具有如下格式：

ldap:///???

这包含了执行一个LDAP搜索所需要的所有元素：服务器的名称，LDAP DN搜索的基，用来获取LDAP属性的，搜索范围，可以使下面的3个选项之一：“base”，“one”或者“sub”，最后是LDAP的搜索过滤。因为该搜索是在本地机器上执行的LDAP DN搜索，部分将被忽略。基于相同的原因，部分也被忽略，因为只有DN才是有用的。这两个元素在URL格式中保留是为了使得什么信息在字符串中的什么地方更加清楚。

假设上面的例子中的个人的确有一个叫做“adamson”的认证用户名，并且该信息在LDAP条目的“uid”属性中保存。saslRegexp指令应该如下书写：

saslRegexp

  uid=(.*),cn=example.com,cn=kerberos_v4,cn=auth

  ldap://localhost/ou=person,dc=example,dc=com??sub?uid=$1

这将会初始化一个对于slapd服务器的LDAP数据库的内部搜索。如果该搜索返回正好一个条目，它被接受为该用户的DN，如果超过一个或者没有返回条目，认证将会失败，用户连接被作为认证请求DN保留。

注意，如果URL中的搜索范围是“base”，唯一返回的LDAP条目将是搜索数据库DN，因此，实际上不会搜索数据库。这和上一部分中的直接将设置为DN的指令是等价的。

在URL中的搜索过滤中指定的属性应该被索引，以允许更快速的查找。如果没有，认证过程可能会很长，用户可能会认为服务器down机了。

9.3、 SASL授权

SASL提供了一个特性，叫做授权。它允许一个认证过的用户请求作为另外一个用户执行操作。该过程在用户得到一个认证DN之后执行，并且，包括向服务器发送一个授权身份。服务器将做出判断，允许或者拒绝授权发生。如果允许，该用户的LDAP连接切换到具有一个从授权身份中派生的绑定DN，LDAP会话以新的授权DN的访问权限继续。

判断允许一个授权是否继续，取决于运行LDAP的站点的规则和策略。并且不能单独由SASL完成。SASL库让服务器做出判断。LDAP管理员设置规则，通过在LDAP数据库条目中增加信息来确定谁可以授权给什么身份。

9.3.1、 授权的使用

该服务当一个实体需要以其他用户的身份执行操作时是非常有用的。比如，用户可能被定向到一个Web页面来修改他们在LDAP条目中的个人信息。用户向Web服务器进行认证来建立他们的身份。但是，Web服务器CGI不能作为该用户向LDAP服务器进行认证，以便修改改变。作为替代，Web服务器可以向LDAP服务器作为一个服务身份进行认证。比如：

cn=WebUpdate,dc=example,dc=com

然后，它将授权作为该用户的DN。授权之后，CGI将用户的LDAP条目做出改变，只要slapd服务器可以通过ACL。在连接的另外一端，是用户自己。用户本来可以以自己的身份直接连接到LDAP服务器，但是，这将需要用户具有更多有关LDAP客户端的知识。而Web页面提供了一个更简单的格式。

授权同样可以被用来限制一个对数据库具有更高访问权限的账户。该帐户甚至可以是在slapd.conf(5)中指定的root DN，它具有一个严格的个人列表，该列表可以授权为该DN。为了成为该DN，用户必须首先作为列表中的人员进行认证。这可以将谁对LDAP数据库进行了更新做出更好的审计。如果个人被允许直接认证为特权账户，很可能是直接通过slapd.conf(5)中的rootpw，或者通过一个userPassword属性，审计将会比较困难。

注意，在一个成功的授权之后，原始的LDAP连接中的认证DN被新的授权请求中的DN所替换。如果一个服务程序可以作为它自己的认证DN进行认证，然后授权作为其他的DN，并且，它还将在一个LDAP会话中切换到多个不同的身份，它将需要在每次授权作为其他DN的时候验证自己。slapd服务器不会保留服务程序切换到其他DN的能力的记录。在象Kerberos认证机制之类的机制上，这并不需要向Kerberos服务器进行多个连接，因为用户的TGT和“ldap”会话密钥在ticket的几个小时的生存期内可以被多次合法使用。

9.3.2、 为身份授权

授权身份通过ldapsearch的-X开关或者其他的工具发送给slapd服务器。或者是通过lutil_sasl_defaults()函数调用的*authzid参数。授权身份可以是以下两种格式之一，或者是：

u:

或者：

dn:

在第一种格式中，是来自于和上面的认证身份相同的名字空间。它是被底层认证机制引用的用户名。这种格式的认证身份被使用和认证过程相同的函数转换成一个DN格式。产生出如下所示的认证请求DN格式：

uid=,cn=,cn=auth

授权请求DN然后被使用相同的saslRegexp过程，转换成数据库中的一个合法的授权DN。如果由于一个错误的LDAP URL搜索而导致不能转换，授权请求将因为“不适当的访问”而失败。否则，DN字符串现在是一个合法的授权DN格式，等待批准。

如果授权DN以第二种格式给出，使用一个{EX:"dn:"}}前缀，前缀之后的字符串已经是一个合法的授权请求DN，等待批准。

9.3.3、 授权规则

一旦slapd获得了授权DN，就开始了真正的批准过程。LDAP管理员可以将两个属性放到LDAP条目中来允许授权：

saslAuthzTo

saslAuthzFrom

两个属性都可以是多值的。第一个称为源规则。它被放到个人认证DN条目中，来说明该个人可以被允许切换到的授权DN。第二个被称为目的规则，它被放到个人一个授权DN条目中，来说明要切换到该授权DN，个人必须来自于哪一个认证DN。选择哪种方法取决于系统管理员。源规则在个人的认证DN条目中首先被检查。如果没有指明允许授权的saslAuthzTo，则检查在授权DN条目中saslAuthzTo规则。如果没有指明任何授权规则，请求将被拒绝。返回“不适当的访问”。因为默认的行为是拒绝授权请求，因此只能指明允许的规则；没有相反的指明拒绝授权的规则。

在这两个属性中的值和saslRegexp指令的输出具有相同的格式：或者是一个DN，或者是一个LDAP URL。比如，如果一个saslAuthzTo的值是一个DN，该DN就是用户可以授权为的DN；另外，如果saslAuthzTo的值是一个LDAP URL，该URL被用来执行内部LDAP数据库的搜索，然后，认证过的用户可以授权为搜索过程返回的任何DN。如果一个LDAP条目如下所示：

dn: cn=WebUpdate,dc=example,dc=com

saslAuthzTo: ldap://host/dc=example,dc=com??sub?objectclass=Person

那么，任何作为cn=WebUpdate,dc=example,dc=com认证的用户将可以授权为在搜索根dc=example,dc=com下，并且是具有“Person”对象的任何其他的LDAP条目。

9.3.3.1、 授权规则中的注意事项

在一个saslAuthzTo或者saslAuthzFrom属性中的一个LDAP URL将返回一组DN。每一个返回的DN将会被检查。返回大量的DN集合将导致授权过程消耗很长的时间。同样，应该在slapd创建了索引的属性上执行搜索。

为了让saslAuthzTo和saslAuthzFrom产生更加大量的规则，这两个属性的值可以是包含正则表达式字符的DN。这意味着如下所示的源规则：

saslAuthzTo: uid=.*,dc=example,dc=com

将允许一个通过认证的用户授权为任何符合给出的正则表达式模式的DN。该正则表达式可以比一个“uid=*”的LDAP查询执行的快的多。

同时注意，在一个授权规则中的值必须是两种格式之一：一个LDAP URL或者是一个DN（使用或者不使用正则表达式字符）。任何不以“ldap://”开头的东西都将作为DN。不可能输入另外一个格式是“u:”的授权身份作为一个授权规则。

确定使用哪一种规则，saslAuthzTo或者saslAuthzFrom， 取决于站点的情况。比如，如果可以授权为一个给定身份的一组用户可以很简单的通过书写一个搜索过滤来表示，应该使用一个简单的目的规则；如果一组用户不能 简单的被一个搜索过滤来定义，并且该组用户的数量很小，更好的方法是，在那些应该被允许授权的个人的条目中书写一个源规则。

10、 使用TLS

OpenLDAP客户端和服务器可以使用传输层安全TLS框架来提供完整性和机密性保护。并且通过SASL EXTERNAL来支持LDAP认证。

11、 构建分布式目录服务

对于许多站点而言，运行一个或者多个slapd(8)服务器，它们保存了整个的数据树，就足够了。但是，经常需要让一个slapd对于特定的树的部分引用其他的目录服务（可能运行或者不运行slapd）。

slapd支持下级和上级知识信息。

11.1、 下级知识信息

下级知识信息可以被用来代表一个子树。下级知识信息在目录中的代理点上作为一个特殊的引用对象被保存。该引用对象作为一个代理点来操作，将两个服务联系在一起。这种机制允许创建一个层次型的目录服务。

一个引用对象具有一个referral结构型的对象类，并且具有和被代理的子树相同的DN。通常，引用对象将提供一个辅助对象类extensibleObject。这允许一个条目包含正确的RDN数值。这最好通过一个例子来说明。

假设服务器a.example.com保存了dc=example,dc=net，并且希望将子树ou=subtree,dc=example,dc=net用另外一个服务器b.example.net代理，下面的命名引用对象应该被增加到a.example.net：

dn: dc=subtree,dc=example,dc=net

objectClass: referral

objectClass: extensibleObject

dc: subtree

ref: ldap://b.example.net/dc=subtree,dc=example,dc=net

该服务器通过这些信息来产生引用，并且搜索将在下级服务器上继续进行。

对于熟悉X.500的用户而言，一个命名引用对象和X.500中在subr DSE中保存的知识引用是很相似的。

11.2、 上级知识信息

上级知识信息可以使用referral指令说明。其值是一个引用到上级目录服务的URL列表。对于没有直接上级的服务器，比如上面的示例中的a.example.net，服务器可以配置为使用全局知识的目录服务，比如，OpenLDAP的根服务（http://www.openldap.org/faq/index.cgi?file=393）。

referral        ldap://root.openldap.org/

但是，因为a.example.net是b.example.net的直接上级，b.example.net应该被配置如下：

referral        ldap://a.example.net/

服务器使用这些信息来对于对如下信息的操作产生操作的引用：不在数据库中保存的名字空间中的信息；或者是名字空间中作为下级的信息。

对于熟悉X.500的用户而言，一个命名引用对象和X.500中在supr DSE中保存的知识引用是很相似的。

11.3、 ManageDsaIT控制

增加，修改和删除引用对象通常是使用ldapmodify(1)或者类似的支持ManageDsaIT控制的工具实现。ManageDsaIT控制通知服务器，你需要将引用object作为一个正常的条目来修改。这阻止服务器对于那些访问或者修改引用对象的请求发送一个引用结果。ldapmodify(1)的-M参数允许ManageDsaIT。例如：

ldapmodify -M -f referral.ldif -x -D "cn=Manag,dc=example,dc=net" -W

或者使用ldapsearch(1)：

ldapsearch -M -b "dc=example,dc=net" -x "(objectclass=referral)" '*' ref