Переход на другой источник безопасности Cognos

Когда вам нужно перенастроить существующую среду Cognos для использования другого внешнего источника безопасности (например, Active Directory, LDAP и т. Д.), Вы можете воспользоваться несколькими подходами. Мне нравится называть их «Хорошим, Плохим и Уродливым». Прежде чем мы исследуем эти хорошие, плохие и уродливые подходы, давайте рассмотрим некоторые распространенные сценарии, которые обычно приводят к изменениям пространства имен аутентификации в среде Cognos.

Общие бизнес-драйверы:

Обновление оборудования или ОС - Частой движущей силой может быть модернизация оборудования / инфраструктуры бизнес-аналитики. В то время как остальная часть Cognos может работать как чемпион на вашем новом гладком оборудовании и современной 64-битной ОС, удачи вам в переносе вашей версии Access Manager примерно 2005 года на эту новую платформу. Access Manager (впервые выпущенный в Series 7) - почтенный пережиток давно минувших дней для многих клиентов Cognos. Это единственная причина, по которой многие клиенты держат эту хреновую старую версию Windows Server 2003. Написание статьи о Access Manager уже довольно долгое время висит на стене. Это устаревшее программное обеспечение. Чем раньше вы сможете от него отказаться, тем лучше.

Стандартизация приложений- Организации, которые хотят объединить аутентификацию всех своих приложений на одном централизованно управляемом корпоративном сервере каталогов (например, LDAP, AD).

Слияния и поглощения- Компания A покупает компанию B, и ей требуется, чтобы среда Cognos компании B указывала на сервер каталогов компании A, не вызывая проблем с существующим контентом или конфигурацией BI.

Корпоративные продажи- Это противоположно сценарию слияния, часть компании выделяется в отдельную организацию, и теперь ей необходимо направить существующую среду бизнес-аналитики на новый источник безопасности.

Почему миграции пространств имен могут быть беспорядочными

Указать среду Cognos на новый источник безопасности не так просто, как добавить новое пространство имен с теми же пользователями, группами и ролями, отключить старое пространство имен и VOILA! - все ваши пользователи Cognos в новом пространстве имен сопоставляются с их содержание. На самом деле, у вас часто может получиться кровавое месиво на руках, и вот почему ...

На всех участников безопасности Cognos (пользователей, группы, роли) ссылается уникальный идентификатор, называемый CAMID. Даже если все остальные атрибуты равны, CAMID для пользователя в существующий пространство имен аутентификации не будет таким же, как CAMID для этого пользователя в new пространство имен. Это может нанести ущерб существующей среде Cognos. Даже если у вас всего несколько пользователей Cognos, вы должны понимать, что ссылки CAMID существуют во МНОГИХ разных местах в вашем Content Store (и могут даже существовать вне вашего Content Store в моделях Framework, Transformer Models, TM1 Applications, Cubes, Planning Applications и т. Д. ).

Многие клиенты Cognos ошибочно полагают, что CAMID действительно имеет значение только для содержимого My Folder, пользовательских предпочтений и т. Д. Это далеко от истины. Дело не только в количестве ваших пользователей, но и в количестве объектов Cognos, о которых вам нужно позаботиться. Только в Content Store имеется более 140 различных типов объектов Cognos, многие из которых могут иметь несколько ссылок CAMID..

Например:

1. Нередко в одном расписании в вашем Content Store есть несколько ссылок CAMID (CAMID владельца расписания, CAMID пользователя, от имени которого должно работать расписание, CAMID каждого пользователя или списка рассылки, на который он должен отправить сгенерированный отчет по электронной почте. , так далее.).
2. Каждый объект в Cognos имеет политику безопасности, которая определяет, какие пользователи могут получить доступ к объекту (подумайте о вкладке «Права доступа»). Одна политика безопасности, свисающая с этой папки в Cognos Connection, имеет ссылку на CAMID для каждого пользователя, группы и роли, которые указаны в этой политике.
3. Надеюсь, вы уловили суть - этот список можно продолжать и продолжать!

Нередко значительное хранилище контента содержит десятки тысяч ссылок CAMID (и мы видели некоторые крупные с сотнями тысяч).

Теперь посчитайте, что в надежная Cognos, и вы можете увидеть, что потенциально имеете дело с полчищами ссылок CAMID. Это может быть кошмар! Переключение (или повторная настройка) пространства имен аутентификации может оставить все эти ссылки CAMID в неразрешимом состоянии. Это неизбежно приводит к проблемам с контентом и конфигурацией Cognos (например, расписания, которые больше не выполняются, контент, который больше не защищен так, как вы думаете, пакеты или кубы, которые больше не реализуют безопасность на уровне данных, потеря контента My Folder и пользователя предпочтения и др.).

Методы перехода пространства имен Cognos

Теперь, зная, что среда Cognos может иметь десятки тысяч ссылок CAMID, которые потребуют поиска, сопоставления и обновления соответствующего нового значения CAMID в новом пространстве имен аутентификации, давайте обсудим подходы Good, Bad и Ugly для решения этой проблемы.

Хорошо: Замена пространства имен на Persona

Первый метод (замена пространства имен) использует Motio«S, Персона IQ продукт. При таком подходе существующее пространство имен «заменяется» специальным пространством имен Persona, которое позволяет виртуализировать всех участников безопасности, доступных для Cognos. Ранее существующие участники безопасности будут доступны Cognos с тем же самым CAMID, что и раньше, даже если они могут поддерживаться любым количеством внешних источников безопасности (например, Active Directory, LDAP или даже базой данных Persona).

Самое прекрасное в этом подходе состоит в том, что он не требует НУЛЕВЫХ изменений в вашем контенте Cognos. Это связано с тем, что Persona может поддерживать CAMID уже существующих принципалов, даже если они поддерживаются новым источником. Итак ... все эти десятки тысяч ссылок CAMID в вашем Content Store, внешние модели и исторические кубы? Они могут оставаться такими, какие они есть. Никакой работы не требуется.

Это, безусловно, наименее рискованный подход с минимальным воздействием, который вы можете использовать для перехода существующей среды Cognos с одного внешнего источника безопасности на другой. Это можно сделать менее чем за час при простое Cognos около 5 минут (единственное время простоя Cognos - это перезапуск Cognos после того, как вы настроили пространство имен Persona).

Плохой: Миграция пространства имен с использованием Persona

Если простой подход с низким уровнем риска - не ваша чашка чая, тогда is другой вариант.

Персона также может использоваться для выполнения миграции пространства имен.

Это включает в себя установку второго пространства имен аутентификации в вашей среде Cognos, сопоставление (надеюсь) всех ваших существующих участников безопасности (из старого пространства имен) с соответствующими участниками в новом пространстве имен, а затем (вот интересная часть), поиск, сопоставление и обновление каждого единственная ссылка CAMID, которая существует в вашей среде Cognos: ваше Content Store, Framework Models, Transformer Models, Historical Cubes, TM1 Applications, Planning Applications, и т. д.

Такой подход, как правило, вызывает стресс и требует интенсивного процесса, но если вы из тех администраторов Cognos, которым нужен небольшой выброс адреналина, чтобы почувствовать себя живым (и который не возражает против телефонных звонков поздно ночью / рано утром), тогда, возможно… этой тот вариант, который вы ищете?

Persona может использоваться для автоматизации отдельных частей этого процесса. Это поможет вам создать сопоставление между старыми участниками безопасности и новыми участниками безопасности, автоматизировать логику грубой силы «найти, проанализировать, обновить» для контента в вашем хранилище контента и т. Д. What Persona может автоматизировать некоторые из задач здесь, в значительной степени Работы при таком подходе вовлекают «людей и процесс», а не настоящие технологии.

Например, сбор информации по каждой модели Framework Manager, каждой модели Transformer, каждому приложению Planning / TM1, каждому приложению SDK, кому они принадлежат, а также планирование того, как они будут обновляться и распространяться, может потребовать много работы. Координация простоев для каждой из сред Cognos, в которых вы хотите это сделать, и периоды обслуживания, в течение которых вы можете попытаться выполнить миграцию, могут включать планирование и «время простоя» Cognos. Придумать (и выполнить) эффективный план тестирования после миграции также может быть довольно сложно.

Также вполне нормально, что вы сначала захотите выполнить этот процесс в непроизводственной среде. до пробовать это в продакшене.

Хотя миграция пространства имен с помощью Persona действительно работает (и она намного лучше, чем «уродливый» подход ниже), она более инвазивна, более рискованна, включает гораздо больше персонала и требует гораздо больше человеко-часов, чем замена пространства имен. Обычно миграции необходимо выполнять в нерабочее время, пока среда Cognos все еще находится в оперативном режиме, но ограниченное использование формы конечными пользователями.

Гадкий: Службы миграции пространства имен вручную

Уродливый метод заключается в незавидном подходе к попыткам вручную перейти из одного пространства имен аутентификации в другое. Это включает в себя подключение второго пространства имен аутентификации к вашей среде Cognos, а затем попытку вручную переместить или воссоздать большую часть существующего содержимого и конфигурации Cognos.

Например, используя этот подход, администратор Cognos может попытаться:

1. Восстановите группы и роли в новом пространстве имен
2. Восстановите членство этих групп и ролей в новом пространстве имен
3. Вручную скопируйте содержимое моих папок, пользовательские настройки, вкладки портала и т. Д. Из каждой исходной учетной записи в каждую целевую учетную запись.
4. Найдите каждый набор политик в Content Store и обновите его, чтобы он ссылался на эквивалентных участников в новом пространстве имен точно так же, как он ссылался на участников из старого пространства имен.
5. Восстановите все расписания и заполните их соответствующими учетными данными, получателями и т. Д.
6. Сбросить все свойства «владелец» и «контакт» для всех объектов в Content Store.
7. [Еще около 40 вещей в Content Store, о которых вы собираетесь забыть]
8. Соберите все FM-модели с безопасностью на уровне объекта или данных:
   1. Обновите каждую модель соответствующим образом
   2. Повторно опубликуйте каждую модель
   3. Распространите измененную модель обратно первоначальному автору
9. Аналогичная работа для моделей Transformer, TM1 Applications и Planning Applications, которые защищены от исходного пространства имен.
10. [и многое другое]

Хотя некоторые мазохисты Cognos могут втайне хихикать от идеи щелкнуть 400,000 XNUMX раз в Cognos Connection, для большинства здравомыслящих людей этот подход имеет тенденцию быть чрезвычайно утомительным, отнимающим много времени и подверженным ошибкам. Однако это не самая большая проблема при таком подходе.

Самая большая проблема этого подхода в том, что он почти всегда приводит к неполной миграции.

Используя этот подход, вы (с трудом) находите и пытаетесь сопоставить те ссылки CAMID, о которых вы знаете ... но, как правило, оставляете все те ссылки CAMID, которые вы не знаю о.

После того как вы think вы закончили с этим подходом, вы часто не на самом деле сделанный.

У вас есть объекты в вашем хранилище контента, которые больше не защищены так, как вы думаете ... у вас есть расписания, которые работают не так, как раньше, у вас есть данные, которые больше не защищены так, как вы думаете это так, и у вас могут быть даже необъяснимые ошибки для определенных операций, которые ты не можешь понять.

Причины, по которым плохой и уродливый подходы могут быть ужасными:

• Автоматическая миграция пространства имен создает большую нагрузку на Content Manager. Проверка и возможное обновление каждого отдельного объекта в вашем Content Store часто может приводить к десяткам тысяч вызовов SDK в Cognos (практически все из которых проходят через Content Manager). Этот ненормальный запрос обычно приводит к резкому увеличению использования / загрузки памяти и подвергает Content Manager риску сбоя во время миграции. Если у вас уже есть какая-либо нестабильность в вашей среде Cognos, вам следует очень опасаться этого подхода.
• Миграция пространства имен требует значительного периода обслуживания. Cognos необходимо активировать, но вы не хотите, чтобы люди вносили изменения в процессе миграции. Обычно это требует запуска миграции пространства имен, когда никто больше не работает, скажем, в 10:10 в пятницу вечером. Никто не хочет начинать напряженный проект в XNUMX:XNUMX в пятницу вечером. Не говоря уже о том, что ваши умственные способности, вероятно, не в лучшем виде по ночам и в выходные на проекте, который приносит требовать от вас внимания!
• Я упомянул, что миграции пространств имен требуют много времени и труда. Вот еще немного об этом:
  • Процесс отображения контента должен выполняться с высокой точностью, а для этого требуется командная работа и много человеко-часов.
  • Требуется несколько пробных прогонов для проверки ошибок или проблем с переносом. Типичная миграция не проходит идеально с первого раза. Вам также понадобится действующая резервная копия вашего Content Store, которую можно будет восстановить в таких случаях. Мы видели много организаций, у которых нет хорошей резервной копии (или есть резервная копия, которую они не осознают, что она неполная).
  • Вам нужно все идентифицировать внешнюю хранилище содержимого, которое может быть потенциально затронуто (каркасные модели, модели преобразователей и т. д.). Эта задача может включать координацию между несколькими командами (особенно в больших общих средах бизнес-аналитики).
  • Вам нужен хороший план тестирования, в котором участвуют репрезентативные люди с разной степенью доступа к вашему контенту Cognos. Ключевым моментом здесь является проверка вскоре после завершения миграции, что все полностью перенесено и работает так, как вы ожидаете. Обычно нецелесообразно проверять все, поэтому вы в конечном итоге проверяете то, что, как вы надеетесь, является репрезентативными образцами.
• Вы должны иметь бroad знание среды Cognos и вещей, которые от нее зависят. Например, исторические кубы с настраиваемыми представлениями ДОЛЖНЫ быть перестроены, если вы идете по маршруту NSM.
• Что, если вы или компания, которой вы поручили перенос пространства имен, забыли о чем-то, например о… приложениях SDK? После того, как вы щелкнете переключателем, эти вещи перестают работать, если они не обновлены должным образом. Есть ли у вас надлежащие проверки, чтобы это сразу заметить, или пройдет несколько недель / месяцев, прежде чем симптомы начнут проявляться?
• Если вы подвергались многочисленным обновлениям Cognos, у вас потенциально могут быть объекты в вашем Content Store, которые находятся в несогласованном состоянии. Если вы не работаете с SDK, вы не сможете увидеть, какие объекты находятся в этом состоянии.

Почему замена пространства имен - лучший вариант

Ключевые факторы риска и требующие много времени шаги, которые я только что обрисовал, устраняются при использовании метода замены пространства имен Persona. При использовании подхода замены пространства имен у вас будет 5 минут простоя Cognos, и ни один из ваших материалов не должен меняться. «Хороший» метод кажется мне простой и понятной задачей. Вечера пятницы предназначены для отдыха, а не для беспокойства по поводу того факта, что ваш Content Manager только что разбился во время миграции пространства имен.