Google Apps, AD та SSO

Ми невеликий магазин, який працює з Google Apps (Enterprise) для наших електронних запитів. Любіть це. Всередині ми використовуємо Windows AD (2003). Ніяких скарг також немає.

Я хотів би, щоб якийсь метод SSO переходив між AD і Google Apps таким чином, що AD - це єдине місце, де мої люди мають керувати (і періодично змінювати паролі).

Я переглядав "tfm" google у минулому, але, мабуть, просто не знаю. Хтось це робить? Якщо так, чи готові ви поділитися тим, як? Чи можна це зробити без величезної суми складності та витрат?

Є кілька речей, які ви можете зробити з Google Apps.

Ви можете налаштувати сервер SAML, підключений до вашої мережі AD, а потім налаштувати Google для аутентифікації вашого доступу до Google Apps на сервері SAML. Ми використовували додаток php під назвою simpleSAMLphp, оскільки у нас вже є налаштування серверів для запуску PHP і у нас є розробники з навичками php. Недолік використання лише рішення SAML полягає в тому, що ви можете входити в облікові записи лише через Інтернет. Це означає, що ви не можете отримати доступ до своєї поштової скриньки через Imap / pop, і ви не можете увійти в Google, щоб поговорити зі старим клієнтом XMPP.

Використання SAML не створює автоматично облікові записи в домені Google Apps. Можливо, вам також знадобиться інструмент, який буде синхронізувати облікові записи, для яких ви можете використовувати Каталог Google Apps інструмент синхронізації . Це дозволить вам створювати облікові записи, але він все одно не буде синхронізувати паролі за замовчуванням, оскільки хеші паролів Windows не є оборотними і Google не може нічого з ними робити.

Можна використовувати щось на кшталт PasswdHk для перехоплення змін пароля у вашій AD та зберігати пароль у форматі (несолоне sha1), яке утиліта синхронізації каталогу Google може використовувати для встановлення паролів Google Apps. Але це додає певного ризику для безпеки, оскільки Google прийме несолоні хеші паролів md5 або sha1 через API надання послуг , і щоб синхронізуватися з Google, ви в основному повинні зберігати ці хеші. Якщо ви користуєтеся цим, дуже важливо зберегти ці хеши в безпеці.

Хммф. Ти мене всіх схвилював про SAML до тих пір, поки не піде про іміп / поп. Це вбило б усіх людей за допомогою клієнтів Windows Mobile та blackberry, чи не так? Будь-які розумні альтернативи там?

Якщо ви готові прийняти ризик зберігання хешей паролів, тоді зможете об'єднати SSO та каталогізацію каталогів разом, щоб отримати робочу систему.

Як альтернатива, хтось може розробити портал Інтранет, куди користувачі вашого домену будуть ініціалізувати свій обліковий запис Google і встановити пароль для облікового запису Google. Я думав розробити щось подібне, але не зміг змусити своїх колег погодитись, що це шлях.

Основна ідея така: побудувати webapp що

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

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

Я теж хотів би побачити кращу відповідь на цю.

Я грав разом із синхронізацією каталогів Google Apps, щоб синхронізувати користувачів Google із користувачами Active Directory. Це виглядало набрякло, аж до моменту, коли я прочитав, що реалізація LDAP AD зберігає пароль у зашифрованому бінарному полі, до якого інструмент Sync Sync не може отримати доступ.

Інше рішення Google SSO, схоже, перетворює таблиці, так що Google є авторитетним джерелом даних. Нас це не цікавить; що буде з нашою локальною мережею, якщо наш доступ до Інтернету не працює?

Тож зараз найкращим моїм рішенням є електронна таблиця Google Apps із іменами користувачів та паролями, які ми експортуємо в CSV та масовим імпортом у Google Apps . Це не обробляє зміни пароля. Наразі найкраще, що ми маємо, - це навчити наших користувачів змінювати і пароль Google, і Windows на той самий новий пароль, коли політика щодо паролів Windows примушує зміни.

Ось фільтр паролів, який зберігає хеш в рекламі. http://code.google.com/p/sha1hexfltr/ Це надійно зберігає хеші в рекламі. Не потрібна SSO, нові сервери не потрібні!

Гм, ніхто не робить щось на 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 (GAPS) для синхронізації паролів, які використовуються в поєднанні з активною синхронізацією каталогів. Але я ще цього не використовував.