IBM Cognos 最佳实践: 为 TM1 9.5 配置 LDAP 身份验证

文档性质:可靠实践;产品:TM1 9.5;关注领域:安全性;版本:1.1

本文档意在补充 TM1 9.5 Operations Guide,更详细地描述为 TM1 9.5 配置 LDAP 身份验证的任务。

Cognos Proven Practices Team, Cognos 最佳实践团队, IBM

Cognos 最佳实践团队。



2011 年 6 月 02 日

免费下载:IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

目的

本文档意在补充 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 通信
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 信任存储和可信的 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” 连接。


配置步骤

尽管 TM1 9.5 Operations Guide 讨论了配置 LDAP 身份验证的最基本概念和任务,但是没有提到一些重要或有意思的配置选项。如果没有正确地实现,必需的其他一些步骤可能会造成问题。

本节详细说明为 TM1 9.5 配置 LDAP 身份验证的步骤。已经对不同的 LDAP 服务器测试过这个配置过程。它是可靠实践。

检查 LDAP 服务器信息

在安装 TM1 9.5 之前,第一步是确认掌握了所有必需的 LDAP 服务器信息,确认能够通过 LDAPS 连接 LDAP 服务器。

  1. 必需的第一个信息是 LDAP 服务器的类型。这可以是符合 LDAP v3 的任何 LDAP 服务器,比如 Tivoli Directory Service (TDS)、OpenLDAP、SunONE LDAP 甚至包括 Microsoft Active Directory (AD)。大体上说,AD 实际上是 Windows 内置的 LDAP,Microsoft 对它做了很多扩展,所以可以使用它为 TM1 9.5 提供 LDAP 身份验证。LDAP 的类型决定 TM1 登录名可以使用的用户条目属性,对于 Active Directory,它还决定 TM1 服务器如何向 LDAP 服务器验证身份。对于 AD,有一个特殊的单点登录特性,稍后讨论此特性。
  2. 第二,需要 LDAP 的连接信息。这包括:
    • 主机 IP、Netbios 名称或完全限定的 DNS 名称。
      提示:对于 AD,也可以使用域名,这是最佳实践,因为这允许使用 Windows DC Locator 特性(AD 故障转移支持)。
    • 端口。LDAPS 在默认情况下使用端口 636。
    • Base Distinguished Name (BaseDN),比如 o=Business Analytics,dc=ibm.com。
  3. 第三个、也是最重要的信息是,LDAP 服务器是使用自签署的证书,还是某个 CA 签署的证书。
    对于自签署证书,需要服务器证书。
    对于 CA 签署的证书,需要签署服务器证书的 CA 的 CA 证书。
    获取采用 Privacy Enhanced Mail (PEM) 格式(Base64 编码的 ASCII)的这些证书。
  4. 必需的最后一个信息是 Binding Credentials (BC),它实际上是一个 LDAP 账号,可以用它绑定和搜索目录。这个 BC 至少需要对应该导入 TM1 的所有用户条目有浏览和读访问权。
    对于 Active Directory,BC 可以是某个域用户账号,记住这个账号。

获取所有这些信息之后,最好确认任意 LDAP 客户机可以通过 SSL 连接 LDAP 服务器。使用您选择的 LDAP 浏览器,使用收集的主机、端口、BaseDN 和 BC 连接 LDAP。如果连接成功,就继续配置;如果不成功,就尝试解决连接问题。如果 LDAP 客户机无法连接 LDAP,TM1 也无法连接。

一种不错的测试方法是使用 Microsoft 的 Windows Server Tool 包(Win2008 服务器在默认情况下包含这个包)中的 “LDP” 实用程序。提供 SSL 支持的其他 LDAP 客户机包括 Apache Directory Studio(开放源码)和 Softerra LDAP 浏览器(商业)。

甚至可以使用 “s_client -connect host:port -ca < cert>” 命令通过 OpenSSL 工具包执行测试。

安装 TM1 9.5,选择 LDAP 身份验证

如果还没有安装 TM1 9.5,就运行安装向导。确保选中 LDAP Authentication 复选框。

图 3. TM1 安装向导 — 选中 LDAP Authentication 选项
TM1 安装向导 — 选中 LDAP Authentication 选项

提供在前一步中收集的 LDAP 相关信息。LDAP search field 的实际值取决于 LDAP 的类型。如果不确定,以后可以修改它。这会在服务器的 tm1s.cfg 文件中创建所需的条目。

如果已经安装了 TM1,那么在 tm1s.cfg 中已经有一些用于当前配置的身份验证模式的设置。在这种情况下,必须手工添加用于 LDAP 的设置。请记住,根据当前的身份验证模式,ETLDAP 可能需要额外的配置设置才能够连接 TM1 服务器。

运行 ETLDAP 工具

正如 2.1 节中提到的,要想让 TM1 使用 LDAP 身份验证,必需的步骤之一是通过运行 ETLDAP 实用程序在 TM1 数据库中创建用户和组。ETLDAP 连接 LDAP 和 TM1,把从 LDAP 提取出的数据写到 TM1 数据库中。它是用 Java 编写的,因此使用 Java API 处理密码学功能。ETLDAP 并不像 TM1 服务器那样使用 Windows 信任存储,而是使用 Java 信任存储。因此,建立 ETLDAP 对 LDAP 服务器证书的信任需要一个额外步骤。

另外,完成成功的导入需要几个设置。

正如 Operations Guide 的第 10 章 “Configuring LDAP validation” 中指出的,在开始使用 ETLDAP 之前,要确认在服务器的 tm1s.cfg 文件中密码源属性设置为 TM1 (PasswordSource=TM1)。还不能切换到 LDAP,因为还没有把用户导入 TM1,而 ETLDAP 必须能够连接 TM1 才能够导入用户和组。

让 ETLDAP 信任 LDAP 服务器的证书

通过名为 Java Runtime Environment (JRE) 的 Microsoft Windows 命令文件调用 ETLDAP,并显式地传递信任存储(包含应该信任的证书的文件)的名称和位置。在默认情况下,引用的信任存储是用于内部 SSL 的信任存储,所以传递给 JRE 的两个参数应该像下面这样:

-Djavax.net.ssl.trustStore="%APPLIXPath%bin\ssl\tm1store"
-Djavax.net.ssl.trustStorePassword=applix

信任存储是 <TM1_ROOT>/bin/ssl/tm1store,它的密码是 “applix”。

尽管可以在 <TM1_ROOT>/bin/etldap.cmd 中修改这两个参数以使用另一个信任存储,但是最简单的方法是把建立 ETLDAP 信任需要的证书添加到用于内部 SSL 的信任存储中。这对于内部 SSL 没有不利影响,也不会造成安全问题,因此下面介绍这种方法。如果非要让 ETLDAP 使用另一个信任存储,那么要调整这个批处理文件,而且不要忘了在这个信任存储中添加 Applix CA 证书,没有这个证书,ETLDAP 就无法连接 TM1。

为了建立信任,必须把签署 LDAP 服务器证书的 CA 证书或服务器证书本身(对于自签署证书)导入 tm1store 中。导入方法是在 <TM1_ROOT>\axajre\jre\bin 文件夹中执行以下命令(在 Operations Guide 中有一个错误的路径,已经报告了这个问题,以后会得到纠正):

keytool -import -keystore <TM1_ROOT>\bin\ssl\tm1store" -storepass applix 
-alias LDAPTrust -file <your_cert>

这个工具会显示证书并询问是否应该导入它。按 “y” 并按回车。这样就添加了证书,ETLDAP 会信任用导入的证书签署的所有证书。

因此,现在已经为 ETLDAP 工具建立了对 LDAP 服务器证书的信任。

连接 LDAP

通过启动 <TM1_ROOT>\bin\etldap.cmd 运行 ETLDAP 工具。

图 4. ETLDAP 工具
ETLDAP 工具

工具打开之后,单击 Edit -> Login -> LDAP

在出现的对话框中,提供 3.1 节中收集的 LDAP 连接信息和 BC。

单击 Test

如果成功地建立了连接,即 SSL 握手完成了,会显示绿色的消息。按 OK 完成登录。

图 5. LDAP 登录对话框 — 选中 SSL 选项
LDAP 登录对话框 — 选中 SSL 选项

如果无法建立连接,请参考 “排除故障” 小节。基本上,要确认:

  • 证书是正确的。
  • 已经把正确的证书导入了在命令文件中提供给 ETLDAP 的信任存储。
  • Binding Credential 是有效的,使用其他 LDAP 客户机软件测试它们。
  • LDAP 服务器正在运行。

连接 TM1

确保启动 Administration Server 和 TM1 服务器。在默认情况下,安装程序会为它们创建两个 Windows 服务。运行这些服务的账号并不重要。

接下来,通过单击 Edit -> Login -> TM1 连接 TM1。

输入运行 Admin Server 的计算机的主机名,单击 “Server” 旁边的按钮。一个显示所有活跃 TM1 服务器的对话框出现。通过双击选择希望连接的 TM1 服务器。

最后,提供用户名和密码,如果这是新的服务器,提供 “admin” 和 “apple”。

单击 Test。如果连接成功,单击 OK 完成登录。

图 6. TM1 登录对话框
TM1 登录对话框

如果无法建立连接,那么确认:

  • TM1 服务器和 Administration Server 正在运行。
  • 已经针对正确的身份验证模式配置了 tm1s.cfg。目前,模式必须不是 LDAP。

注意:如果使用其他身份验证模式,要确保所有设置都已经就位,ETLDAP 才能够连接 TM1 服务器。

搜索 LDAP

现在已经连接到 LDAP 和 TM1,可以开始从 LDAP 导入用户。

单击 File -> Connect。这把 ETLDAP 连接到 LDAP。

“Search” 按钮现在启用了。

下一步是执行 LDAP 搜索,这会返回要导入 TM1 的条目集。这个搜索由以下部分组成:

  • “SearchDN”,这是开始搜索的位置的 DN。
  • 筛选器,它定义要寻找的条目。
  • 用逗号分隔的属性名列表,它定义要在结果集中显示条目的哪些属性。(在默认情况下,显示条目的 DN。)
  • 搜索范围,它定义是否搜索 SearchDN 的子条目。

关于搜索 LDAP 服务器的更多信息,请联系您的 LDAP 管理员和/或查阅 Operations Guide。

按 “Search” 运行定义的搜索。

图 7. LDAP Load Tool 对话框
LDAP Load Tool 对话框

此工具在列表视图中显示结果集(如果有的话),每个列代表一个属性。通过右键单击一个条目,可以显示它的所有属性。

这是可能要导入的数据的预览,但这只是非正式地检查搜索属性。为了定义把搜索找到的条目的哪些属性导入 TM1,要使用另一个对话框。

定义映射

在 TM1 数据库中,每个用户都有几个属性。每个 TM1 用户都有惟一的用户名,他至少属于一个组,还可能有电子邮件地址。为了实现 LDAP 身份验证,必须用从 LDAP 读取的数据填充这些用户属性。下面的对话框用于把 LDAP 用户的属性映射到这些属性。

单击 Edit -> Mapping 以定义映射。

图 8. ETLDAP TM1 Mapping 对话框
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 映射
定义的 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 连接信息:

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 引用特定的域控制器,请求就只由这个主机处理。

通常,clientID 的映射应该是 sAMAccountName,这是用户的 Windows 登录名。

用于连接 AD 的 tm1s.cfg 示例

PasswordSource=LDAP
LDAPPort=636
LDAPHost=some.domain.com
LDAPSearchBase=dc=some,dc=domain,dc=com
LDAPSearchField=sAMAccountName
LDAPUseServerAccount=T

# Should TM1 verifiy the cert (=T)or Windows (=F)?
LDAPVerifyServerSSLCert=F
  # only if LDAPVerifyServerSSLCert=T
  # verify based on a  whitelist (=F)or simply default to true (=T)
  LDAPSkipSSLCertVerification=F
  # whitelist of accepted servers
  LDAPVerifyCertServerName=wcsfrkxp99.mydomain.com
  # skip CRL processing (=T) or process (=F)
  LDAPSkipSSLCRLVerification=T

对于不支持 Windows 集成的身份验证的 LDAP 服务器,tm1s.cfg 必须指定 LDAPUseServerAccount=F 并显式地提供 TM1 服务器要使用的 Binding Credential。但是,这些要在几个属性中指定。首先是执行绑定的用户的绝对 DN,TM1 称其为 “Well Known User Name”。这要在 LDAPWellKnownUserName 中指定。并不在此文件中以明文指定这个用户的密码,而是必须使用 tm1crypt 把密码存储在一个加密的文件中。

像下面这样运行 tm1crypt 实用程序:

<TM1_ROOT>/bin/tm1crypt -pwd <password> 
                        -keyfile <key_output_file>
                        -outfile <encrypted_output_file>
                        [-validate]

对于 password,指定 WellKnownUser 的密码,也就是 BC 的密码。对于 key_output_file,选择一个文件名,它应该表明这是加密文件的密钥,比如 “ldappasskey.dat”。对于 encrypted_output_file,选择一个文件名,它应该表明这是加密的密码文件,比如 “ldappass.dat”。

在 tm1s.cfg 中,在 LDAPPasswordKeyFile 中指定密钥文件(包含用于密码解密的密钥),在 LDAPPasswordFile 中指定加密的密码文件。

用于连接 OpenLDAP 的 tm1s.cfg 示例

PasswordSource=LDAP

LDAPHost=wcsfrkxp99.mydomain.com
LDAPPort=636
LDAPSearchBase=ou=people,dc=cognos,dc=com
LDAPSearchField=uid

LDAPUseServerAccount=F
LDAPWellKnownUserName=cn=binduser,dc=cognos,dc=com
LDAPPasswordFile=e:\cognos\tm1\9.5\bin\ssl\ldappass.dat
LDAPPasswordKeyFile=e:\cognos\tm1\9.5\bin\ssl\ldappasskey.dat

# Should TM1 verifiy the cert (=T)or Windows (=F)?
LDAPVerifyServerSSLCert=F
  # only if LDAPVerifyServerSSLCert=T
  # verify based on a  whitelist (=F)or simply default to true (=T)
  LDAPSkipSSLCertVerification=F
  # whitelist of accepted servers
  LDAPVerifyCertServerName=wcsfrkxp99.mydomain.com
  # skip CRL processing (=T) or process (=F)
  LDAPSkipSSLCRLVerification=T

在 ADMIN 组中添加用户

现在,一切就绪了,可以重新启动 TM1 服务器并激活 LDAP 身份验证。但是,在这么做时,没有可用的管理员账号。这是因为 ETLDAP 只根据 LDAP 数据创建用户和组,并没有把任何用户分配给组。另外,把身份验证模式改为 LDAP 之后,无法再访问原来分配给 ADMIN 组的用户。因此,在切换到 LDAP 身份验证之前,需要把至少一个用户提升为管理员。

  • 打开 Architect
  • 双击要切换到 LDAP 身份验证的 TM1 服务器
  • 作为管理员登录(用户名和密码是 admin 和 apple)。
  • 右键单击服务器名并选择 Security -> Clients/Groups。
图 10. 选择 Security -> Clients/groups
选择 Security -> Clients/groups
  • 找到从 LDAP 导入的新用户之一,通过选中 ADMIN group 的框让他成为管理员。这个账号现在是新的管理账号。
  • 关闭 Architect。

重新启动

为了最终为这个服务器激活 LDAP 身份验证,确保保存对 tm1s.cfg 的修改,重新启动 TM1 Admin Server 和 TM1 服务器。

把可信根 CA 证书导入 Windows 信任存储

完成设置的最后一步是把适当的证书导入 Windows 信任存储,让 Windows 信任 LDAP 服务器提供的服务器证书。

这可以采用两种方式:

  • 直接或通过 Internet Explorer 向导使用 Microsoft Management Console (MMC) 的 Microsoft Windows Certificate 插件
  • 使用 TM1 中的 importsslcert 工具

使用 importsslcert

有一个没有文档记载的工具 importsslcert,TM1 在为内部 SSL 设置证书时使用它。这个工具把证书和它的 CRL 证书放进 Windows 的信任存储中。这是目前最简便的方法,基本上不可能出现错误。

调用这个工具的方法是进入 <TM1_ROOT>/bin 并执行:

importsslcert -ca <certificate> [-crl <crl_certificate>]

对于 certificate,提供包含 CA 证书(如果使用自签署证书,是服务器证书)的文件的绝对路径。还可以可选地提供 CRL 证书。工具会显示成功或失败消息。

现在,完成了。

使用 Windows Certificate 插件

把证书作为可信根 CA 导入 Windows 很简单,但是有一处需要注意。当 Windows 询问要放置此证书的证书存储时,必须小心。逻辑存储和物理存储之间有细微的差异。Windows API 期望证书在本地主机上的物理存储中。如果由于某种原因它们没有放在那里,即使 Windows 把证书显示为可信根 CA,也无法建立信任。

使用 Internet Explorer 浏览器导入证书:

  • 打开浏览器。
  • 进入 Internet Options 的 Content 选项卡。
  • 找到 Certificates 部分并单击 Certificates。
  • 单击 “Import...”,Certificate Import Wizard 会出现。
  • 单击 Next。
  • 找到要导入的证书文件并单击 Next。
  • Certificate Store selection 对话框出现。确保选中 “Place all certificates in the following store” 选项。然后单击 Browse。
图 11. Certificate Import Wizard
Certificate Import Wizard
  • 在出现的对话框中,选中 “show physical stores”,进入 Third Party Root Certification Authorities -> Local Computer,单击选择它。单击 OK。
图 12. Select Certificate Store 对话框
Select Certificate Store 对话框
  • 返回到 Certificate Import Wizard,单击 Next。
  • 在最后的汇总信息页面上,单击 Finish。
  • 表示导入成功的消息框出现之后,在 “Trusted Root Certification Authorities” 上的列表中应该会出现这个证书。

导入任务完成了。

注意:可以使用 Microsoft MMC 的 Certificates 插件完成这个任务。在选择 Trusted Root Certification Authorities 之后,一定要单击 View-> Options 并指定 “physical certificate stores” 选项。

图 13. certmgr View Options
certmgr View Options

把证书导入 Trusted Root Certifying Authorities -> Local Computer -> Certificates 文件夹。

图 14. Trusted Root Certifying Authorities / Local Computer / Certificates
Trusted Root Certifying Authorities / Local Computer / Certificates

使用 LDAP 凭证登录 TM1

既然设置已经完成了,现在应该能够通过任何客户机使用 LDAP 凭证登录 TM1。要记住,TM1 管理员必须把用户分配给组(如果还没有完成这一步的话),因为 LDAP 导入步骤并没有建立组成员关系。


排除故障

本节尝试为在为 TM1 9.5 设置 LDAP 身份验证时最常出现的问题提供解决方法。

到目前为止,最常见的错误是错误码为 0x51 /81 的 “Connection Error”。这几乎总是意味着 SSL 握手问题。下面几项措施可能有助于解决这些问题。

为 LDAPAuth 添加调试日志记录器

如果把 TM1 配置为自己检查证书,可以在 tm1s-log.properties 文件中添加日志记录器。通过使用这个日志记录器,tm1.log 会包含关于证书检查失败或其他错误的额外信息。如果由 Windows 检查服务器证书 (LDAPVerifyServerSSLCert=F),日志记录只显示 LDAP ERROR: 0x51 - ldap_connect failed。在这种情况下,最好让 TM1 检查 SSL 证书(改为 LDAPVerifyServerSSLCert=T)并启用日志记录器以收集更多信息。

通过编辑 <TM1_SERVER_ROOT>/ tm1s-log.properties 启用日志记录器。

紧挨在 log4j.logger.TM1=INFO, S1 行后面添加下面一行:

log4j.logger.TM1=INFO, S1
log4j.logger.TM1.LDAPAuth=DEBUG

保存文件并停止 TM1 服务器。移走或删除旧的 tm1.log 并重新启动服务器。再次尝试执行身份验证,查看日志中新的错误消息。

检查证书

为了确认 LDAP 服务器提供的证书确实是有效的,可以尝试在 Windows 中查看它(为了让 Windows 能够识别它,需要把扩展名改为 *.cert),或者使用某些 PKI 工具查看它。也可以使用 OpenSSL。要检查的内容是:

  • 主题/CN 是 LDAP 服务器的 Netbios 主机名,还是完全限定的域名?
  • 这是自签署的证书吗?自签署证书的特征是,主题和颁发者字段包含相同的字符串,而且没有设置表示这是 CA 证书的证书属性。
    如果它是自签署证书,要确认这个证书已经导入到 Windows 中了。
  • 每个证书都有过期日期。确认这个证书没有过期。
  • 确认证书没有被撤消。如果可信根 CA 提供 CRL,要确认撤消的证书列表中不包含这个证书。
  • 是否可以使用其他 LDAP 客户机(比如 Microsoft LDP、OpenSSL、Softerra LDAP)连接 LDAP?

检查 tm1s.cfg 设置

排除故障的好方法之一是利用 tm1s.cfg 中的高级设置。通过修改配置让 TM1 处理证书检查,然后先跳过证书检查和 CRL 检查:

...
# Should TM1 verifiy the cert (=T)or Windows (=F)?
LDAPVerifyServerSSLCert=T
  # only if LDAPVerifyServerSSLCert=T
  # verify based on a  whitelist (=F)or simply default to true (=T)
  LDAPSkipSSLCertVerification=T
  # whitelist of accepted servers
  LDAPVerifyCertServerName=wcsfrkxp99.mydomain.com
  # skip CRL processing (=T) or process (=F)
  LDAPSkipSSLCRLVerification=T

如果这无效,说明问题不在于 SSL 握手,而是网络连接或者 BC 或 Service Account 的 LDAP 身份验证出了问题。对于使用 ServerAccount (LDAPUseServerAccount=T) 的情况,改为使用显式的 BC 并运行 tm1crypt 生成必需的文件。对于 AD,如果显式的 BC 有效,就说明不是 Windows 集成的身份验证的问题。

如果上面的配置有效,那么重新启用 SSLCertVerification 并启用 LDAPAuth 日志记录器(如果还没有启用的话)。查看 tm1.log 中的错误码。

在启用 LDAPAuth 日志记录器的情况下 tm1s.log 中最常见的错误码

  • LDAP ERROR: 0x800b0109
    下面的错误组合表明可接受的服务器名白名单有问题。
     LDAP ERROR: 0x800b0109 - Error verifying server certificate chain validity
     LDAP ERROR: Error verifying server certificate no match for <server>
     LDAP ERROR: 0x51 - ldap_connect failed.

    这基本上意味着提供的服务器证书的主题(错误中的 <server>)与白名单中的任何条目都不匹配。纠正措施是复制证书的主题字符串,把它粘贴到白名单中的 LDAPVerifyCertServerName=<subject> 条目中。
  • LDAP ERROR: 0x800b010f
    下面的错误组合表明 Windows 不信任这个证书。
     LDAP ERROR: 0x800b010f - Error verifying server certificate chain validity
     LDAP ERROR: Error verifying server certificate no match for <server>
     LDAP ERROR: 0x51 - ldap_connect failed.

    这表明 Windows 对 LDAP 服务器证书的信任有问题。建议的纠正措施是确保把证书正确地导入 Windows,参见 2.2.6 节。
  • LDAP ERROR: 0x80092012
    下面的错误组合表明 CRL 处理有问题。
     LDAP ERROR: 0x80092012 - Error verifying server certificate chain validity
     LDAP ERROR: Error verifying server certificate no match for <server>
     LDAP ERROR: 0x51 - ldap_connect failed.

    要么是这个证书被撤消了,要么是 TM1 寻找 CRL 证书但在 Windows 信任存储中无法找到它。建议的纠正措施是跳过 CRL 处理(设置 LDAPSkilSSLCRLVerification=T),即不从 CA 导入 CRL 证书。

在 ETLDAP 工具中没有显示任何属性

如果 ETLDAP 映射对话框中的下拉列表没有显示任何要映射的 LDAP 属性,这表明 BC 有权限问题。如果无法用具有足够特权的 BC 运行 ETLDAP,可以通过在配置文件中指定映射来解决此问题。当然,这要求知道要映射的属性名。

实现方法是,在连接 LDAP 并运行搜索之后,选择:

File -> save as

这可以把在 ETLDAP 工具中设置的配置保存到一个文件中。指定一个有意义的名称,比如 ETLDAP.conf。

打开保存的配置文件,添加以下设置(如果已经存在,就修改它们)。

mapval:tm1client || <client_mapping>
mapval:tm1group || <group_mapping>
mapval:rep.email || <email_mapping>

保存文件。

现在再次打开 ETLDAP,通过 File -> Open 装载配置文件。

参考资料

学习

获得产品和技术

讨论

  • 参与 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=677539
ArticleTitle=IBM Cognos 最佳实践: 为 TM1 9.5 配置 LDAP 身份验证
publish-date=06022011