Назад | Перейти на главную страницу

Google Apps, AD и SSO

Мы - небольшой магазин с Google Apps (Enterprise) для работы с электронной почтой. Любить это. Внутри мы используем Windows AD (2003). Нареканий там тоже нет.

Я хотел бы получить какой-то метод единого входа между AD и Google Apps, чтобы AD была единственным местом, где мои люди могли управлять паролями (и периодически МЕНЯТЬ!).

Раньше я просматривал "tfm" Google, но, думаю, я просто не совсем понял. Кто-нибудь этим занимается? Если да, не могли бы вы поделиться, как? Можно ли это сделать без огромных сложностей и затрат?

С Google Apps можно сделать несколько вещей.

Вы можете настроить SAML сервер, подключенный к вашей сети AD, а затем настройте Google для аутентификации доступа к Google Apps на сервере SAML. Мы использовали приложение php под названием simpleSAMLphp потому что у нас уже есть серверы, настроенные для запуска PHP, и у нас есть разработчики с навыками php. Недостатком использования только решения SAML является то, что вы можете входить в учетные записи только через Интернет. Это означает, что вы не можете получить доступ к своему почтовому ящику через imap / pop, и вы не можете войти в Google Talk с любым старым клиентом XMPP.

Использование SAML не приводит к автоматическому созданию аккаунтов в домене Google Apps. Вам также, вероятно, понадобится инструмент, который будет синхронизировать учетные записи, для которого вы можете использовать Каталог Google Apps инструмент синхронизации. Это позволит вам создавать учетные записи, но по-прежнему не будет синхронизировать пароли по умолчанию, потому что хэши паролей Windows необратимы, и Google ничего не может с ними сделать.

Можно использовать что-то вроде PasswdHk для перехвата изменений пароля в вашем AD и последующего сохранения пароля в формате (без соли sha1), который утилита синхронизации каталогов Google может использовать для установки паролей Google Apps. Но это добавляет небольшой риск безопасности, поскольку Google будет принимать только несоленые хэши паролей md5 или sha1 через свои Provisioning API, а для синхронизации с Google вы должны хранить эти хэши. Если вы собираетесь использовать это, очень важно сохранить эти хэши в безопасности.

Хммм. Вы меня очень волновали по поводу SAML, вплоть до imap / pop. Это убило бы всех, кто пользуется клиентами Windows Mobile и Blackberry, не так ли? Есть какие-нибудь умные альтернативы?

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

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

Основная идея заключается в том, чтобы создать веб-приложение, которое

  • Живет в вашей интрасети и аутентифицируется по вашему активному каталогу
  • Имеет функцию, которая будет принимать имя пользователя и пароль, которые пользователь использовал для входа на сайт интрасети, и получать любую другую информацию, которая вам нужна, из AD, а затем использовать Google Provisioning API для добавления / обновления учетной записи пользователя.

Создание инструмента на самом деле не должно быть слишком сложным, я подсчитал, что для создания чего-то базового потребуется всего 12-16 часов времени разработки. Преимущество этого решения в том, что оно дает вам 100% функциональность Google Apps, недостатком является то, что это несколько неудобно для конечного пользователя.

Вот фильтр паролей, который хранит хеш в объявлении. http://code.google.com/p/sha1hexfltr/ Он надежно сохраняет хеши в объявлении. Не требуется SSO, не нужны новые серверы!

Я тоже хотел бы увидеть лучший ответ на этот вопрос.

Я играл с Google Apps Directory Sync для синхронизации пользователей Google с пользователями Active Directory. Это выглядело великолепно, вплоть до того момента, когда я прочитал, что реализация LDAP AD хранит пароль в зашифрованном двоичном поле, к которому инструмент Google Sync не может получить доступ.

Google другое решение SSO похоже, меняет положение дел, так что Google является авторитетным источником учетных данных. Нас это не интересует; что произойдет в нашей локальной сети, если у нас отключится доступ в Интернет?

Итак, сейчас моим лучшим решением является электронная таблица Google Apps с именами пользователей и паролями, которую мы затем экспортируем в CSV, и массовый импорт в Google Apps. Это не обрабатывает изменения пароля. На данный момент лучшее, что у нас есть, - это научить наших пользователей менять пароли Google и Windows на один и тот же новый пароль, когда политика паролей Windows требует изменения.

Хм, никто не занимается SSO? Признаюсь, я немного удивлен!

Просто для начала: у меня было PingConnect предлагается через другие каналы. Кто-нибудь использовал это?

Для этого вы можете использовать LemonLDAP :: NG. Видеть http://lemonldap-ng.org/documentation/latest/applications/googleapps

Некоторые продукты, такие как Oracle Internet Directory + Oracle SSO (и IBM TIM / TAM), позволяют подключаться к сторонним системам. Это означает, что продукт настроен для синхронизации с AD и сохраняет учетные данные для всех других продуктов, которые вы когда-либо представляли. Вы получаете новую ссылку для входа, которая вводит учетные данные в нужную систему (в данном случае - в Google Apps), и все.

Имейте в виду, что получить такую ​​конфигурацию и запустить ее довольно сложно, а также может стоить вам немного денег, поэтому она подходит не для каждой организации.

Похоже, есть Google Apps Password Sync (GAPS) для синхронизации паролей, которые будут использоваться в сочетании с синхронизацией активного каталога. Но пока не пользовался.