とりあえずドメイン所有権の確認を行います。
いくつか方法が用意されてるんだけど、DNSにTXTレコードを追加する方法で対応した。
該当するドメインのゾーンファイルに、Google Appsで指定されるTXTレコードを追加する。
IN TXT google-site-verification=hogehogehogehogehogehogehogehogehogehogehog
DNSサーバーを再起動。
シリアル番号の更新も忘れずに。
確認。
手元にあるのがWindowsだったら
nslookup - ns1.hoge.co.jp ←DNSサーバー名
>set q=TXT
>hoge.co.jp
dig使えるなら
$ dig @ns1.hoge.co.jp hoge.co.jp TXT
みたいな感じで、登録したTXTレコードが出てくればおk。
Google Appsのドメイン管理画面でドメイン所有権の確認を続ける。
多分数分もすれば確認できる。DNSの浸透には長いと数週間~とか言う奴がいるけど浸透ってなんなの?相性で済ましちゃうPCユーザーみたいなもんじゃないの?しらんけど。
ドメイン所有権の確認ができればGmailの機能が使えるようになります。
つぎにGoogle Appsでアカウントを作りまくる。CSVでぶち込んでやると早い。
アカウントの用意ができたら、
本稼働中のメールサーバーから Google Appsテスト用ドメイン(hoge.co.jp.test-google-a.com みたいな感じで用意される)にメールを転送を開始。
これで、本稼働中のサーバーとGmailに同じメールが届くようにしてしまおう。
こうなってしまえばもうGoogle Appsをメインに使ってもなんの支障もない。
ユーザー全員を一気に乗り換えさせると管理してる人の手間が大変なので、段階的にユーザーのメール環境をGoogle Appsに変更させていく。
サポート分散しないとウン十人分のPC設定とGoogle Appsの説明なんて無理。
そんな感じで現在半数をGoogle Appsに移行完了。もう少しダブル運用で挙動チェック予定。
Google Apps。
実際に使う前にもっと調べときゃよかった。
今までサーバー製品とグループウェアを売ってきた業者達からもGoogle Appsを売り込んでもらうために、標準状態ではセキュリティーポリシーの設定も糞もあったもんじゃない投げっぱなしな状態。
便利にできるAPIを用意してるからどんどん作ってそれをオプションとして売り込んでね!!!っていうものなんだな。
ドキュメントを読む限りSingle Sign-On環境程度なら僕でも作れそうな感触はあったけど、そんな保守なんてしたくないし責任を負いたくないからアウトソーシング化を進めているのにそんなことをしてしまったら本末転倒すぎて死ぬ。
セキュリティーポリシーをまじめに考えるのなら予算を作ってもらうしか…。
何社かに見積もりをとったところ、多くを望まなければそんなに高くないようだけど利便性が死ぬからよく考える必要がありそう。
わかりきってたことだけど安全と利便性は両立しないね。
ちなみにMXレコードの編集はまだです。
優先順位を落として、本稼働中のメールサーバーと併記するってのも可能だけど、
MXレコードの優先順位なんてあまりアテにならなくない?そうなると2つの環境に全く同じようにメールが届く環境を作るのはむしろ難しくなる。
少なくともスパマーどもは、わざと優先順位の低いMXレコードを辿ってメール放りこんできたりするからタチが悪い。
いくつか方法が用意されてるんだけど、DNSにTXTレコードを追加する方法で対応した。
該当するドメインのゾーンファイルに、Google Appsで指定されるTXTレコードを追加する。
IN TXT google-site-verification=hogehogehogehogehogehogehogehogehogehogehog
DNSサーバーを再起動。
シリアル番号の更新も忘れずに。
確認。
手元にあるのがWindowsだったら
nslookup - ns1.hoge.co.jp ←DNSサーバー名
>set q=TXT
>hoge.co.jp
dig使えるなら
$ dig @ns1.hoge.co.jp hoge.co.jp TXT
みたいな感じで、登録したTXTレコードが出てくればおk。
Google Appsのドメイン管理画面でドメイン所有権の確認を続ける。
多分数分もすれば確認できる。DNSの浸透には長いと数週間~とか言う奴がいるけど浸透ってなんなの?相性で済ましちゃうPCユーザーみたいなもんじゃないの?しらんけど。
ドメイン所有権の確認ができればGmailの機能が使えるようになります。
つぎにGoogle Appsでアカウントを作りまくる。CSVでぶち込んでやると早い。
アカウントの用意ができたら、
本稼働中のメールサーバーから Google Appsテスト用ドメイン(hoge.co.jp.test-google-a.com みたいな感じで用意される)にメールを転送を開始。
これで、本稼働中のサーバーとGmailに同じメールが届くようにしてしまおう。
こうなってしまえばもうGoogle Appsをメインに使ってもなんの支障もない。
ユーザー全員を一気に乗り換えさせると管理してる人の手間が大変なので、段階的にユーザーのメール環境をGoogle Appsに変更させていく。
サポート分散しないとウン十人分のPC設定とGoogle Appsの説明なんて無理。
そんな感じで現在半数をGoogle Appsに移行完了。もう少しダブル運用で挙動チェック予定。
Google Apps。
実際に使う前にもっと調べときゃよかった。
今までサーバー製品とグループウェアを売ってきた業者達からもGoogle Appsを売り込んでもらうために、標準状態ではセキュリティーポリシーの設定も糞もあったもんじゃない投げっぱなしな状態。
便利にできるAPIを用意してるからどんどん作ってそれをオプションとして売り込んでね!!!っていうものなんだな。
ドキュメントを読む限りSingle Sign-On環境程度なら僕でも作れそうな感触はあったけど、そんな保守なんてしたくないし責任を負いたくないからアウトソーシング化を進めているのにそんなことをしてしまったら本末転倒すぎて死ぬ。
セキュリティーポリシーをまじめに考えるのなら予算を作ってもらうしか…。
何社かに見積もりをとったところ、多くを望まなければそんなに高くないようだけど利便性が死ぬからよく考える必要がありそう。
わかりきってたことだけど安全と利便性は両立しないね。
ちなみにMXレコードの編集はまだです。
優先順位を落として、本稼働中のメールサーバーと併記するってのも可能だけど、
MXレコードの優先順位なんてあまりアテにならなくない?そうなると2つの環境に全く同じようにメールが届く環境を作るのはむしろ難しくなる。
少なくともスパマーどもは、わざと優先順位の低いMXレコードを辿ってメール放りこんできたりするからタチが悪い。
