Есть у Google Apps еще одна очень существенная “плюшка” – он умеет интегрироваться с некоторыми корпоративными службами каталогов совместимыми с LDAP, а именно Active Directory от Microsoft или Lotus Domino от IBM
Сразу же скажу, что весь сегодняшний текст (в отличии от остальных) – чисто теоретические измышления на базе прочтения хелпа. Почему так – будет описано в публикации. Если Вас это не смущает – прошу под кат.
Также скажу кому сегодняшний текст скорее всего не нужен – он не нужен тем, у кого локальная сеть организации децентрализована и не содержит сервера (серверов) домена с их службами. Также это не сильно поможет если у Вас несколько доменов (т.е. например почта создается на уровне факультета, но у каждой кафедры свой независимый домен). К сожалению на данный момент внутри школ и ВУЗов, крайне мало где есть даже такие зачатки автоматизации коллективной работы как у нас. Впрочем мне известны варианты, когда домена нет, а вот организация работы на более высоком уровне. Это я про центр Siemens PLM в БГТУ, им домен не так уж и сильно нужен, ибо у них Teamcenter. Впрочем TC у них был вместо домена почти 5 лет назад, и вполне возможно, что сейчас у них и то и другое (если, конечно оно им надо). Надо будет как-то еще в гости заехать, узнать чем живут соседи.
Теперь я обращусь к информации по связыванию, а потом объясню почему мы не пошли таким путем.
***
Итак. Согласно информации из хелпа. Того кто интегрирует свой LDAP с Google Apps ждет светлое будущее в виде:
- Синхронизация аккаунтов пользователей Google Apps в соответствии с пользовательскими данными на сервере LDAP.
- Поддержка сложных правил для персонализированного сопоставления пользователей, групп, контактов для лиц, не являющихся сотрудниками организации, а также расширенных профилей пользователей, псевдонимов, ресурсов календаря и исключений.
- Выполнение односторонней синхронизации, при которой данные на сервере LDAP не обновляются и не изменяются.
- Работа в качестве служебной программы в среде сервера. Теперь не нужно предоставлять доступ к данным сервера каталога LDAP компьютерам за пределами периметра сети.
- Наличие расширенных тестов и моделей, помогающих обеспечить правильность синхронизации.
- Наличие в установочном пакете всех необходимых компонентов.
Что это значит? Это значит что Вам дадут программу работающую по принципу “one click instal”, которая с минимальным количеством плясок с бубном (а в идеале вообще без них), свяжет Ваш Active Directory (например) с Google Apps. Причем связь будет автоматической и ассоциативной, когда изменения в Active Directory приводят к изменения в гуглоаппсах. При этом все получается достаточно надежно, ибо обратной связи нет.
Следовательно Вам нет надобности кучу раз выполнять одни и те же действия направленные на управление толпой пользователей. Все делается единожды и в AD, а синхронизация – дело техники.
Красивая сказка в светлое будущее, которая хоть и является действительностью, к сожалению показалась сказкой.
К сожалению или к счастью, но администрирование не является ни основной задачей, ни целью, ни любовью у меня и у коллег по кафедре отягощенных “правами администратора”. Нам приходится этим заниматься ибо иначе просто не останется времени ни на преподавание, ни на проекты. Мы осознаем необходимость, потому что это позволяет нам уделять больше времени любимым проектам (еще и потому, что проекты - основной источник дохода). Да и к тому же во многом исповедуем классический принцип лучше день потерять, потом за пять минут долететь. Только стараемся, чтобы общее время обучения искусству полета, было не сильно больше, чем дойти пешком. Отсюда получается, что занимаемся администрированием постольку-поскольку и в моменты когда припрет. Время получается уделять лишь урывками, иногда с длительными и очень длительными перерывами, и постоянно отвлекаясь на основные обязанности.
Так и вышло, что читая разные куски хелпа полностью сбили с толку. Так в “Способах добавления аккаунтов пользователей”:
Создать аккаунты пользователей можно несколькими способами, и каждый из них имеет свои преимущества. Возможные варианты перечислены ниже:
В английском варианте заметки возможность создания пользователей с помощью GADS даже боле стилистически подчеркнута, чем в русском: You can use Google Apps Directory Sync to synchronize your users (as well as groups, contacts, and organizations) from a LDAP directory to Google Apps.
Ну по крайней мере мне так кажется. Если не прав – поправьте. В любом случае нельзя сказать что русский и английский тексты противоречат друг другу.
Однако!
Однако, если начать смотреть их обучающие видео, и далее читать справку то получается, что GAPS созданием пользователей не занимается…
В качестве подтверждения данному утверждению приведу другую цитату из “Руководства по конфигурации GAPS”. Итак первый шаг:
1.Если вы до сих пор не создали аккаунты Google Apps для всех пользователей, выполните эти действия сейчас.
Причем это не единственный пункт, который так говорил. Возникало странное чувство что тебя кто-то наё… водит за нос. То ли постоянная спешка и природная невнимательность сыграла роль, то ли со временем справка стала более адекватной (факт ее изменения во времени был подтверждением сопоставлением некоторых записей из истории Evernote, с текущими записями справки), но как-то не было замечено, что речь идет о разных утилитах. Причем GAPS, для которой рекомендуют сначала создать пользователей, а потом включать синхронизацию,это лишь часть утилиты GADS, которая и пользователей умеет создавать. Сейчас в справке по синхронизации паролей говорится, что пользователей лучше всего делать GADS’ом. Тогда.. ну вот хоть режьте – не помню такого. Но, если можно то лучше не резать. Был еще ряд моментов, который поставил под сомнение приведенные в начале фразы. Допускаю, что не только справка “допиливалась” но и само ПО, и просто по началу не біло таких привлекательных для нас плюшек.
Ладно. Идем дальше. Почему мы не подключили это решение до сих пор? Начнем с Причина первая: “Сынок, если работает, главное - ничего не трогай, ничего не меняй”. Не скажу что у нас все работает так как нам бы хотелось. Но оно работает.
Другие причины вытекают из того, как все это в итоге должно работать. Об этом и поговорим.
Как по идее выглядит подобная интеграция? После того, как Вы заинтегрировали гугл с доменом, во избежание проблем рассинхронизации, для многих вещей домен становится определяющим. А именно: список пользователей, их пароли, вхождение в те или иные группы (с разделением по правам) и ряд других вещей – все это теперь можно поменять только из домена.
Казалось бы в чем проблема? Ну например в том, что в выходные в неурочное время, я получаю письмо с просьбой скинуть пароль одному из студентов ибо он его забыл. Без интеграции, я просто захожу в панель администратора и меняю. При наличии интеграции…. студент ждет пока я доберусь до работы и вспомню о его письме. При наличии длительных выходных студент может потерять доступ к основному хранилищу информации по учебе, на весь срок. И у него, как минимум, появляется “козырная отмазка”, а по максимуму – проблемы в связи с неуспеваемостью.
Идем далее. Гугл кроме прочего импортирует и группы пользователей. В Active Directory любой пользователь может одновременно входить в различные группы. Так например, я вхожу в группы “admins”, “preps”, “eng”. В соответствии с этими группами приходят не только права на доступ к определенным ресурсам (в этом случае “admins” было бы достаточно), но и определенные настройки, как например сетевые диски на которые повешены определенные сетевые ресурсы.
В то же время в Google пользователь может принадлежать только одной конкретной группе, или подгруппе. В связи с чем надо наманьячить и в AD группы так, чтобы каждый пользователь принадлежал только одной. Ну как-то не слишком удобно. Кстати вот эта невозможность пользователя одновременно принадлежать нескольким группам в гугле сильно утомляет.
Идем далее. В том же гугле, для большей простоты администрирования одногруппников всех поместили в отдельные группы. Так проще назначать в гугле права (например для младших групп отключить гугл+ в соответствии с требованиями политики гугла), доступ к определенным ресурсам (форумам - гуглогруппам). Но вот беда, в рамках домена в таком разделении нет нужды.
Далее. С пользователями тоже получается интересная вещь. Например в домене, у нас существуют тестовые пользователи, соответствующие или конкретной группе, или их набору, для того чтобы тестировать доступность ресурсов. В гуглоапсе они не сильно нужны. В то же время, в последнем есть свои “лишние” пользователи. Например пользователь которому падают сообщения с кафедрального сайта, “пользователи” введенные для служебных целей, а именно для хранения лекций от преподавателей, информации по программным продуктам, аккаунт “студактива” и пр.
Таким образом получается, что добиться полного соответствия не то чтобы невозможно, но можно через дополнительные действия по осмыслению и настройке.
В итоге получилось три проблемы, которые несколько мешают, в нашем восприятии, движению в сторону интеграции.
Ну и последнее. В хелпе гуглоаппсов написано, что не смотря на то, что связь вроде как односторонняя, могут возникать ситуации, когда на гугле и в домене информация будет изменена по отдельности не смотря на все настройки. И указано, что это может привести к существенным проблемам.
Ну а раз так то мы пока отложили этот пункт до лучших времен. Ну а Вы уже решайте для себя.
Комментариев нет:
Отправить комментарий