电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 为 TM1 9.5 配置 LDAP 身份验证 -1 [打印本页]

作者: look_w 时间: 2018-2-21 14:27 标题: 为 TM1 9.5 配置 LDAP 身份验证 -1

简介目的本文档意在补充 TM1 9.5 Operations Guide，更详细地描述为 TM1 9.5 配置 LDAP 身份验证的任务。它讨论文档中缺少的内容，介绍还没有文档记载的配置项，帮助解决文档中根本没有提到的问题。
适用性本文档中描述的配置只适用于 Microsoft Windows 的所有版本和 TM1 9.5。尽管这些概念可能适用于更早的 TM1 版本，但是作者没有测试过。
到目前为止，已经确认以下 LDAP 服务器可以与 TM1 9.5 结合使用：OpenLDAP、Sun ONE LDAP、Novell eDirectory、Tivoli Directory Services 和 Microsoft Active Directory。尽管对于支持的 LDAP 服务器没有官方声明，但是可以假设支持所有符合 LDAP v3 的 LDAP 服务器。
例外与除外责任TM1 9.5 当前在除 Microsoft Windows 之外的任何其他平台上都不支持 LDAP 身份验证。尤其是，这在 UNIX 上不可能实现，因为在这些平台上 TM1 9.5 中没有 LDAP 客户机 API。
本文档涉及 Public Key Infrastructures (PKI) 的概念，比如证书、Certifying Authority、密钥存储和信任存储。读者应该熟悉这些概念，本文档不解释它们。
背景知识TM1 中的 LDAP 身份验证当把 TM1 配置为使用 LDAP 身份验证时，它会根据配置的 LDAP 服务器检查用户凭证。但是，IBM Cognos TM1 不支持单独的 LDAP 配置。正如 Operations Guide 的第 7 章中指出的，TM1 总是要在 TM1 数据库中执行查找（这是内部安全措施）。从技术上说，步骤如下：

TM1 用户通过任何客户机登录并提供凭证。
TM1 把凭证提供给配置的 LDAP 服务器进行检验。
如果 LDAP 服务器接受了凭证，TM1 就检查提供的用户名在 }Clients.dim 中是否有匹配的条目。如果有，用户就会登录 TM1。

由此可见，必须先把 LDAP 中的用户和组导入 TM1 数据库中，然后才能够使用 LDAP 身份验证。这由 ETLDAP 工具处理。
ETLDAP 工具在 }Clients.dim 中创建用户名条目并在 }ClientProperties.dim 中创建条目。
在 TM1 中由 SSL 保护的通信IBM Cognos TM1 在两方面使用 Secure Socket Layer (SSL) 加密的连接。
首先，在 TM1 服务器与 Architect、Perspectives 和 web 客户机等客户机之间有内部通信。自 9.1 版以来，TM1 支持用 SSL 对这些连接进行加密，这是最佳实践。（参见 TM1 Operations Guide 的第 1 章）。
第二，对于 LDAP 身份验证，在 TM1 服务器与 LDAP 服务器之间有通信。LDAP 协议也可以用 SSL 加密，这称为 Lightweight Directory Access Protocol over SSL (LDAPS)。从 9.1 版开始，TM1 要求使用 LDAPS，不支持使用不加密的 LDAP。与 LDAP 的通信总是只由 TM1 服务器处理，客户机不直接连接 LDAP。
图 1. TM1 9.5 中的 SSL 通信

在默认情况下，内部的 SSL 通信基于由 TM1 创建的密钥和由 TM1 内置的 Certifying Authority (CA) 签署的证书。它们在默认情况下存储在 <TM1 ROOT>/bin/ssl 文件夹中。这意味着所有 TM1 组件都信任用于内部 SSL 的服务器证书。对于这种信任，客户机必须信任签署服务器证书的 CA。对于内部 SSL，这当然是 “Applix CA”（TM1 内置 CA 的名称）。因为 TM1 使用 Windows 操作系统的密码学功能检查 SSL 信任，这意味着要作为可信的根把 <Applix CA> 证书导入 Windows LocalComputer 信任存储中。这由安装程序自动地完成，所以在安装之后系统已经为内部 SSL 配置好了。
但是，对于生产环境，建议把默认的证书替换为由商业 CA 签署的证书。这需要向 TM1 提供服务器证书、私有密钥、签署它们的 CA 证书和 CA 的 Certificate Revocation List (CRL) 证书。由于 TM1 使用 Windows API 实现密码学功能，在 Windows 信任存储中还没有新的 CA 证书，必须手工导入它们（参见 TM1 9.5 Operations Guide 的第 12 章 “Running TM1 in Secure Mode Using SSL” 中的 “Using Independent Certificates” 段落）。如果使用 Thawte 或 Verisign 等商业 CA 的 CA 证书，Windows 很可能已经信任这些 CA，因为 Windows 的信任存储中包含一些预先安装的 CA 证书。可以使用 Microsoft Management Console (MMC) 的 Certificates 插件查看 <Trusted Root Certification Authorities> 节点以检查证书，如下所示：
图 2. Windows 信任存储和可信的 CA 证书

这个屏幕图显示在默认的 Windows 2003 Server 中所有可信的根 CA 证书，还有目前已经添加的两个证书（CS Germany CA 和 Applix）。
注意：在 <TM1_ROOT>/bin/ssl 文件夹中有一个没有文档记载的工具 importsslcert.exe，它会自动地把证书导入 Windows 信任存储。TM1 在内部使用它，但是可以使用它导入任何证书，可以避免使用 MMC 插件的麻烦。
只有在把证书导入 Windows 信任存储之后，TM1 服务器才能够使用服务器证书建立 SSL 套接字。
对于外部 SSL，适用相同的概念。为了让 TM1 服务器信任在建立 SSL 连接时由 LDAP 服务器提供的服务器证书，必须把签署 LDAP 服务器证书的 CA 的证书导入 Windows 信任存储。
如果 LDAP 服务器使用自签署的证书（在这种证书中主题和颁发者是相同的，没有设置 “is CA” 属性），那么此证书同时作为服务器证书和 CA 证书，所以必须把服务器证书导入 Windows 信任存储。要记住，对于生产服务器，使用自签署的证书是不好的做法，应该使用由 CA 签署的证书。
因为 LDAP 服务器是外部的第三方软件，SSL 支持的配置不属于 TM1 的范围。TM1 管理员必须从 LDAP 管理员那里获取某些信息。
用于把最初的用户导入 TM1 中的 ETLDAP 实用程序是用 Java 编写的，因此可以使用其他信任存储和 API 建立 SSL 连接。通过 LDAPS 连接 ETLDAP 需要几个额外步骤。Operations Guide 描述了这些步骤，但是文档中有一个小错误（参见下一节）。为了理解整个机制，一定要认识到 ETLDAP 使用 “外部 SSL” 连接。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)