Google Apps、AD、SSO
私たちは、メールのニーズに応えるためにGoogle Apps（Enterprise）を実行している小さなショップです。大好きです。内部的には、Windows AD（2003）を使用しています。そこにも文句はありません。
ADとGoogle Appsの間でSSOを実行して、パスワードを管理する（そして定期的に変更する）必要があるのはADだけになるようにしたいのですが。
私は過去にグーグルの「tfm」を見てきましたが、私はそれをまったく理解していないと思います。誰かこれをしましたか？もしそうなら、あなたはどのようにして喜んで共有しますか？膨大な複雑さと費用をかけずにそれを行うことができますか？
Google Appsでできることはいくつかあります。
ADネットワークに接続された [〜＃〜] saml [〜＃〜] サーバーをセットアップし、SAMLサーバーに対するGoogle Appsアクセスを認証するようにGoogleをセットアップできます。 simpleSAMLphp と呼ばれるphpアプリケーションを使用しました。これは、PHPを実行するためのサーバー設定がすでにあり、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について興奮していた。それはウィンドウズモバイルとブラックベリークライアントを使用しているすべての人々を殺すでしょうね？そこで賢い選択肢はありますか？
パスワードハッシュを保存するリスクを受け入れる場合は、SSOとディレクトリの同期を組み合わせて、正常に機能するシステムを取得できます。
別の方法として、ドメイン内のユーザーが自分のGoogleアカウントを初期化し、Googleアカウントのパスワードを設定するイントラネットポータルを誰かが開発する可能性があります。私はこのようなものを開発することを考えていましたが、それが進むべき道であることを同僚に同意させることができませんでした。
基本的な考え方はこれです。
- イントラネット上に存在し、Active Directoryに対して認証します
- ユーザーがイントラネットサイトへのログインに使用したユーザー名とパスワードを取得し、ADから必要なその他の情報を取得して、Google Provisioning APIを使用してユーザーアカウントを追加/更新する機能があります。
ツールの構築はそれほど難しくはないはずです。開発に12〜16時間しかかからないような基本的なものをハックアウトすると推定していました。このソリューションの利点は、Google Appsの機能が100％提供されることです。欠点は、エンドユーザーにとって多少不便です。
私もこれに対するより良い答えを見たいです。
Google Apps Directory Sync をいじって、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）に認証情報をシードする新しいログインリンクを取得しました。これで完了です。
このような構成を稼働させることは非常に複雑であり、コストもかかる可能性があるため、すべての組織に適しているわけではないことに注意してください。
Active Directoryの同期と組み合わせて使用するパスワードを同期するための Google Apps Password Sync（GAPS） があるようです。しかし、私はまだそれを使用していません。