Конец года, все потихоньку подводят итоги.  Для меня этот год запомнился проектом внедрения Single Sign On (SSO) между SAP и Windows. В этой статье расскажу об опыте внедрения и проектного менеджмента, подводных камнях, находках и выводах.   Компания — крупное транспортное предприятие в Бельгии, объединяющее метро, трамвай и автобус. Сотрудников более 10 тысяч, из них почти две тысячи это backoffice, использующий много инструментов: корпоративный сайт, почту, службу заявок, sharepoint, архивариус и, конечно, SAP.  SAP повсюду: от бухгалтерии и HR до регистрации движения транспортных единиц, документации аварий, аналитики, закупок, складирования и т.д.  Проблема:  Задача: внедрить SSO между Windows и SAP, чтобы, заходя в свою учётную запись на PC, пользователь мог залогиниться в SAP не вводя пароль.  Если вы не имеете дела с SAP вам будет интересна эта статья с точки зрения менеджмента проекта, для сапёров тех детали будут приведены (в скобках).  Под катом:  Забегая вперёд, если вы не горите желанием набивать стандартные шишки, вот список вопросов, которые вы должны прояснить для себя в самом начале проекта:  У нас состав участников проекта менялся несколько раз: сначала это был только отдел авторизации в SAP и отдел администраторов (Basic Components). Затем к ним присоединились отдел занимающийся авторизацией в Windows (Active Directory, AD) и отдел внедрения обновлений (Packaging), затем отдел баз данных и отдел мобильных приложений, и т.д. Для технической стороны дела был приглашён внешний консультант, а Project Manager (ПМ) стала я, как человек занимающийся авторизациями в SAP (поэтому деталей по авторизациям в SAP в этой статье будет больше, чем других). Важное уточнение: весь доступ, который мы даём в SAP, кастомизирован. Мы не пользуемся стандартными ролями, которые предлагает система, а создаём новые, под отдел, под позиции, под функции. На сегодняшний день у нас нет синхронизации между пользователями SAP и Windows AD. Например, если у вас пользователь обладает правами администратора в локальной сети, то это не значит, что он также администратор в SAP.  Люди в нашей компании пользуются SAPом через приложение на личном компьютере (тонкий клиент — SAP Logon GUI), но не только. Как считать пользователей, попадающих под раздачу?  Мы взяли за основу всех, кто ежедневно подключается через SAP Logon (SAP user type Dialogue) с ноутбуков. В этой категории весь backoffice — сотрудники администрации, бухи, ичары, разработчики, тестировщики, логистика и т.д.  Исключили:  В нашей компании в 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 человек.  Люди, интересующиеся тех деталями, найдут на сайте SAP пошаговую инструкцию, так же как и различные доступные способы (мы выбрали SSO based on Kerberos, но это не всегда очевидный вариант).  С очень упрощенной точки зрения (моей), SSO это надстройка в SAP, позволяющая вам заходить в систему, используя свою учётную запись Windows. Вы включаете компьютер, вводите пароль, и для того чтобы зайти в SAP вам достаточно двойного клика.  Чтобы магия сработала нужно 5 составляющих:   В системе 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, которые проще в согласовании, но также требуют планирования. В Active Directory требуется создание специального технического пользователя (SAP Kerberos). Этот пользователь будет связываться с Windows чтобы получить копию входного «тикета» для SAP. Достаточно одного такого сервисного пользователя AD для всех систем SAP.   Эта часть была целиком сделана нашим внешним консультантом и командой Active Directory, включала в себя несколько итераций по уточнению параметров и настройке спец.библиотеки, но для меня в большей степени осталась «чёрным ящиком».   Эта программа сама по себе ничего не делает. Она нужна, чтобы хранить тикет от AD, подтверждающий вашего пользователя при входе в сессию Windows, и при необходимости предоставлять этот тикет в SAP для авторизации. SLC можно установить всем пользователям сразу в начале проекта — без остальных компонентов SSO она всё равно работать не будет.  Как уже было сказано, в нашей компании нет единого управления пользователями, доступ в разных системах получают от разных команд. При этом 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. Там выяснилось что всё сложнее, чем мы думали. В процессе расследования пришли вот к такой схеме:   Почти две недели ушло на поиск, согласование изменений, согласование графика обновления и загрузки-выгрузки таблиц. Дело было в синхронизации — программа по созданию пользователей (пункт 6) должна строго запускаться после того, как все другие программы уже отработали и данные скопированы в таблицы. В итоге две недели мы отслеживали, когда какая программа завершилась и в какое время, и отлаживали схему. Когда пользователи создаются с заполненным полем SNC, но без нужных AD имён, в SU01 можно увидеть всех юзеров-соратников по несчастью, привязанных к одному, несуществующему пользователю AD.  Обновление параметров существующих пользователей
Именно потому что у нас login SAP и Windows не совпадают, мы не смогли воспользоваться стандартным решением от SAP для массового заполнения поля SNC (программа RSUSR300 via SNC1). В итоге данные 10 тысяч существующих пользователей я обновляла с помощью самодельного скрипта (SAP eCATT), выгрузив данные по пользователям вручную и создав variant. Для успеха пришлось открыть для изменений и eCATT системы в PRD и ACC и пообещать разработчикам миллионы печенек.  Технически это дело 1 минуты. Надо лишь отметить в свойствах файла, что доступно подключение через SNC.   Сложность в том, что этот файлик находится локально на PC пользователя и надо поменять его у двух тысяч пользователей.  Фактически для нас финальное внедрение было моментом распределения нового файла sap.logon.ini среди пользователей, а не изменение параметров PRD. Потому что даже если первые четыре составляющие уже сделаны, а последняя пятая нет, то магия не случится. С последним пунктом вышел небольшой казус. Я отчиталась перед руководством, что у нас 2000 пользователей, у кого будет установлено обновление, а когда пришло время внедрять, мне прислали статус, где их было 3500. Стало не по себе. Всё потому, что я со своей стороны видела только активных пользователей SAP, а в действительности обновление было отправлено на все персональные ноутбуки, которых в компании гораздо больше. Слава богу никаких багов с технической стороны не возникло.  Как тестировать SSO? Либо он работает, либо нет. Наш разработчик фыркал и говорил, что тестировать ничего не нужно, и как только всё заработает в «песочнице», нужно отсылать в продакшн. Конечно. Nobody will say he writes code with bugs. Проверять надо:  SSO это не программа, её сложно внедрять последовательно DEV — ACC — PRD. Но тем не менее первичное тестирование необходимо, чтобы уловить всё, что потенциально может пойти не так. Тестирование в данном случае это распределение нового SAP logon.ini, когда все компоненты уже запущены. Мы тестировали DEV и ACC с разработчиками и новый SAP logon.ini c PRD c выборкой бизнес пользователей.  Что нашли: Как быть с модификацией поля 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).  Решений может быть несколько:  Мы в итоге выбрали последний вариант, сделав custom authorisation object и завязав программу SU01 на него. Правда, как выяснилось потом, у SAP есть похожее решение — можно активировать extended maintenance (note 1882254) для отдельных полей SU01. За время проекта я столкнулась со всеми сложностями командной работы и открыла для себя много базовых истин:  Кроме всего от настойчивости консультанта зависит многое. Кто-то один, или консультант-разработчик или ПМ должен быть как пуля дерзким и пробивать стены бюрократии. В данном случае мне отчасти повезло, наш приглашённый консультант был назойливым и порой невыносимым (сложно было заставить его что-то услышать), но своё дело знал: о любых проблемах и остановках сообщал немедленно и не успокаивался пока проблема не разрешалась.  В большой компании изменения, затрагивающие конечных пользователей, должны быть своевременно, а лучше заранее объявлены.  В нашем случае надо было проинформировать всех пользователей, что теперь им не нужен пароль для входа в SAP. Также, надо было предоставить техдокументацию для 1ой линии поддержки со всеми возможными ошибками, которые могут возникнуть после внедрения.  Надо признаться, что с коммуникацией всё что могло, пошло не так.  Во-первых, мы объявили пользователям об SSO на корпоративном сайте, а не письмом. Как часто вы читаете корпоративный сайт? Многие просто ничего не заметили до тех пор пока их SAP внезапно не перестал запрашивать пароль. Во-вторых, девушка, ответственная за размещение инфы, заболела, перепоручила, не проверила, мне сказали подождать неделю, я отказалась (в конце концов из-за оповещения задерживать проект?) и мой текст оказался на сайте без вычитки, с кучей очепяток. В-третьих, техподдержка написала мне в день Go Live, что они не поддерживают изменения, если документация им пришла меньше чем за неделю (я отправила документацию за 2 дня), и что в случае звонков мы будем выкручиваться сами. Хорошо что технических ошибок не было.  Проект запустился и уже вовсю шёл 5-ый день эры SSO в нашем SAP, когда мы обнаружили слона, которого никто не заметил.  В компании присутствует два языка: голландский и французский. Априори, благо компания расположена в Брюсселе — у всех стоит французский. Но тем не менее многие сотрудники подключаются через голландский или английский. В общей сложности из 2-х тысяч активных пользователей, почти 500 человек это голландско-говорящие. Раньше они сами всякий раз меняли язык в окошке подключения.  Теперь у всех по дефолту оказался французский. Причём если бы мы оставили галочку “use a default language SAP logon” пустой — никаких вопросов не возникло бы, каждый бы подключался с тем языком, какой у него отмечен в параметрах (SU01, вкладка Defaults). После внедрения посыпались звонки с просьбой «сменить пользователю SAP».  На этапе тестирования проблемы замечено не было, потому что почти все тестировщики оказались французско-говорящими, либо подключались на французском в повседневной работе.  Решили проблему отправкой инструкцией о смене языка всем нидерландо-говорящим пользователям дабы предовратить их новые звонки в техподдержку. В целом внедрить SSO — это просто, когда вы это уже сделали хотя бы один раз в жизни. Говорят, что это вопрос 1-2 недель работы, но никак не 3-х месяцев.  На деле всё сильно зависит от масштабов компании. Каждая компания имеет свои особенности и много энергии и ресурсов уходит именно на понимание этих нюансов. В нашем случае три месяца было именно столько, сколько нужно для всех встреч, согласований, изменений.  Многие вещи про SSO были, возможно, уже давно известны, как минимум, гуглу. Например про запрос сервера к AD, или поле SNC. Но есть такая вещь, как вечная нехватка времени. Как специалист вы обязаны гуглить, а как менеджер проекта (особенно если вы не можете разобраться в первые полчаса, и у вас нет профильного образования) — вы должны найти самый короткий путь к решению.  Сухой остаток: