获取演示
登录

转换到不同的 Cognos 安全源

by 2015 年 6 月 30 日Cognos 分析, 人格智商0评论

当您需要重新配置现有 Cognos 环境以使用不同的外部安全源（例如 Active Directory、LDAP 等）时，您可以采用多种方法。 我喜欢称他们为“好的、坏的和丑的”。 在我们探索这些好的、坏的和丑陋的方法之前，让我们先看看一些常见的场景，这些场景往往会导致 Cognos 环境中的身份验证名称空间发生变化。

常见的业务驱动因素:

更新硬件或操作系统 – BI 硬件/基础设施的现代化可能是一个常见的驱动因素。 虽然 Cognos 的其余部分可能会在您时尚的新硬件和现代 64 位操作系统上像冠军一样运行，但祝您将 2005 年左右版本的 Access Manager 迁移到该新平台上好运。 Access Manager（首次随系列 7 发布）是许多 Cognos 客户过去的宝贵遗产。 这是许多客户保留 Windows Server 2003 的旧版本的唯一原因。Access Manager 的文章已经被搁置了很长时间。 它是遗留软件。 越早摆脱它越好。

应用标准化– 希望将所有应用程序的身份验证整合到一个集中管理的公司目录服务器（例如 LDAP、AD）的组织。

合并与收购– 公司 A 购买了公司 B 并需要公司 B 的 Cognos 环境指向公司 A 的目录服务器，而不会对他们现有的 BI 内容或配置造成问题。

企业剥离– 这与合并方案相反，公司的一部分被分拆为自己的实体，现在需要将其现有的 BI 环境指向新的安全源。

为什么命名空间迁移会很混乱

将 Cognos 环境指向新的安全源并不像添加具有相同用户、组和角色的新命名空间、断开旧命名空间的连接那么简单，瞧！-新命名空间中的所有 Cognos 用户都与他们的内容。 事实上，你的手上经常会弄得一团糟，这就是为什么......

所有 Cognos 安全主体（用户、组、角色）都由称为 CAMID 的唯一标识符引用。 即使所有其他属性都相同，一个用户的 CAMID 现有 身份验证命名空间将与该用户的 CAMID 不同 新 命名空间。 这可能会对现有的 Cognos 环境造成严重破坏。 即使您只有几个 Cognos 用户，您也需要意识到 CAMID 引用存在于内容存储中的许多不同位置（甚至可以存在于内容存储之外的框架模型、转换器模型、TM1 应用程序、多维数据集、规划应用程序等中） ）。

许多 Cognos 客户错误地认为 CAMID 仅对我的文件夹内容、用户首选项等重要。这与事实大相径庭。 这不仅仅是您拥有的用户数量的问题，而是您需要关注的 Cognos 对象的数量。 仅 Content Store 中就有 140 多种不同类型的 Cognos 对象，其中许多可能有多个 CAMID 引用.

例如：

  1. Content Store 中的单个计划具有多个 CAMID 引用（计划所有者的 CAMID、计划运行的用户的 CAMID、每个用户的 CAMID 或分发列表应该通过电子邮件将生成的报告输出发送到， 等等。）。
  2. Cognos 中的每个对象都有一个安全策略来管理哪些用户可以访问该对象（想想“权限选项卡”）。 挂在 Cognos Connection 中该文件夹的单个安全策略具有该策略中指定的每个用户、组和角色的 CAMID 参考。
  3. 希望你明白这一点——这个列表还在继续！

一个相当大的 Content Store 包含数以万计的 CAMID 引用（我们已经看到一些包含数十万的大型引用）的情况并不少见。

现在，计算一下里面有什么 选择您 Cognos 环境，您可以看到您可能正在处理成群的 CAMID 引用。 这可能是一场噩梦！ 切换（或重新配置）您的身份验证命名空间会使所有这些 CAMID 引用处于无法解析的状态。 这不可避免地导致 Cognos 内容和配置问题（例如不再运行的计划、不再像您认为的那样保护内容、不再正确实现数据级别安全性的包或多维数据集、丢失我的文件夹内容和用户偏好等）。

Cognos 命名空间转换方法

现在，知道 Cognos 环境可能有数以万计的 CAMID 引用，这些引用需要在新的身份验证名称空间中查找、映射和更新到相应的新 CAMID 值，让我们讨论解决这个问题的好、坏和丑方法。

善: 用 Persona 替换命名空间

第一种方法（命名空间替换）利用 Motio“S， 人格智商 产品。 采用这种方法，您现有的命名空间将被一个特殊的 Persona 命名空间“替换”，该命名空间允许您虚拟化向 Cognos 公开的所有安全主体。 预先存在的安全主体将使用与以前完全相同的 CAMID 向 Cognos 公开，即使它们可能由任意数量的外部安全源（例如 Active Directory、LDAP 甚至 Persona 数据库）提供支持。

这种方法的美妙之处在于它需要对 Cognos 内容进行零更改。 这是因为 Persona 可以维护预先存在的委托人的 CAMID，即使它们有新来源的支持。 那么……您的内容存储、外部模型和历史立方体中的所有这些数以万计的 CAMID 引用？ 他们可以保持原样。 无需工作。

这是迄今为止风险最低、影响最小的方法，可用于将现有 Cognos 环境从一个外部安全源转换到另一个。 它可以在一小时内完成，Cognos 停机时间大约为 5 分钟（Cognos 唯一停机时间是在您配置 Persona 名称空间后重新启动 Cognos）。

坏: 使用 Persona 进行命名空间迁移

如果简单、低风险的方法不适合您，那么 is 另外一个选项。

Persona 还可用于执行命名空间迁移。

这涉及在您的 Cognos 环境中安装第二个身份验证名称空间，将（希望）所有现有安全主体（从旧名称空间）映射到新名称空间中的相应主体，然后（这是有趣的部分），查找、映射和更新每个Cognos 环境中存在的单个 CAMID 引用：您的内容存储、框架模型、转换器模型、历史多维数据集、TM1 应用程序、规划应用程序等。

这种方法往往压力重重且流程密集，但如果您是那种需要肾上腺素飙升才能感觉还活着的 Cognos 管理员（并且不介意深夜/清晨的电话），那么也许…… Free Introduction 是您正在寻找的选项吗？

Persona 可用于帮助自动化此过程的某些部分。 它将帮助您创建旧安全主体和新安全主体之间的映射，自动执行内容存储中内容的蛮力“查找、分析、更新”逻辑等。什么 Persona 可以自动执行这里的一些任务，很多这种方法的工作涉及“人员和过程”而不是实际技术。

例如，编译每个 Framework Manager 模型、每个 Transformer 模型、每个 Planning / TM1 应用程序、每个 SDK 应用程序的信息、谁拥有它们，以及规划它们将如何更新和重新分发可能需要大量工作。 协调您希望尝试迁移的每个 Cognos 环境的中断以及您可以尝试迁移的维护时段可能涉及规划和 Cognos“停机时间”。 在迁移之后提出（并执行）一个有效的测试计划也可能是一个负担。

您希望首先在非生产环境中执行此过程也很正常 before 在生产中尝试它。

虽然使用 Persona 进行命名空间迁移确实有效（并且它比下面的“丑陋”方法要好得多），但与命名空间替换相比，它更具侵入性、风险更大、涉及更多的人员并且需要更多的工时来执行。 通常迁移需要在“下班时间”完成，而 Cognos 环境仍然在线，但最终用户对表单的使用受到限制。

丑: 手动命名空间迁移服务

丑陋的方法涉及一种不令人羡慕的方法，试图 手动 从一个身份验证名称空间迁移到另一个身份验证名称空间。 这涉及将第二个身份验证名称空间连接到您的 Cognos 环境，然后尝试手动移动或重新创建大部分现有 Cognos 内容和配置。

例如，使用这种方法，Cognos 管理员可能会尝试：

  1. 在新命名空间中重新创建组和角色
  2. 在新命名空间中重新创建这些组和角色的成员资格
  3. 手动将我的文件夹内容、用户首选项、门户选项卡等从每个源帐户复制到每个目标帐户
  4. 查找内容存储中的每个策略集，并将其更新为引用新命名空间中的等效主体，其方式与引用旧命名空间中的主体完全相同
  5. 重新创建所有计划并使用相应的凭据、收件人等填充它们。
  6. 重置 Content Store 中所有对象的所有“所有者”和“联系人”属性
  7. [Content Store 中大约有 40 件您会忘记的东西]
  8. 收集所有具有对象或数据级别安全性的 FM 模型：
    1. 相应地更新每个模型
    2. 重新发布每个模型
    3. 将修改后的模型重新分发给原作者
  9. 针对原始命名空间保护的 Transformer 模型、TM1 应用程序和规划应用程序的类似工作
  10. [还有很多]

虽然一些 Cognos 受虐狂可能会为在 Cognos Connection 中点击 400,000 次的想法暗自窃喜，但对于大多数明智的人来说，这种方法往往极其乏味、耗时且容易出错。 然而，这并不是这种方法的最大问题。

这种方法的最大问题是它几乎 时刻 导致迁移不完全。

使用这种方法，您（痛苦地）查找并尝试映射您知道的那些 CAMID 引用……但往往会留下您所知道的所有 CAMID 引用 不知道.

一旦你 认为 你已经完成了这种方法，你通常没有 真 完成。

您的内容存储库中的对象不再像您认为的那样受到保护……您的计划没有按照过去的方式运行，您的数据不再像您想象的那样受到保护确实如此，而且您甚至可能会在某些操作中遇到无法解释的错误 你真的不能把你的手指放在上面.

糟糕和丑陋的方法可能可怕的原因：

  • 自动命名空间迁移给内容管理器带来了很大压力。 对 Content Store 中每个对象的检查和潜在更新，通常会导致对 Cognos 的数以万计的 SDK 调用（几乎所有这些调用都通过内容管理器）。 这种异常查询通常会导致内存使用量/负载激增，并使内容管理器在迁移过程中面临崩溃的风险。 如果您的 Cognos 环境中已经存在任何不稳定性，您应该非常害怕这种方法。
  • 命名空间迁移需要相当大的维护窗口。 Cognos 需要启动，但您不希望人们在迁移过程中进行更改。 这通常需要在没有其他人工作时开始命名空间迁移，假设在周五晚上 10 点。 没有人愿意在周五晚上 10 点开始一项压力大的项目。 更不用说，在一个项目中，你的智力可能不在最佳的工作之夜和周末 不 要求你敏锐！
  • 我已经提到命名空间迁移是时间和劳动密集型的。 这里有更多的内容：
    • 内容映射过程应该精确完成，这需要团队协作和大量工时。
    • 需要多次试运行来检查迁移的错误或问题。 典型的迁移在第一次尝试时并不完美。 您还需要一个有效的 Content Store 备份，以便在这种情况下可以恢复。 我们已经看到许多组织没有可用的良好备份（或者他们没有意识到备份是不完整的）。
    • 你需要确定一切 学校以外 可能受到影响的内容存储（框架模型、转换器模型等）。 此任务可能涉及多个团队之间的协调（尤其是在大型共享 BI 环境中）。
    • 您需要一个好的测试计划，其中涉及对您的 Cognos 内容具有不同程度访问权限的代表性人员。 此处的关键是在迁移完成后不久验证一切是否已完全迁移并按预期运行。 验证所有内容通常是不切实际的，因此您最终会验证您希望的具有代表性的样本。
  • 你必须有 broad Cognos 环境和依赖它的事物的知识。 例如，如果您采用 NSM 路线，则必须重建具有自定义视图的历史立方体。
  • 如果您或您将命名空间迁移外包的公司忘记了某些东西，例如……SDK 应用程序，该怎么办？ 一旦你打开了开关，如果它们没有正确更新，这些东西就会停止工作。 您是否进行了适当的检查以立即注意到这一点，还是在症状开始出现之前几周/几个月？
  • 如果您经历了多次 Cognos 升级，则您的 Content Store 中可能会有处于不一致状态的对象。 如果您不使用 SDK，您将无法看到哪些对象处于此状态。

为什么命名空间替换是最佳选择

使用 Persona Namespace Replacement 方法时，我刚刚概述的关键风险因素和耗时步骤将被消除。 使用命名空间替换方法，您有 5 分钟的 Cognos 停机时间，并且您的任何内容都不必更改。 “好”的方法对我来说似乎是一种干脆的“不费脑子”。 周五晚上是为了放松，而不是因为您的内容管理器刚刚在命名空间迁移过程中崩溃而感到压力。

了解更多