为 TM1 9.5 配置 LDAP 身份验证 -4

look_w

定义映射
在 TM1 数据库中，每个用户都有几个属性。每个 TM1 用户都有惟一的用户名，他至少属于一个组，还可能有电子邮件地址。为了实现 LDAP 身份验证，必须用从 LDAP 读取的数据填充这些用户属性。下面的对话框用于把 LDAP 用户的属性映射到这些属性。
单击 Edit -> Mapping 以定义映射。
图 8. ETLDAP TM1 Mapping 对话框首先，这里有用户提供给 TM1 进行身份验证的 TM1 用户名（“client”）。它必须是惟一的，而且是区分大小写的。使用 client 字段在 }Clients.dim 和 }ClientProperties.dim 中创建用户。从下拉列表中选择包含所需信息的属性，这里指定的属性决定用户在登录时必须输入什么。列出的属性取决于 LDAP 服务器类型（LDAP 支持的模式）和 BC 权限。对于 Active Directory，常见的映射是 “uid”、“cn” 或 sAMAccountName 属性，但是如果用户使用电子邮件进行身份验证，映射 “email” 属性也可以。
注意：如果在下拉列表中没有出现任何属性，请参考 “排除故障” 小节中的解决方法或用第三方 LDAP 浏览器工具检查 BC 的 LDAP 权限。BC 必须能够查看用户的所有属性。
下一个属性是 “group”。这个属性表示用户所属的组的名称，使用它的值在 }Groups.dim 中创建条目。选择一个对用户进行分组的 LDAP 属性，比如部门 ID、建筑或位置 ID /名称。
最后，可以指定映射到 TM1 用户的电子邮件属性的 LDAP 模式属性。大多数 LDAP 服务器模式支持包含用户电子邮件地址的属性。在这里映射这个属性，就会填充在 TM1 中创建的用户的电子邮件属性。
图 9. 定义的 ETLDAP TM1 映射完成之后，单击 OK。
现在，“Export” 按钮应该启用了，可以开始导出到 TM1。在导出期间，ETLDAP 从 LDAP 读取数据并在 TM1 中创建用户和组。导出之后，单击 View -> Log 以检查日志，了解已经创建了哪些用户和组，哪些创建失败了。
但是，在导出之后，必须手工地把用户分配给组。详细信息参见 TM1 9.5 Operations Guide "Running the ETLDAP tool"。这很重要，因为导入的用户很可能都不属于 ADMIN 组，详细信息参见 3.3.7 小节。
编辑 TM1s.cfg
在 TM1 中创建用户之后，现在终于可以把 TM1 服务器的身份验证模式改为 LDAP 了。为此，必须在 TM1s.cfg 中把 Passwordsource 属性改为 LDAP。接下来，还必须提供 LDAP 服务器的连接信息。
但是，还要注意许多其他问题。正如 2.2.1 节中解释的，TM1 服务器将连接 LDAP 服务器以检查用户凭证。因为 LDAP 服务器运行 SSL，所以连接它的过程由两个步骤组成。
首先，必须建立网络连接，这意味着网络层连接（假设已经提供了）和更重要的 SSL 握手。这个握手过程要检查 LDAP 服务器的证书并确认对它的信任。
第二步是绑定到 LDAP 服务器，即执行身份验证并建立用于接收数据的会话。
可以通过 TM1s.cfg 文件中的设置配置这两个步骤，因此管理员可以根据具体情况调整这些步骤的处理。
一般情况下，必须调整 tm1s.cfg 中的三个部分。
调整 tm1s.cfg 文件之后，不要忘了保存它。
一般性设置
为了给 TM1 启用 LDAP 身份验证，把 PasswordSource 属性改为 “LDAP”。
PasswordSource=LDAP
接下来，在以下属性中提供基本的 LDAP 连接信息：

1 2 3 4

LDAPHost=<host> LDAPPort=<port> LDAPSearchBase=<baseDN> LDAPSearchField=<mapped client attribute>

指定主机和端口，默认的 LDAP 端口是 636，但可以是任何端口，这取决于 LDAP 服务器使用的端口。SearchBase 应该是在运行 ETLDAP 工具时使用的 DN（2.2.1 节中提供的 BaseDN）。LDAPSearchField 必须是在 2.2.3 节中为客户机映射指定的 LDAP 模式属性。
检查 SSL 证书
TM1 使用 Microsoft Windows API 实现密码学功能。这包括检查 SSL 证书。在默认情况下，TM1 会打开连接配置的主机和端口的安全套接字，希望另一端的服务器提供它的证书以启动 SSL 握手。然后，把证书传递给 Windows API 进行检查。这意味着 Windows 操作系统必须能够检查对这个证书的信任关系。为了实现这个目标，Windows 必须信任签署 LDAP 服务器证书的 CA 证书或 LDAP 服务器证书本身（对于自签署证书），也就是说它们必须是 “可信根 CA”。确认信任关系之后，Windows API 请求可信根 CA 的 Certificate Revocation List (CRL) 证书（如果可应用的话），从而确认证书还没有撤消。在此之后，它才会向调用者发出已经成功地检查了提供的证书的信号。
可以修改这种最方便的 SSL 握手处理过程以解决某些难题。TM1 期望收到的证书的主题与配置的端点的服务器名匹配。如果不匹配，检查会失败，因为 TM1 请求 Windows API 根据配置的服务器名检查收到的证书。如果配置的主机和端口实际上并不代表 LDAP 服务器，而是代理等其他系统，检查会失败。由于这个原因，可以把对 SSL 证书的检查委托给 TM1。这通过在 tm1s.cfg 中添加 LDAPVerifyServerSSLCert=T 来实现。这让 TM1 自己处理这个检查。
如果 TM1 自己处理证书检查，它会像 Windows API 一样分两步执行检查（信任和 CRL 检查），但是采用略有不同的方式。
它并不根据配置的主机名检查收到的证书并检查信任关系，而是先查看一个服务器名列表。这个列表是一个白名单，这意味着它显式地列出应该被接受的所有服务器名。条目必须与在 SSL 握手时另一端的服务器提供给 TM1 的证书的主题精确地匹配。对于每个服务器，必须有一个 LDAPVerifyCertServerName=<server_cert_subject> 这样的条目。只有在找到匹配的情况下，TM1 才会继续处理。如果证书主题与白名单中的服务器之一匹配，TM1 就调用 Windows API，显式地要求只检查这个证书。这要求 Windows 信任此证书，意味着必须导入正确的可信根 CA。
如果由于任何原因不想检查信任，可以通过指定 LDAPSkipSSLCertVerification=F 跳过信任检查步骤。这个设置让 TM1 根本不检查服务器证书，而是直接接受它。
确认信任（或跳过检查步骤）之后，TM1 希望检查 CRL 证书。这也通过调用 Windows API 来完成，所以必须已经把可信根的 CRL 证书导入了 Windows。如果在 Windows 的信任存储中没有这个证书，那么必须通过指定 LDAPSkipSSLCRLVerification=T 跳过 CRL 处理，否则 TM1 会坚持检查 CRL。如果指定 LDAPVerifyServerSSLCert=F（由 Windows 处理所有检查），就不需要这么做了，因为 API 能够容忍空的或不存在的 CRL 证书。
如果上面的所有检查都成功了，SSL 握手就会完成，TM1 现在可以向 LDAP 服务器验证身份。
向 LDAP 服务器验证身份
向 LDAP 服务器验证身份可以采用两种方式。
如果 LDAP 服务器是 Microsoft Active Directory，那么 TM1 可以使用 Windows 集成的身份验证向 LDAP（在这里是 AD）验证身份。从理论上说，这种方法也适用于其他 LDAP 服务器，但是需要为 LDAP 服务器配置相关的模块。如果不确定目标 LDAP 服务器是否支持 Windows 集成的身份验证，请询问您的 LDAP 管理员。目前，我们假设这种方法只应用于 Microsoft AD。
如果应该使用 Windows 集成的身份验证，那么必须在 tm1s.cfg 中添加 LDAPUseServerAccount=T 条目。这让 TM1 对于运行 TM1 服务器的账号 使用 Windows 集成的身份验证向 LDAP 验证身份。也就是说，运行 TM1 服务器的账号将向 Active Directory 验证身份，因此这个账号必须在 AD 中有足够的特权。
另外，一种最佳实践是指定主机的域名而不是实际的主机名。这样就可以使用 Windows Domain Locator 进程把请求路由到 “最适合” 处理它的域控制器。可以根据可用性（故障转移）、地理位置接近程度或负载执行路由，Windows 域管理员可以配置路由规则。如果用 IP 或 DNS 引用特定的域控制器，请求就只由这个主机处理。