本章包含以下主题:
LDIF 是一种基于文本的格式,用于描述目录服务实体及其属性。使用 LDIF 格式,可以借助 ldapadd 和 ldapmodify 等命令将信息从一个目录移到另一个目录。下面是每个服务的 LDIF 格式示例。使用带有 -l 选项的 ldaplist(1) 可以显示以下信息:
% ldaplist -l hosts myhost
hosts dn: cn=myhost+ipHostNumber=7.7.7.115,ou=Hosts,dc=mydc,dc=mycom,dc=com cn: myhost iphostnumber: 7.7.7.115 objectclass: top objectclass: device objectclass: ipHost description: host 1 - floor 1 - Lab a - building b |
% ldaplist -l passwd user1
passwd dn: uid=user1,ou=People,dc=mydc,dc=mycom,dc=com uid: user1 cn: user1 userpassword: {crypt}duTx91g7PoNzE uidnumber: 199995 gidnumber: 20 gecos: Joe Smith [New York] homedirectory: /home/user1 loginshell: /bin/csh objectclass: top objectclass: shadowAccount objectclass: account objectclass: posixAccount |
% ldaplist -l services name
services dn: cn=name+ipServiceProtocol=udp,ou=Services,dc=mydc,dc=mycom,dc=com cn: name cn: nameserver ipserviceprotocol: udp ipserviceport: 42 objectclass: top objectclass: ipService |
% ldaplist -l group mygroup
group dn: cn=mygroup,ou=Group,dc=mydc,dc=mycom,dc=com cn: mygroup gidnumber: 4441 memberuid: user1 memberuid: user2 memberuid: user3 userpassword: {crypt}duTx91g7PoNzE objectclass: top objectclass: posixGroup |
% ldaplist -lnetgroup mynetgroup
netgroup cn=mynetgroup,ou=netgroup,dc=central,dc=sun,dc=com objectclass=nisNetgroup objectclass=top cn=mynetgroup nisnetgrouptriple=(user1..mydc.mycom.com,-,) nisnetgrouptriple=(user1.,-,) membernisnetgroup=mylab |
% ldaplist -l networks 200.20.20.0
networks dn: ipNetworkNumber=200.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com cn: mynet-200-20-20 ipnetworknumber: 200.20.20.0 objectclass: top objectclass: ipNetwork description: my Lab Network ipnetmasknumber: 255.255.255.0 |
% ldaplist -l netmasks 201.20.20.0
netmasks dn: ipNetworkNumber=201.20.20.0,ou=Networks,dc=mydc,dc=mycom,dc=com cn: net-201 ipnetworknumber: 201.20.20.0 objectclass: top objectclass: ipNetwork description: my net 201 ipnetmasknumber: 255.255.255.0 |
% ldaplist -l rpc ypserv
rpc dn: cn=ypserv,ou=Rpc,dc=mydc,dc=mycom,dc=com cn: ypserv cn: ypprog oncrpcnumber: 100004 objectclass: top objectclass: oncRpc |
% ldaplist -l protocols tcp
protocols dn: cn=tcp,ou=Protocols,dc=mydc,dc=mycom,dc=com cn: tcp ipprotocolnumber: 6 description: transmission control protocol objectclass: top objectclass: ipProtocol |
% ldaplist -l bootparams myhost
bootparams dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com bootparameter: root=boothost:/export/a/b/c/d/e objectclass: top objectclass: device objectclass: bootableDevice cn: myhost |
% ldaplist -l ethers myhost
ethers dn: cn=myhost,ou=Ethers,dc=mydc,dc=mycom,dc=com macaddress: 8:1:21:71:31:c1 objectclass: top objectclass: device objectclass: ieee802Device cn: myhost |
% ldaplist -l publickey myhost
publickey dn: cn=myhost+ipHostNumber=200.20.20.99,ou=Hosts,dc=mydc,dc=mycom,dc=com cn: myhost iphostnumber: 200.20.20.99 description: Joe Smith nispublickey: 9cc01614d929848849add28d090acdaa1c78270aeec969c9 nissecretkey: 9999999998769c999c39e7a6ed4e7afd687d4b99908b4de99 objectclass: top objectclass: NisKeyObject objectclass: device objectclass: ipHost |
% ldaplist -l aliases myname
aliases dn: mail=myname,ou=aliases,dc=mydc,dc=mycom,dc=com cn: myname mail: myname objectclass: top objectclass: mailgroup mgrprfc822mailmember: my.name |
与 NIS 或 NIS+ 客户机不同,LDAP 客户机总是 返回主机名的全限定域名 (fully qualified domain name, FQDN)。LDAP FQDN 与 DNS 返回的 FQDN 相似。例如,假设域名为以下形式:
west.example.net |
查找主机名 server 时,gethostbyname() 和 getnameinfo() 都将返回 FQDN 版本。
server.west.example.net |
此外,如果使用特定于接口的别名(例如 server-#),则将返回一个较长的全限定主机名列表。 如果要使用主机名共享文件系统或者进行类似的其他检查,则必须对这些检查进行说明。例如,如果将非 FQDN 用于本地主机,FQDN 仅用于由 DNS 解析的远程主机,则必须说明二者之间的区别。如果使用与 DNS 不同的域名设置 LDAP,则同一个主机可能会以两个不同的 FQDN 结尾,具体情况取决于查找源。
缺省情况下,Solaris LDAP 客户机在访问信息时假设 DIT 具有给定的结构。对于 LDAP 服务器支持的每个域,都存在一个具有假定结构的子树。不过,通过指定服务搜索描述符 (Service Search Descriptor, SSD) 可以覆盖缺省结构。对于给定域,缺省 DIT 将具有一个用于存放许多已知容器的基本容器,这些已知容器用于存储特定信息类型的项。有关这些子树的名称,请参见下表。(此信息可在 RFC 2307 和其他参考资料中找到。)
表 9–1 DIT 缺省位置
缺省容器 |
信息类型 |
---|---|
ou=Ethers |
bootparams(4)、ethers(4) |
ou=Group |
group(4) |
ou=Hosts |
hosts(4)、ipnodes(4) 和主机的 publickey |
ou=Aliases |
aliases(4) |
ou=Netgroup |
netgroup(4) |
ou=Networks |
networks(4)、netmasks(4) |
ou=People |
passwd(1)、shadow(4)、user_attr(4)、audit_user(4) 和用户的 publickey |
ou=printers |
printers(4) |
ou=Protocols |
protocols(4) |
ou=Rpc |
rpc(4) |
ou=Services |
services(4) |
ou=SolarisAuthAttr |
auth_attr(4) |
ou=SolarisProfAttr |
prof_attr(4)、exec_attr(4) |
ou=projects |
project |
automountMap=auto_* |
auto_* |
架构是用于描述可作为项存储在 LDAP 目录中的信息类型的定义。要支持 LDAP 名称客户机,可能需要扩展目录服务器的架构。第 14 章,LDAP 一般参考(参考)中提供了有关 IETF 和 Solaris 特定架构的详细消息。还可以从 IETF Web 站点 http://www.ietf.org 访问各种 RFC。
使用架构映射时一定要谨慎,而且必须采用一致的方式。应确保所映射属性的语法与其映射到的属性的语法一致。换而言之,应确保单值属性映射到单值属性,属性的语法保持一致,并且映射对象类应该具有正确的强制性属性(可能是映射属性)。
如上所述,缺省情况下,LDAP 名称服务要求以特定方式构造 DIT。如果需要,可以指示 Solaris LDAP 名称服务在 DIT 的非缺省位置中进行搜索。另外,还可以指定用不同的属性和对象类来代替缺省架构所指定的属性和对象类。有关缺省过滤器的列表,请参见LDAP 名称服务使用的缺省过滤器。
serviceSearchDescriptor 属性 定义 LDAP 名称服务客户机搜索特定服务信息的方式和位置。serviceSearchDescriptor 包含一个服务名称,其后跟一个或多个用分号分隔的基 (base)-范围 (scope) -过滤器 (filter) 三元参数。 使用这些基 (base)-范围 (scope) -过滤器 (filter) 三元参数,可以定义仅搜索特定服务并按顺序进行搜索。 如果针对给定服务指定了多个基 (base)-范围 (scope) -过滤器 (filter),则该服务查找特定项时,将使用指定的范围和过滤器在每个基本容器中进行搜索。
使用 SSD 时,不会在缺省位置中搜索服务(数据库),除非该 SSD 中包括缺省位置。 如果针对某个服务指定了多个 SSD,将会产生不可预测的行为。
在以下示例中,Solaris LDAP 名称服务客户机会依次在 ou=west,dc=example,dc=com 和 ou=east,dc=example,dc=com 中执行一级搜索,以查找 passwd 服务。要查找用户 username 的 passwd 数据,可以针对每个 BaseDN 使用缺省的 LDAP 过滤器 (&(objectClass=posixAccount)(uid=username))。
serviceSearchDescriptor: passwd:ou=west,dc=example,dc=com;ou=east, dc=example,dc=com |
在以下示例中,Solaris LDAP 名称服务客户机将在 ou=west,dc=example,dc=com 中执行子树搜索以查找 passwd 服务。要查找用户 username 的 passwd 数据,可以使用 LDAP 过滤器 (&(fulltimeEmployee=TRUE)(uid=username)) 搜索 ou=west,dc=example,dc=com 子树。
serviceSearchDescriptor: passwd:ou=west,dc=example, dc=com?sub?fulltimeEmployee=TRUE |
还可以将多个容器与一个特定的服务类型关联。在以下示例中,服务搜索描述符指定在三个容器中搜索口令项。
请注意,在下面的示例中,SSD 中的结尾 ',' 表示 defaultSearchBase 将附加在相对基本容器之后。
defaultSearchBase: dc=example,dc=com serviceSearchDescriptor: \ passwd:ou=myuser,;ou=newuser,;ou=extuser,dc=example,dc=com |
使用 Solaris LDAP 名称服务时, 可以重新映射其任何服务的一个或多个属性名。(Solaris LDAP 客户机使用第 14 章,LDAP 一般参考(参考)中列出的已知属性。) 如果映射一个属性,则必须确保该属性与初始属性具有相同的含义和语法。请注意,映射 userPassword 属性可能会产生问题。
希望映射现有目录服务器中的属性
如果用户名只存在大小写差异,则必须将忽略大小写的 uid 属性映射到不忽略大小写的属性。
此属性的格式为 service:attribute-name=mapped-attribute-name。
如果要针对给定服务映射多个属性,则可以定义多个 attributeMap 属性。
在以下示例中,将 uid 和 homeDirectory 属性用于 passwd 服务时便会使用 employeeName 和 home 属性。
attributeMap: passwd:uid=employeeName attributeMap: passwd:homeDirectory=home |
但也会出现以下特殊情况:将 passwd 服务的 gecos 属性映射到多个属性。下面是一个示例:
attributemap: gecos=cn sn title |
以上示例将 gecos 值映射到用空格分隔的 cn、sn 和 title 属性值的列表。
使用 Solaris LDAP 名称服务时, 可以重新映射其任何服务的对象类。如果要针对给定服务映射多个对象类,则可以定义多个 objectclassMap 属性。在以下示例中,使用 posixAccount 对象类时便会使用 myUnixAccount 对象类。
objectclassMap: passwd:posixAccount=myUnixAccount |
为了简化 Solaris 客户机设置,并避免针对每台客户机都重新输入同样的信息,可以在目录服务器上创建一个客户机配置文件。这样,通过一个配置文件便可以为所有配置为使用该配置文件的客户机定义配置。以后对配置文件属性进行的任何更改都会按刷新间隔所定义的频率传播到客户机。
这些客户机配置文件应存储在 LDAP 服务器上的已知位置中。给定域的根 DN 必须具有对象类 nisDomainObject 以及包含客户机所在域的 nisDomain 属性。 所有的配置文件都位于相对于此容器的 ou=profile 容器中。这些配置文件应可以匿名读取。
下表列出了 Solaris LDAP 客户机的配置文件属性,这些属性可以在运行 idsconfig 时自动设置。有关如何手动设置客户机配置文件的信息,请参见手动初始化客户机以及 idsconfig (1M) 手册页。
表 9–2 客户机的配置文件属性
属性 |
说明 |
---|---|
cn |
配置文件的名称。该属性没有缺省值。必须指定该属性值。 |
preferredServerList |
首选服务器的主机地址是用空格分隔的服务器地址的列表。(请勿使用主机名。) 将先尝试与该列表中的服务器建立连接,然后再尝试与 defaultServerList 中的服务器建立连接,直到成功建立连接。该属性没有缺省值。在 preferredServerList 或 defaultServerList 中至少必须指定一台服务器。 |
defaultServerList |
缺省服务器的主机地址是用空格分隔的服务器地址的列表。(请勿使用主机名。)在尝试与 preferredServerlist 中的服务器建立连接之后,会先尝试与客户机所在子网中的缺省服务器建立连接,然后再尝试与其余的缺省服务器建立连接,直到成功建立连接。在 preferredServerList 或 defaultServerList 中至少必须指定一台服务器。只有在尝试与首选服务器列表中的服务器建立连接之后,才会尝试与该列表中的服务器建立连接。该属性没有缺省值。 |
defaultSearchBase |
相对于要在其中查找已知容器的位置的 DN。该属性没有缺省值。不过,对于给定服务,可以使用 serviceSearchDescriptor 属性覆盖该属性。 |
defaultSearchScope |
定义客户机要搜索的数据库范围。可以使用 serviceSearchDescriptor 属性覆盖该属性。可能的值为 one 或 sub。缺省搜索级别为 one。 |
authenticationMethod |
标识客户机使用的验证方法。缺省值为 none(匿名)。有关更多信息,请参见选择验证方法。 |
credentialLevel |
标识客户机应该用于验证的凭证类型。选项包括 anonymous 和 proxy。缺省值为 anonymous。 |
serviceSearchDescriptor |
定义客户机搜索名称数据库的方式和位置,例如,客户机应在 DIT 中的一个点还是多个点执行查找。缺省情况下,不定义任何 SSD。 |
serviceAuthenticationMethod |
客户机针对指定服务使用的验证方法。缺省情况下,不定义任何服务验证方法。如果某个服务未定义 serviceAuthenticationMethod,则使用 authenticationMethod 的缺省值。 |
attributeMap |
客户机使用的属性映射。缺省情况下,不定义任何 attributeMap。 |
objectclassMap |
客户机使用的对象类映射。缺省情况下,不定义任何 objectclassMap。 |
searchTimeLimit |
客户机上的搜索操作在超时之前可以执行的最长时间(以秒为单位)。这并不影响在 LDAP 服务器上完成搜索所需的时间。缺省值为 30 秒。 |
bindTimeLimit |
客户机与服务器的绑定在超时之前可以持续的最长时间(以秒为单位)。缺省值为 30 秒。 |
followReferrals |
指定客户机是否应遵循 LDAP 引用。可能的值为 TRUE 或 FALSE。缺省值为 TRUE。 |
profileTTL |
ldap_cachemgr (1M) 从 LDAP 服务器刷新客户机配置文件的时间间隔。缺省值为 43200 秒(即 12 小时)。如果指定的值为 0,则不刷新配置文件。 |
下表列出了可以使用 ldapclient 在本地设置的客户机属性。有关更多信息,请参见 ldapclient(1M) 手册页。
表 9–3 本地客户机属性
属性 |
说明 |
---|---|
domainName |
指定客户机的域名(该域将成为此客户机的缺省域)。该属性没有缺省值。必须指定该属性值。 |
proxyDN |
代理的标识名。如果使用代理的 credentialLevel 配置客户机,则必须指定 proxyDN。 |
proxyPassword |
代理的口令。如果使用代理的 credentialLevel 配置客户机,则必须定义 proxyPassword。 |
certificatePath |
包含证书数据库的本地文件系统中的目录。如果借助 TLS 使用 authenticationMethod 或 serviceAuthenticationMethod 配置客户机,则将使用此属性。缺省值为 /var/ldap。 |
如果 SSD 中的 BaseDN 包含一个结尾逗号,则将其视为 defaultSearchBase 的相对值。执行搜索之前,会将 defaultSearchBase 的值附加在 BaseDN 后面。
ldap_cachemgr 是运行于 LDAP 客户机上的守护进程。启动 LDAP 客户机时,系统会调用 ldap_cachemgr 守护进程。该守护进程执行以下主要功能:
刷新存储在服务器上配置文件中的客户机配置信息并从客户机提取这些数据
维护要使用的活动 LDAP 服务器的排序列表
通过缓存由不同客户机提交的一些常见查找请求来提高查找效率
提高主机的查找效率
ldap_cachemgr 必须一直运行,LDAP 名称服务才能正常工作。
有关详细信息,请参阅 ldap_cachemgr(1M) 手册页。
Solaris LDAP 名称服务将 LDAP 系统信息库用作名称服务和验证服务的源。本节讨论客户机标识、验证方法、 pam_ldap(5) 和 pam_unix 模块和帐户管理的概念。
启用 pam_ldap 帐户管理后,所有用户在每次登录系统时都必须提供口令。进行验证时必须提供登录口令。因此,使用 rsh、rlogin 或 ssh等工具进行的不基于口令的登录将会失败。
要访问 LDAP 系统信息库中的信息,客户机首先向目录服务器证明自己的身份。此身份可以是匿名的,也可以是 LDAP 服务器能够识别的对象。基于客户机的身份和服务器的访问控制信息 (access control information, ACI),LDAP 服务器将允许客户机读写目录信息。有关 ACI 的更多信息,请查阅所用 Sun Java System Directory Server 版本的管理指南。
如果客户机对于任何给定的请求以非匿名方式进行连接,则客户机必须使用客户机和服务器均支持的验证方法来向服务器证明自己的身份。客户机在证明自己的身份之后即可发出各种 LDAP 请求。
名称服务和验证服务 (pam_ldap) 访问目录的方式有所不同。名称服务基于预定义的身份从目录中读取各项及其属性,验证服务通过使用用户的名称和口令进行登录到 LDAP 服务器的验证,确认用户输入的口令是否正确。 有关验证服务的更多信息,请参见 pam_ldap(5) 手册页。
为了将 TLS 用于 Solaris LDAP 名称服务,目录服务器必须针对 LDAP 和 SSL 分别使用缺省端口 389 和 636。如果目录服务器未使用这些端口,则 TLS 此时便不可用。
TLS 可用于 保护 LDAP 客户机和目录服务器之间的通信安全,提供保密性和数据完整性。TLS 协议是 安全套接字层 (Secure Sockets Layer, SSL) 协议的一个超集。Solaris LDAP 名称服务支持 TLS 连接。请注意,使用 SSL 会增加目录服务器和客户机的负荷。
需要针对 SSL 设置目录服务器。有关针对 SSL 设置 Sun Java System Directory Server 的更多信息,请参阅所用 Sun Java System Directory Server 版本的管理指南。还需要针对 SSL 设置 LDAP 客户机。
如果使用 TLS,则必须安装必要的安全数据库,特别是需要安装证书和密钥数据库文件。例如,如果采用 Netscape Communicator 的旧数据库格式,则需要以下两个文件:cert7.db 和 key3.db。或者,如果使用 Mozilla 提供的新数据库格式,则需要三个文件:cert8.db、key3.db 和 secmod.db。cert7.db 或 cert8.db 文件包含受信任证书。key3.db 文件包含客户机的密钥。即使 LDAP 名称服务客户机不使用客户机密钥,此文件也必须存在。secmod.db 文件包含安全模块,如 PKCS#11 模块。如果使用的是旧格式,则不需要此文件。
有关更多信息,请参见设置 TLS 安全性。
LDAP 名称服务 客户机根据客户机的凭证级别进行登录到 LDAP 服务器的验证。可以为 LDAP 客户机指定三个可能的凭证级别,LDAP 客户机将使用这些凭证级别进行登录到目录服务器的验证。
Anonymous
如果使用 anonymous 进行访问,则只能访问所有人都能使用的数据。此外,还应考虑安全问题。允许 anonymous 访问目录的某些部分意味着任何具有该目录访问权限的人都具有读取访问权限。如果使用 anonymous 凭证级别,则需要允许对所有的 LDAP 名称项和属性都具有读取访问权限。
绝对不要对目录进行 anonymous 写入,因为任何人都可以在具有写入访问权限的 DIT 中更改信息,包括其他用户的口令或他们自己的标识。
Sun Java System Directory Server 允许基于 IP 地址、DNS 名称、验证方法和时间来限制访问。您可能希望进一步限制访问。有关更多信息,请参阅所用 Sun Java System Directory Server 版本的管理指南中的“管理访问控制”。
Proxy
客户机 使用代理帐户进行登录到目录的验证或绑定到目录。此代理帐户可以是任何允许绑定到目录的项。此代理帐户需要有足够的权限以便在 LDAP 服务器上执行名称服务功能。 需要使用 proxy 凭证级别在每台客户机上配置 proxyDN 和 proxyPassword。经过加密的 proxyPassword 存储在客户机本地。可以为不同组的客户机设置不同的代理。例如,可以为所有的销售客户机配置一个代理,使其可以访问公司范围内可访问的目录和销售目录,同时禁止销售客户机访问包含薪水信息的人力资源目录。或者,在极端情况下,可以为每台客户机指定不同的代理或者为所有客户机仅指定一个代理。典型的 LDAP 部署一般介于这两种极端情况之间。请认真做出选择。代理太少,可能不便于您控制用户对资源的访问。但是,代理太多,又会增加系统设置和维护难度。 您需要根据自己的环境授予代理用户适当的权限。 有关如何确定哪种验证方法最适合您的配置的信息,请参见凭证存储。
如果某个代理用户的口令发生变化,则需要在使用此代理用户的每台客户机上更新该口令。如果针对 LDAP 帐户使用口令失效功能,请确保针对代理用户关闭此功能。
请注意,代理凭证级别应用于任何给定计算机上所有的用户和进程。如果两个用户需要使用不同的命名策略,则他们必须使用不同的计算机。
另外,如果客户机要使用 proxy 凭证进行验证,则 proxyDN 在所有服务器上都必须具有相同的 proxyPassword。
proxy anonymous
proxy anonymous 是一个多值项,其中定义了多个凭证级别。指定了 proxy anonymous 级别的客户机将首先尝试使用其代理标识进行验证。如果客户机由于某种原因(例如,用户锁定、口令过期)而无法作为代理用户进行验证,客户机将使用匿名访问机制。这可能会导致不同级别的服务,具体情况取决于目录的配置方式。
如果将客户机配置为使用 代理标识,则客户机会将其 proxyDN 和 proxyPassword 保存在 /var/ldap/ldap_client_cred 中。为了增强安全性,将仅限超级用户可以访问该文件,并且对 proxyPassword 值进行了加密。尽管以前的 LDAP 实现已将代理凭证存储在客户机的配置文件中,但是 Solaris 9 LDAP 名称服务却未这样做。初始化过程中使用 ldapclient 设置的任何代理凭证都存储在本地。这会提高代理的 DN 和口令信息的安全性。有关设置客户机配置文件的更多信息,请参见第 12 章,设置 LDAP 客户机(任务)。
为客户机指定 proxy 或 proxy-anonymous 凭证级别时,还需要选择代理进行登录到目录服务器的验证的方法。缺省情况下,验证方法是 none,它指示进行匿名访问。对于该验证方法,还存在与之关联的传输安全选项。
与凭证级别一样,验证方法也可以为多值。例如,在客户机配置文件中,可以指定客户机首先尝试使用由 TLS 保护的 simple 方法进行绑定。如果绑定失败,则客户机将尝试使用 sasl/digest-MD5 方法进行绑定。因此,authenticationMethod 可以为 tls:simple;sasl/digest-MD5。
LDAP 名称服务支持某些简单身份验证和安全层 (Simple Authentication and Security Layer, SASL) 机制。这些机制无需 TLS 便可安全交换口令。但是,这些机制不提供数据完整性和保密性。有关 SASL 的信息,请参见 RFC 2222。
以下是受支持的验证机制:
none
客户机不进行登录到目录的验证。这与 anonymous 凭证级别等效。
如果客户机使用 simple 验证方法,则通过以明文形式发送用户的口令绑定到服务器。因此,除非会话受 ipsec(7) 保护,否则口令很容易被窥探。 使用 simple 验证方法的主要好处在于所有目录服务器都支持该验证方法且其易于设置。
在验证期间会保护客户机的口令,但不会对会话进行加密。某些目录服务器(包括 Sun Java System Directory Server)还支持 sasl/digest-MD5 验证方法。digest-MD5 的主要好处在于,在验证过程中,口令不会以明文形式通过线路传输,因此它比 simple 验证方法更安全。有关 digest-MD5 的信息,请参见 RFC 2831。digest-MD5 以 cram-MD5 为基础,在安全方面有所改进。
使用 sasl/digest-MD5 时,验证过程比较安全,但不会保护会话。
如果使用的是 Sun Java System Directory Server,则口令必须以明文形式存储在目录中。
sasl/cram-MD5
使用 sasl/cram-MD5 执行验证时,不会对 LDAP 会话进行加密,但是在验证期间会保护客户机的口令。
有关 cram-MD5 验证方法的信息,请参见 RFC 2195。只有部分目录服务器支持 cram-MD5。例如,Sun Java System Directory Server 就不支持 cram-MD5。
tls:simple
客户机使用 simple 方法进行绑定,并且对会话进行加密。口令也受到保护。
tls:sasl/cram-MD5
对 LDAP 会话进行加密,客户机使用 sasl/cram-MD5 进行登录到目录服务器的验证。
tls:sasl/digest-MD5
对 LDAP 会话进行加密,客户机使用 sasl/digest-MD5 进行登录到目录服务器的验证。
为了使用 digest-MD5,Sun Java System Directory Server 要求以明文形式存储口令。如果将验证方法设置为 sasl/digest-MD5 或 tls:sasl/digest-MD5,则代理用户的口令必须以明文形式存储。应特别小心的是,如果 userPassword 属性以明文形式存储,它将具有正确的 ACI,以便使其不可读。
下表概述了各种验证方法及其各自的特征。
表 9–4 验证方法
|
绑定 |
线路上的口令 |
Sun Java System Directory Server 上的口令 |
会话 |
---|---|---|---|---|
none |
否 |
N/A |
N/A |
不加密 |
simple |
是 |
明文 |
任何 |
不加密 |
sasl/digest-MD5 |
是 |
加密 |
明文 |
不加密 |
sasl/cram-MD5 |
是 |
加密 |
N/A |
不加密 |
tls:simple |
是 |
加密 |
任何 |
加密 |
tls:sasl/cram-MD5 |
是 |
加密 |
N/A |
加密 |
tls:sasl/digest-MD5 |
是 |
加密 |
明文 |
加密 |
可以在 serviceAuthenticationMethod 属性中为给定的服务指定验证方法。目前,以下服务支持此操作:
passwd-cmd
passwd(1) 使用此服务更改登录口令和口令属性。
keyserv
chkey(1) 和 newkey (1M) 实用程序使用此服务创建和更改用户的 Diffie-Hellman 密钥对。
pam_ldap
pam_ldap(5) 使用此服务验证用户。
pam_ldap 支持帐户管理。
如果未针对服务设置 serviceAuthenticationMethod,则缺省情况下将使用 authenticationMethod 属性的值。
下面示例列出了客户机配置文件的一部分,在这部分客户机配置文件中,用户将使用 sasl/digest-MD5 进行登录到目录服务器的验证,使用 SSL 会话更改其口令。
serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5 serviceAuthenticationMethod=passwd-cmd:tls:simple |
使用 PAM 框架,可以在多种验证服务中进行选择。可以将 pam_unix 或 pam_ldap 与 LDAP 结合使用。
建议使用 pam_ldap,因为它的灵活性更强,支持更强大的验证方法并且能够使用帐户管理功能。
如果未对 pam.conf(4) 文件进行过更改,则缺省情况下,pam_unix 功能处于启用状态。
Solaris 已经删除了 pam_unix 模块而且将不再支持它。但是,通过一组其他服务模块提供了等效或更强的功能。因此,在本指南中,pam_unix 是指等效的功能,而不是指 pam_unix 模块本身。
pam_unix 遵循传统的 UNIX 验证模型,如下所述。
客户机从名称服务检索用户的加密口令。
系统提示用户输入其口令。
对用户的口令进行加密。
客户机比较这两个经过加密的口令,确定用户是否通过了验证。
口令必须以 UNIX crypt 格式存储,而不应采用任何其他加密方法(包括明文)存储。
名称服务必须能够读取 userPassword 属性。
例如,如果将凭证级别设置为 anonymous,则任何人都必须能够读取 userPassword 属性。同样,如果将凭证级别设置为 proxy,则代理用户必须能够读取 userPassword 属性。
pam_unix 与 sasl 验证方法 digest-MD5 不兼容,因为 Sun Java System Directory Server 要求以明文形式存储口令,以便使用 digest-MD5。而 pam_unix 要求以 crypt 格式存储口令。
实现 pam_ldap 时,用户使用在 pam_ldap 的 serviceAuthenticationMethod 参数(如果存在的话)中定义的验证方法绑定到 LDAP 服务器。否则,将使用 authenticationMethod。
如果 pam_ldap 能够使用用户的标识和提供的口令绑定到服务器,它将对用户进行验证。
启用 pam_ldap 帐户管理之后,所有用户在每次登录系统时都必须提供口令。进行验证时必须提供登录口令。因此,使用 rsh、rlogin 或 ssh 等工具进行的不基于口令的登录将会失败。
pam_ldap 不读取 userPassword 属性。因此,除非其他客户机正在使用 pam_unix,否则无需授予对 userPassword 属性的读取访问权限。此外,pam_ldap 不支持 none 验证方法。因此,您必须定义 serviceAuthenticationMethod 或 authenticationMethod 属性,以便客户机可以使用 pam_ldap。有关更多信息,请参见 pam_ldap(5) 手册页。
如果使用 simple 验证方法,则 userPassword 属性在传输过程中可被第三方读取。
下表概述了 pam_unix 和 pam_ldap 之间的主要区别。
表 9–5 pam_unix 与 pam_ldap
|
pam_unix |
pam_ldap |
---|---|---|
口令的发送方式 |
使用 passwd 服务验证方法 |
使用 passwd 服务验证方法 |
新口令的发送方式 |
加密 |
不加密(除非使用 TLS) |
新口令的存储方式 |
crypt 格式 |
Sun Java System Directory Server 中定义的口令存储方案 |
是否需要读取口令? |
是 |
否 |
更改口令之后,是否与 sasl/digest-MD5 兼容 |
否。口令不以 clear 形式存储。用户无法进行验证。 |
是。只要将缺省的存储方案设置为 clear,用户就可以进行验证。 |
可以使用 passwd(1) 更改口令。要更改口令,用户必须对 userPassword 属性具有写入权限。请记住,对于此操作,passwd-cmd 的 serviceAuthenticationMethod 会覆盖 authenticationMethod。在传输过程中可能未对当前的口令进行加密,具体取决于所使用的验证方法。
对于 pam_unix,新的 userPassword 属性在写入 LDAP 之前会使用 UNIX crypt 格式进行加密和标记。因此,无论使用哪种验证方法绑定到服务器,在传输过程中都会对新口令进行加密。有关更多信息,请参见 pam_authtok_store(5) 手册页。
从 Solaris 10 软件发行版开始,pam_ldap 不再支持口令更新。以前建议使用的带有 server_policy 选项的 pam_authtok_store 现已取代pam_ldap 口令更新功能。使用 pam_authtok_store 时,新口令将以明文形式发送到 LDAP 服务器。因此,为了确保保密性,请使用 TLS。如果不使用 TLS,新的 userPassword 很容易被窥探。 如果使用 Sun Java System Directory Server 设置未标记的口令,则该软件会使用 passwordStorageScheme 属性对口令进行加密。有关 passwordStorageScheme 的更多信息,请参见所用 Sun Java System Directory Server 版本的管理指南中有关用户帐户管理的章节。
设置 passwordStorageScheme 属性时,需要考虑以下配置问题。如果 NIS、NIS+ 或另一台使用 pam_unix 的客户机将 LDAP 用作系统信息库,则 passwordStorageScheme 必须为 crypt。此外,如果在 Sun Java System Directory Server 上结合使用 pam_ldap 和 sasl/digest-MD5,则必须将 passwordStorageScheme 设置为 clear。
LDAP 名称服务可以利用 Sun Java System Directory Server 中的口令和帐户锁定策略支持。可以将 pam_ldap(5) 配置为支持用户帐户管理。将 passwd(1) 和正确的 PAM 配置结合使用时,将遵循 Sun Java System Directory Server 口令策略所设置的口令语法规则。
通过 pam_ldap(5) 可以支持以下帐户管理功能。这些功能取决于 Sun Java System Directory Server 的口令和帐户锁定策略配置。可以根据需要启用任意功能。
口令失效和到期通知
用户必须按照计划更改其口令。如果在所配置的时间内未更改口令,口令将过期。过期的口令会导致用户验证失败。
用户在到期警告期间内登录时,会看到一条警告消息。该消息指出口令在多少小时或多少天之后到期。
口令语法检查
新口令必须符合口令长度的最低要求。此外,口令不能与用户目录项中 uid、cn、sn 或 mail 属性的值相匹配。
历史记录中口令的检查
用户不能重复使用口令。如果用户尝试将口令更改为以前所使用过的口令,passwd(1) 将失败。LDAP 管理员可以配置保留在服务器历史记录列表中的口令数目。
用户帐户锁定
连续验证失败达到指定次数后,会锁定用户帐户。在管理员已取消激活用户帐户的情况下,也会锁定用户帐户。除非帐户锁定时间已过或者管理员重新激活被锁定的帐户,否则验证将一直失败。
前面介绍的帐户管理功能仅适用于 Sun Java System Directory Server。 有关在服务器上配置口令和帐户锁定策略的信息,请参见所用 Sun Java System Directory Server 版本的管理指南中的“用户帐户管理”一章。 另请参见为帐户管理配置的 pam_ldap 的示例 pam_conf 文件。请勿针对 proxy 帐户启用帐户管理。
在 Sun Java System Directory Server 上配置口令和帐户锁定策略之前,请确保所有主机都使用具有 pam_ldap 帐户管理功能的“最新”LDAP 客户机。
另外,还应确保客户机上具有已正确配置的 pam.conf(4) 文件。否则,当 proxy 或用户口令到期后,LDAP 名称服务将无法工作。
启用 pam_ldap 帐户管理之后,所有用户在每次登录系统时都必须提供口令。进行验证时必须提供登录口令。因此,使用 rsh、rlogin 或 ssh 等工具进行的不基于口令的登录将会失败。