Google Apps、ADおよびSSO

私たちは、メールのニーズに合わせてGoogle Apps（Enterprise）を実行している小さな店です。大好きです。内部的には、Windows AD（2003）を使用しています。苦情もありません。

ADとGoogle Appsの間でSSOを行う方法を取得して、ADがパスワードを管理（および定期的に変更）する必要がある唯一の場所にするようにします。

私は過去にグーグルの「tfm」を見てきましたが、私はそれをまったく理解していないと思います。誰もこれをしていますか？もしそうなら、あなたはどのように共有したいと思いますか？膨大な複雑さと費用をかけずにそれを行うことができますか？

Google Appsでできることはいくつかあります。

ADネットワークに接続されたSAMLサーバーをセットアップし、SAMLサーバーに対してGoogle Appsアクセスを認証するようにGoogleをセットアップできます。PHPを実行するサーバーが既にセットアップされており、PHPスキルを持つ開発者がいるため、simpleSAMLphpというphpアプリケーションを使用しました。SAMLソリューションを単独で使用する場合の欠点は、Webを介してのみアカウントにログインできることです。これは、imap / popを介してメールボックスにアクセスできず、古いXMPPクライアントを使用してGoogleトークにログインできないことを意味します。

SAMLを使用しても、Google Appsドメインにアカウントは自動的に作成されません。また、おそらくGoogle Apps Directory同期ツールを使用できるように、アカウントを同期するツールが必要になります。これにより、アカウントを作成できるようになりますが、Windowsパスワードハッシュは元に戻せず、Googleはアカウントで何もできないため、デフォルトではパスワードを同期しません。

PasswdHkのようなものを使用してADのパスワード変更をインターセプトし、Googleディレクトリ同期ユーティリティがGoogle Appsパスワードの設定に使用できる形式（無塩sha1）でパスワードを保存することができます。ただし、GoogleはProvisioning APIを介して無塩のmd5またはsha1パスワードハッシュのみを受け入れ、Googleと同期するには基本的にこれらのハッシュを保存する必要があるため、これは少しのセキュリティリスクを追加します。これを使用する場合、これらのハッシュを安全に保つことが非常に重要です。

ふむ imap / popについて少し話をするまで、SAMLに興奮していた。これは、Windows MobileとBlackberryクライアントを使用しているすべての人を殺すでしょう。巧妙な選択肢はありますか？

パスワードハッシュを保存するリスクを受け入れる場合は、SSOとディレクトリ同期を組み合わせて、稼働中のシステムを取得できます。

別の方法として、ドメイン内のユーザーがGoogleアカウントを初期化し、Googleアカウントのパスワードを設定するイントラネットポータルを開発できます。私はこのようなものを開発することを検討していましたが、それが進むべき道であることに私の同僚に同意させることができませんでした。

基本的な考え方はこれです、ウェブアプリを構築します

• イントラネット上に存在し、アクティブディレクトリに対して認証します
• ユーザーがイントラネットサイトへのログインに使用したユーザー名とパスワードを取得し、ADから必要な他の情報を取得し、Google Provisioning APIを使用してユーザーアカウントを追加/更新する機能を備えています。

このツールの構築はそれほど難しくないはずです。12〜16時間の開発時間しかかからない基本的なものをハックするつもりでした。このソリューションの利点は、Google Appsの機能を100％提供できることです。欠点は、エンドユーザーに多少不便をかけることです。

私もこれに対するより良い答えを見たいです。

遊んだ Google Appsのディレクトリ同期のActive Directoryユーザーから、Googleのユーザーを同期します。ADのLDAP実装がパスワードを暗号化されたバイナリフィールドに保持し、Googleの同期ツールがアクセスできないことを読んだところまで、それは大きく見えました。

Googleの 他のSSOソリューションは表を変えたように見えるので、Googleは認証情報の信頼できるソースです。興味はありません。インターネットアクセスがダウンした場合、LANで何が起こりますか？

そのため、現時点での最良のソリューションは、ユーザー名とパスワードを含むGoogle Appsスプレッドシートです。これをCSVにエクスポートし、Google Appsに一括インポートします。これはパスワードの変更を処理しません。これまでの最善策は、Windowsパスワードポリシーが変更を強制する場合に、Googleと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）は、Active Directoryの同期と組み合わせて使用するパスワードを同期させるため。しかし、私はまだ使用していません。