Google Apps, AD i logowanie jednokrotne

Jesteśmy małym sklepem z Google Apps (Enterprise) na potrzeby naszych e-maili. Kocham to. Wewnętrznie korzystamy z Windows AD (2003). Nie ma też żadnych skarg.

Chciałbym uzyskać metodę logowania jednokrotnego między AD a Google Apps, dzięki czemu AD jest jedynym miejscem, w którym moi ludzie muszą zarządzać (i okresowo ZMIENIAĆ!) Hasłami.

Przeglądałem „tfm” google w przeszłości, ale myślę, że po prostu tego nie rozumiem. Czy ktoś to robi? Jeśli tak, czy chciałbyś podzielić się tym, jak? Czy można to zrobić bez ogromnej złożoności i kosztów?

Istnieje kilka rzeczy, które możesz zrobić z Google Apps.

Możesz skonfigurować serwer SAML podłączony do sieci AD, a następnie skonfigurować Google do uwierzytelniania dostępu Google Apps do serwera SAML. Użyliśmy aplikacji php o nazwie simpleSAMLphp, ponieważ mamy już skonfigurowane serwery do uruchamiania PHP i mamy programistów z umiejętnościami php. Wadą używania samego rozwiązania SAML jest to, że można logować się tylko na konta przez Internet. Oznacza to, że nie możesz uzyskać dostępu do swojej skrzynki pocztowej za pomocą imap / pop i nie możesz zalogować się do Google Talk za pomocą dowolnego starego klienta XMPP.

Korzystanie z SAML nie powoduje automatycznego tworzenia kont w domenie Google Apps. Prawdopodobnie będziesz także potrzebować narzędzia, które zsynchronizuje konta, aby móc korzystać z narzędzia do synchronizacji katalogu Google Apps . Umożliwi to tworzenie kont, ale nadal nie będzie domyślnie synchronizować haseł, ponieważ skróty haseł do systemu Windows nie są odwracalne i Google nie może z nimi nic zrobić.

Możliwe jest użycie czegoś takiego jak PasswdHk, aby przechwycić zmiany hasła w AD, a następnie przechowywać hasło w formacie (niesolony sha1), którego narzędzie do synchronizacji katalogów Google może użyć do ustawienia haseł Google Apps. To jednak stanowi dodatkowe ryzyko związane z bezpieczeństwem, ponieważ Google akceptuje tylko niesolone skróty hasła md5 lub sha1 za pośrednictwem interfejsu API do obsługi administracyjnej , a aby zsynchronizować się z Google, zasadniczo musisz przechowywać te skróty. Jeśli chcesz tego użyć, bardzo ważne jest, aby zapewnić bezpieczeństwo tych skrótów.

Hmmph. Podekscytowałeś mnie wszystkim SAML, aż trochę o imap / pop. To zabiłoby wszystkich ludzi korzystających z Windows Mobile i BlackBerry, prawda? Jakieś sprytne alternatywy?

Jeśli chcesz zaakceptować ryzyko przechowywania skrótów haseł, możesz połączyć SSO i katalog synchronizując się, aby uzyskać działający system.

Alternatywnie ktoś mógłby stworzyć portal intranetowy, w którym użytkownicy w Twojej domenie poszliby zainicjować swoje konto Google i ustawić hasło do konta Google. Zastanawiałem się nad stworzeniem czegoś takiego, ale nie mogłem zmusić współpracowników, by zgodzili się, że to była właściwa droga.

Podstawową ideą jest zbudowanie aplikacji internetowej

• Mieszka w intranecie i uwierzytelnia się w stosunku do twojego active directory
• Ma funkcję, która pobierze nazwę użytkownika i hasło, których użył użytkownik, aby zalogować się do witryny intranetowej i uzyskać wszelkie inne potrzebne informacje z AD, a następnie użyć interfejsu API Google Provisioning do dodania / zaktualizowania konta użytkowników.

Zbudowanie narzędzia naprawdę nie powinno być zbyt trudne, oszacowałem, że zhakuję coś podstawowego, zajmie to tylko 12-16 godzin czasu programowania. Zaletą tego rozwiązania jest to, że daje ono 100% funkcjonalność Google Apps, wadą jest to, że nieco utrudnia użytkownikowi końcowemu.

Ja również chciałbym zobaczyć lepszą odpowiedź na to pytanie.

Bawiłem się z Google Apps Directory Sync, aby synchronizować użytkowników Google z użytkownikami Active Directory. Wyglądało to pęczniejąco, aż do momentu, w którym przeczytałem, że implementacja LDAP AD utrzymuje hasło w zaszyfrowanym polu binarnym, do którego narzędzie Google Sync nie ma dostępu.

Inne rozwiązanie logowania jednokrotnego Google wydaje się przewracać tabele, dzięki czemu Google jest wiarygodnym źródłem poświadczeń. Nie interesuje nas to; co stałoby się w naszej sieci LAN, gdyby dostęp do Internetu był wyłączony?

Tak więc teraz moim najlepszym rozwiązaniem jest arkusz kalkulacyjny Google Apps z nazwami użytkowników i hasłami, które następnie eksportujemy do pliku CSV i importujemy zbiorczo do Google Apps . To nie obsługuje zmian hasła. Jak dotąd najlepiej, aby edukować naszych użytkowników, aby zmieniali zarówno hasło Google, jak i Windows na to samo nowe hasło, gdy zasady haseł Windows wymuszą zmianę.

Oto filtr haseł, który przechowuje skrót w reklamie. http://code.google.com/p/sha1hexfltr/ Bezpiecznie zapisuje skróty w reklamie. Nie jest wymagane jednokrotne logowanie, nie są potrzebne nowe serwery!

Hmm, nikt nie robi SSO? Przyznaję, że jestem trochę zaskoczony!

Tylko po to, żeby wszystko zaczęło się kręcić: PingConnect zaproponował mi inne kanały. Ktoś go wykorzystał?

Możesz użyć do tego LemonLDAP :: NG. Zobacz http://lemonldap-ng.org/documentation/latest/applications/googleapps

Niektóre produkty, takie jak Oracle Internet Directory + Oracle SSO (i IBM TIM / TAM), umożliwiają podłączenie do systemów innych firm. Oznacza to, że produkt jest skonfigurowany do synchronizacji z AD i przechowuje dane uwierzytelniające do każdego innego produktu, jaki kiedykolwiek sobie wyobrażasz. Otrzymasz nowy link logowania, który zapełnia poświadczenia systemu, który chcesz (w tym przypadku - Google Apps) i to wszystko.

Pamiętaj, że uruchomienie takiej konfiguracji jest dość skomplikowane i może również kosztować trochę pieniędzy, więc nie pasuje do każdej organizacji.

Wygląda na to, że istnieje Google Apps Password Sync (GAPS) do synchronizacji haseł do użycia w połączeniu z synchronizacją Active Directory. Ale jeszcze go nie użyłem.