Конец года, все потихоньку подводят итоги.

Для меня этот год запомнился проектом внедрения Single Sign On (SSO) между SAP и Windows. В этой статье расскажу об опыте внедрения и проектного менеджмента, подводных камнях, находках и выводах.

Компания — крупное транспортное предприятие в Бельгии, объединяющее метро, трамвай и автобус. Сотрудников более 10 тысяч, из них почти две тысячи это backoffice, использующий много инструментов: корпоративный сайт, почту, службу заявок, sharepoint, архивариус и, конечно, SAP.

SAP повсюду: от бухгалтерии и HR до регистрации движения транспортных единиц, документации аварий, аналитики, закупок, складирования и т.д.

Проблема:

• SAP для пользователя PC — это отдельное приложение, для входа в которое нужен свой пароль
• Сначала пароль нужно запросить, а потом помнить. Техподдержка вынуждена принимать звонки по созданию и смене паролей.
• С точки зрения пользователя лишний пароль — это лишние хлопоты. Люди хранят пароли на бумажках или делают их слишком простыми. Безопасность вопит о грубых нарушениях.
• Минимальные требования для пароля от PC не совпадают с параметрами паролей в SAP. Если приводить их к единому знаменателю, то лучше сразу внедрить SSO.

Задача: внедрить SSO между Windows и SAP, чтобы, заходя в свою учётную запись на PC, пользователь мог залогиниться в SAP не вводя пароль.

Если вы не имеете дела с SAP вам будет интересна эта статья с точки зрения менеджмента проекта, для сапёров тех детали будут приведены (в скобках).

Под катом:

1. Scope
   1.1 Scope Люди
   1.2 Scope системы
2. Компоненты
   2.1 Изменение параметров системы
   2.2 Windows Active Directory (AD)
   2.3 SAP Secure Login Client (SLC)
   2.4 Привязка пользователя SAP к его AD
   2.5 Модификация файла SAP logon.ini
3. Тестирование
4. SNC это дыра в безопасности
5. Командная работа
6. Информация для бизнеса
7. Трудности перевода
8. Итоги и выводы

Введение

Забегая вперёд, если вы не горите желанием набивать стандартные шишки, вот список вопросов, которые вы должны прояснить для себя в самом начале проекта:

• Scope проекта (Системы, пользователи – в каком порядке внедряем, где приоритет и что можно отбросить если что-то пойдёт не так, какие пользователи должны получить доступ и т.д.)
• Основные отделы, затронутые проектом (Даже если проект по ним проходит «по касательной», всё равно важно, чтобы все были в курсе заранее)
• Ваши полномочия (Здесь не сильно можно разбежаться – в европейской компании всё строится на согласии и добровольном желании помочь. Если отдел скажет, что у них нет ресурсов, то надавить и «заставить» практически невозможно. Но можно позвать стороннего консультанта для помощи, например)
• Сроки (Для всего проекта в целом и для конкретных частей)
• Процедуры согласования (Бюрократические регламенты — в большой компании это далеко не последний вопрос)
• Возможные сложности (Все. Возможные. Сложности.)

У нас состав участников проекта менялся несколько раз: сначала это был только отдел авторизации в SAP и отдел администраторов (Basic Components). Затем к ним присоединились отдел занимающийся авторизацией в Windows (Active Directory, AD) и отдел внедрения обновлений (Packaging), затем отдел баз данных и отдел мобильных приложений, и т.д.

Для технической стороны дела был приглашён внешний консультант, а Project Manager (ПМ) стала я, как человек занимающийся авторизациями в SAP (поэтому деталей по авторизациям в SAP в этой статье будет больше, чем других).

Важное уточнение: весь доступ, который мы даём в SAP, кастомизирован. Мы не пользуемся стандартными ролями, которые предлагает система, а создаём новые, под отдел, под позиции, под функции. На сегодняшний день у нас нет синхронизации между пользователями SAP и Windows AD. Например, если у вас пользователь обладает правами администратора в локальной сети, то это не значит, что он также администратор в SAP.

1. Scope

1.1 Scope Люди

Люди в нашей компании пользуются SAPом через приложение на личном компьютере (тонкий клиент — SAP Logon GUI), но не только. Как считать пользователей, попадающих под раздачу?

Мы взяли за основу всех, кто ежедневно подключается через SAP Logon (SAP user type Dialogue) с ноутбуков. В этой категории весь backoffice — сотрудники администрации, бухи, ичары, разработчики, тестировщики, логистика и т.д.

Исключили:

• тех, у кого стационарный компьютер, а не ноут
• 8 тысяч пользователей, которые никогда не открывают SAP logon, а пользуются SAPом через сайт и приложения (SAP user type Communication)
• всех внешних пользователей (не сотрудники, но должны логиниться в системе через VPN)

1.2 Scope Systems

В нашей компании в SAPе используются шесть активных landscapes (ECC, BI, SRM, Netweaver, PI, Solution manager), не считая песочниц. У каждой из них свои DEV, ACC, PRD — т.е. фактически это 6*3 = 18 систем.

Гласным голосованием было решено взять только первые четыре landscapes. PI и SM используются узким кругом администраторов и требуют обновления самой системы (по крайней мере обновления SAP_BASIS component до версии 740). Иначе транзакция sncwizard не поддерживается, а вручную это делать слишком хлопотно ради 10-20 человек.

2. Компоненты

Люди, интересующиеся тех деталями, найдут на сайте SAP пошаговую инструкцию, так же как и различные доступные способы (мы выбрали SSO based on Kerberos, но это не всегда очевидный вариант).

С очень упрощенной точки зрения (моей), SSO это надстройка в SAP, позволяющая вам заходить в систему, используя свою учётную запись Windows. Вы включаете компьютер, вводите пароль, и для того чтобы зайти в SAP вам достаточно двойного клика.

Чтобы магия сработала нужно 5 составляющих:

2.1 Изменение параметров системы (instances SAP)

В системе SAP (ECC, BI, SRM, Netweaver) нужно активировать параметр snc/enable =1. Это делается через sncwizard и включает подготовку, перезагрузку системы и окончательные шаги активации.

С параметрами до и после мы разобрались силами тех консультанта, помощи со стороны других отделов и методом проб и ошибок. Самое сложное здесь был рестарт системы.

На производстве всегда сложно перезапускать PRD, работа идёт круглосуточно. А в транспортной компании это вдвойне сложнее: транспорт двигается с пяти утра и до часу ночи, даже по выходным. Любые сложности с PRD влияют не только на сотрудников компании, но на весь город и десятки тысяч людей. Другими словами — нужно минимизировать время, когда система недоступна и по возможности совместить с другими обновлениями. При этом нельзя недооценивать бюрократию: рестарт это заранее согласованные по регламенту даты, время, продолжительность (если с первого раза параметры не сохранятся) и уведомление бизнеса.

У нас было четыре системы SAP PRD: ECC, Netweaver, SRM, BI – для перезагрузки

ECC — самая важная, на неё завязаны все данные реального времени и основной транспорт: автобусы, трамваи.

Данные системы Netweaver (аварии, мобильные приложения), как и системы ECC используются даже в 3 часа ночи — если трамваи не ходят, то ходят ремонтные бригады.

Система SRM — в основном используется для закупок и была доступна в любой день после 18:00.

С BI сложность в том, что на выходных в систему идут потоки загрузки данных из ECC, кроме того, иногда отчёты из BI, используются высшим менеджментом вне рабочих часов.

В совокупности на перезагрузки всех PRD ушло 2 недели.
P.S. Рестарту каждой из систем PRD предшествовали рестарты всех DEV и ACC, которые проще в согласовании, но также требуют планирования.

2.2 Windows Active Directory (AD)

В Active Directory требуется создание специального технического пользователя (SAP Kerberos). Этот пользователь будет связываться с Windows чтобы получить копию входного «тикета» для SAP. Достаточно одного такого сервисного пользователя AD для всех систем SAP.

Эта часть была целиком сделана нашим внешним консультантом и командой Active Directory, включала в себя несколько итераций по уточнению параметров и настройке спец.библиотеки, но для меня в большей степени осталась «чёрным ящиком».

2.3 Установка на компьютер пользователя программы SAP Secure Login Client (SLC)

Эта программа сама по себе ничего не делает. Она нужна, чтобы хранить тикет от AD, подтверждающий вашего пользователя при входе в сессию Windows, и при необходимости предоставлять этот тикет в SAP для авторизации. SLC можно установить всем пользователям сразу в начале проекта — без остальных компонентов SSO она всё равно работать не будет.

2.4 Привязка пользователя SAP к его пользователю AD

Как уже было сказано, в нашей компании нет единого управления пользователями, доступ в разных системах получают от разных команд. При этом login пользователя в SAP отличается от имени пользователя в Windows, например пользователь #45011 в AD это Иван Иванов или ИВАНОВИ. Именно эту связку и надо заполнить в SNC (через транзакцию SU01, поле SNC, p:CN=ADname@domain).

В нашей компании нет SAP Identity Management. Поэтому надо было решить две задачи: создание новых пользователей и обновление параметров существующих.

Создание новых пользователей
В основной системе (ECC) каждый рабочий день создаётся 4-6 новых логина, это за год почти 1000 новых пользователей. Процесс автоматизирован: при создании пользователя программа заполняет его адрес, имя, базовые настройки. Мы решили, что программа также должна заполнять поле SNC на этапе создания пользователя, независимо от того, потребуется ли человеку SSO в SAP впоследствии или нет.

Загвоздка была в том, что для каждого пользователя надо заполнить уникальное собственное имя в AD, т.е. это не одинаковый для всех параметр — т.е. надо чтобы программа сама искала имя пользователя в AD и заполняла его в SAP.

Разработчик быстро обновил программу. На код и базовое тестирование ушло 2 дня, но данные для проверки в ACC нам не подходили (AD не обновлялась), поэтому мы сразу отправили изменения в PRD. Там выяснилось что всё сложнее, чем мы думали. В процессе расследования пришли вот к такой схеме:

1. Сначала пользователи создаются в HR системе (в SAPе их можно увидеть в PA20)
2. Потом они копируются в Z-таблицу, вместе с данными про отдел, должность, позицию, является ли руководящим звеном и т.д.
3. Затем данные по пользователям отсылаются в AD и здесь система создаёт пользователя в Windows, и даёт ему имя в AD и почту
4. Поток PI в этой схеме просто чтобы понимать, что это сторонний процесс третьей системы
5. Данные копируются обратно в SAP (в новую Z-таблицу), на этот раз просто имена AD и почтовые адреса
6. На последнем этапе запускается Z-программа, которая создаёт пользователей в SAP (SU01). Не все пользователи, кто создан в HR системе будут созданы последствии в SAP, есть немало таких, кто в итоге ни в каком виде не пользуется SAPом

Почти две недели ушло на поиск, согласование изменений, согласование графика обновления и загрузки-выгрузки таблиц. Дело было в синхронизации — программа по созданию пользователей (пункт 6) должна строго запускаться после того, как все другие программы уже отработали и данные скопированы в таблицы. В итоге две недели мы отслеживали, когда какая программа завершилась и в какое время, и отлаживали схему.

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

Обновление параметров существующих пользователей
Именно потому что у нас login SAP и Windows не совпадают, мы не смогли воспользоваться стандартным решением от SAP для массового заполнения поля SNC (программа RSUSR300 via SNC1).

В итоге данные 10 тысяч существующих пользователей я обновляла с помощью самодельного скрипта (SAP eCATT), выгрузив данные по пользователям вручную и создав variant. Для успеха пришлось открыть для изменений и eCATT системы в PRD и ACC и пообещать разработчикам миллионы печенек.

2.5 Модификация файла SAP logon.ini

Технически это дело 1 минуты. Надо лишь отметить в свойствах файла, что доступно подключение через SNC.

Сложность в том, что этот файлик находится локально на PC пользователя и надо поменять его у двух тысяч пользователей.

Фактически для нас финальное внедрение было моментом распределения нового файла sap.logon.ini среди пользователей, а не изменение параметров PRD. Потому что даже если первые четыре составляющие уже сделаны, а последняя пятая нет, то магия не случится.

С последним пунктом вышел небольшой казус. Я отчиталась перед руководством, что у нас 2000 пользователей, у кого будет установлено обновление, а когда пришло время внедрять, мне прислали статус, где их было 3500. Стало не по себе. Всё потому, что я со своей стороны видела только активных пользователей SAP, а в действительности обновление было отправлено на все персональные ноутбуки, которых в компании гораздо больше. Слава богу никаких багов с технической стороны не возникло.

3. Тестирование

Как тестировать SSO? Либо он работает, либо нет. Наш разработчик фыркал и говорил, что тестировать ничего не нужно, и как только всё заработает в «песочнице», нужно отсылать в продакшн. Конечно. Nobody will say he writes code with bugs.

Проверять надо:

• работает ли вход в SAP с SSO сразу после перезагрузки
• могут ли пользователи пользоваться SSO когда подключены с VPN
• сложности для разработчиков для других систем, для модификации SAP logon

SSO это не программа, её сложно внедрять последовательно DEV — ACC — PRD. Но тем не менее первичное тестирование необходимо, чтобы уловить всё, что потенциально может пойти не так. Тестирование в данном случае это распределение нового SAP logon.ini, когда все компоненты уже запущены. Мы тестировали DEV и ACC с разработчиками и новый SAP logon.ini c PRD c выборкой бизнес пользователей.

Что нашли:

• иногда (1 случай на 500) надо полностью переустановить SAP logon или SLC
• key users, у которых есть права менять других пользователей (об этом в след пункте)

4. SNC это дыра в безопасности

Как быть с модификацией поля SNC?
Дело в том, что изменив поле SNC у другого пользователя (в SU01) на своё, вы можете подключиться под чужим аккаунтом, даже не меняя пароля. Система вас просто спросит какого пользователя выбрать, вашего или чужого. При этом, если вы это сделаете, завтра никто ничего не заметит, потому что пароль остался неизменным.

В любой компании есть люди, которые занимаются user management. Обычно эти люди следят за созданием пользователей (SU01) и доступа для них (PFCG), а также обновлением паролей. Совершенно логично, что они также могут заполнять поле SNC.

Проблема возникает, когда в компании надо разделять user management и просто key users. Администраторы создают пользователей, а key users при необходимости меняют их данные: параметры пользователя, его язык, его место локации и т.д.

В SAP для измененеия поля SNC нет отдельного этапа контроля. Все у кого есть права для изменения юзера (объект S_USER_GRP, ACTVT 02) также могут менять поле SNC (тогда как для изменения пароля требуется тот же объект, но c ACTVT 05).

Решений может быть несколько:

• забрать права доступа к SU01 у ключевых пользователей, а в ответ всем дать SU2 и SU3, где пользователь может поменять собственные параметры
• забрать права доступа к SU01, а в обмен дать z-транзакцию, где вкладка SNC показана не будет
• оставить SU01, но защитить поле SNC специальным контролем

Мы в итоге выбрали последний вариант, сделав custom authorisation object и завязав программу SU01 на него. Правда, как выяснилось потом, у SAP есть похожее решение — можно активировать extended maintenance (note 1882254) для отдельных полей SU01.

5. Командная работа

За время проекта я столкнулась со всеми сложностями командной работы и открыла для себя много базовых истин:

• Времени много не бывает. Запас времени — это лучшее, что может предусмотреть ПМ.
• Должен быть базовый план проекта, но пересматривать его нужно каждую неделю, оставляя большой запас для гибкости. Где-то мы двигались быстрее, где-то топтались на месте.
• Взрослые дяди в ИТ отделе иногда по поведению не отличаются от девчонок в бухгалтерии: отказываются работать с друг с другом, просто потому что человек им не нравится. И требуется лишний раз урегулировать вопросы субординации.
• Часто отделы тормозят согласование проекта, потому что не понятно на чьей ответственности лежит внедрение и на чей бюджет ложатся дополнительные часы работы. Важно дать менеджерам всё обговорить напрямую.
• То и дело возникают непредвиденные ситуации. Лучшее, что может быть, это своевременная коммуникация, письмо, звонок, смс всем задействованным людям.
• Нет ничего лучше, чем личная встреча. Вопросы решаются в разы быстрее, чем при обсуждении по почте. С другой стороны все личные договоренности должны тут же сопровождаться последующим письмом (чтобы закрепить и не забыть)
• ПМ в ИТ проекте может только доверять людям. На деле вы понятия не имеете сколько реально по времени будет занимать то или иное действие: например, создание пользователя в AD для Kerberos,10 минут или три дня? И нет никакой возможности проверить реально ли стопорилось тестирование или кто-то валял дурака. Остаётся только доверять.

Кроме всего от настойчивости консультанта зависит многое. Кто-то один, или консультант-разработчик или ПМ должен быть как пуля дерзким и пробивать стены бюрократии. В данном случае мне отчасти повезло, наш приглашённый консультант был назойливым и порой невыносимым (сложно было заставить его что-то услышать), но своё дело знал: о любых проблемах и остановках сообщал немедленно и не успокаивался пока проблема не разрешалась.

6. Информация для бизнеса

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

В нашем случае надо было проинформировать всех пользователей, что теперь им не нужен пароль для входа в SAP. Также, надо было предоставить техдокументацию для 1ой линии поддержки со всеми возможными ошибками, которые могут возникнуть после внедрения.

Надо признаться, что с коммуникацией всё что могло, пошло не так.

Во-первых, мы объявили пользователям об SSO на корпоративном сайте, а не письмом. Как часто вы читаете корпоративный сайт? Многие просто ничего не заметили до тех пор пока их SAP внезапно не перестал запрашивать пароль.

Во-вторых, девушка, ответственная за размещение инфы, заболела, перепоручила, не проверила, мне сказали подождать неделю, я отказалась (в конце концов из-за оповещения задерживать проект?) и мой текст оказался на сайте без вычитки, с кучей очепяток.

В-третьих, техподдержка написала мне в день Go Live, что они не поддерживают изменения, если документация им пришла меньше чем за неделю (я отправила документацию за 2 дня), и что в случае звонков мы будем выкручиваться сами. Хорошо что технических ошибок не было.

7. Трудности перевода или последний fuck-up

Проект запустился и уже вовсю шёл 5-ый день эры SSO в нашем SAP, когда мы обнаружили слона, которого никто не заметил.

В компании присутствует два языка: голландский и французский. Априори, благо компания расположена в Брюсселе — у всех стоит французский. Но тем не менее многие сотрудники подключаются через голландский или английский. В общей сложности из 2-х тысяч активных пользователей, почти 500 человек это голландско-говорящие. Раньше они сами всякий раз меняли язык в окошке подключения.

Теперь у всех по дефолту оказался французский. Причём если бы мы оставили галочку “use a default language SAP logon” пустой — никаких вопросов не возникло бы, каждый бы подключался с тем языком, какой у него отмечен в параметрах (SU01, вкладка Defaults). После внедрения посыпались звонки с просьбой «сменить пользователю SAP».

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

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

8. Итоги и выводы

В целом внедрить SSO — это просто, когда вы это уже сделали хотя бы один раз в жизни. Говорят, что это вопрос 1-2 недель работы, но никак не 3-х месяцев.

На деле всё сильно зависит от масштабов компании. Каждая компания имеет свои особенности и много энергии и ресурсов уходит именно на понимание этих нюансов. В нашем случае три месяца было именно столько, сколько нужно для всех встреч, согласований, изменений.

Многие вещи про SSO были, возможно, уже давно известны, как минимум, гуглу. Например про запрос сервера к AD, или поле SNC. Но есть такая вещь, как вечная нехватка времени. Как специалист вы обязаны гуглить, а как менеджер проекта (особенно если вы не можете разобраться в первые полчаса, и у вас нет профильного образования) — вы должны найти самый короткий путь к решению.

Как правило, самым коротким путём оказывается спросить, причём спросить устно. 

Сухой остаток:

• Основное время за 3 месяца ушло на согласование и координацию действий
• Отделы, принимавшие участие в этом проекте, стали лучше понимать работу друг друга
• Во время тестирования надо представлять себя на месте конечного пользователя – чтобы вы хотели увидеть в информационном сообщении, и в базовых настройках.
• SSO для SAP внедрён. Пользователи рады и уже забыли о временах, когда надо было помнить пароль от SAP. В техподдержку звонят реже, ура.