Category Archives: Work

ADFSをSSLオフロード環境で利用する

Posted on by • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • Leave a comment

AD FSですが、MSの提供しているAD FS 2.0 Capacity Planning Spreadsheetなどを参考にサイジングしてみると、比較的とCPU食わなそうに見えるのですが、実際に動作を見てみると意外に新規トランザクション数が伸びない印象を受けます。

ということで、少しでも負荷を軽減できるようにSSLのオフロード（LBでSSLを終端）をするときの処理を考えてみます。本当はiRulesまで作ろうかと思ったのですが、まだ需要が無かったのでとりあえずサーバ側のみで。

Office365のようなパッシブフェデレーションの場合、https://sts.example.com/adfs/ls…などにリダイレクトされます。AD FSサーバのIISを見てみると同じフォルダツリーの中に入っているので、そのままでも動くかなと思い、とりあえず以前の投稿で書いた無理矢理SSO用のurlをhttps⇒httpに変更してアクセスを試みます。

403エラーが表示されます。何となくIISの設定のみで行けそうなので、サーバマネージャのIISを開き、ADFSの実態で有る/adfs/lsの[SSL設定]を開いて確認してみると、[SSLが必要]にチェックボックスが入っています。

このチェックを外して再度アクセスを試みると、無事アクセスできました。

あと、SSLオフロードをする際は、代理で接続に来るLBなりの仕様に応じて（おそらく対応してないでしょうが）IIS側でWindows認証の拡張保護を無効化する必要があるかもしれません。（この辺を参考に）

Exchange Onlineでのメール転送

Posted on by • Posted in Exchange Online, Work • Tagged • Leave a comment

Office365で利用されているExchange Onlineは、いくつかの方法で着信したメールを他のアドレスに転送をすることができます。

大きく分けて、転送を設定出来るポイントは4つ有ります。

  1. Forefront Online Protection for Exchangeのポリシールール
  2. Exchange Onlineのトランスポートルール
  3. Exchange Onlineのメール転送
  4. Exchange Onlineの受信トレイルール

今回は、これらの4つをいくつかのポイントに焦点を合わせて比較してみたいと思います。

①FOPE Policy ②Transport ③MailForward ④Inbox-Rule
設定可能な人 管理者 管理者（代理設定）
ユーザー
ジャーナルアーカイブ 対象外 対象
受信トレイに残さず転送 可能 不可
Envelope From書き換え 無し 有り
転送系ヘッダ付与 無し 有り（※1） 有り（※2） 有り（※3）
表示名への書き換え 無し 有り（※4）
受信トレイルールの影響 受けない 有り（※5） 
※1: X-OriginatorOrg、X-MS-Exchange-Transport-Rules-Loop
※2: X-OriginatorOrg、X-MS-Exchange-Inbox-Rules-Loop
※3: X-OriginatorOrg、X-MS-Exchange-Inbox-Rules-Loop、Recent-From
※4: Exchangeが自動的に行う変更username@example.com⇒山田太郎<username@example.com>など
※5: ルールの順序により、転送より優先度が高いルールの方が先に処理される

以上のことから、通常は3をベースに条件に応じて使い分けるのが良いかと思われます。

  1. Exchangeに影響無しにメールを転送したい場合
  2. 管理者が保全などの目的で（特定条件を満たす）メールを転送する場合
  3. ユーザ自身が（また、管理者が代理で）携帯などに転送を設定する場合
  4. ユーザが特定の条件に合うメールのみ、条件付き転送を行う場合

設定方法といくつかの注意点をメモ書き程度に

①Forefront Online Protection for Exchangeのメニューから【ポリシールール】でBCCで配信ルールを作成する。

②Exchangeコントロールパネル（組織の管理）の【メールの制御】-【ルール】から新規作成を行う。

③Exchangeコントロールパネルを開き、【アカウント】-【接続されているアカウント】から【電子メールの転送先】を設定する

④Exchangeコントロールパネルを開き、【電子メールの整理】-【受信トレイのルール】でリダイレクトのルールを作成する

  • プランEではなく、プランPの場合はFOPEの管理メニューにアクセス出来ないので①の方式は利用不可
  • Exchange Onlineのみでメール監査を行う場合、①～③でメールボックスに配送せず転送した場合は、対象外となる
  • ①②の「リダイレクト」は④のリダイレクトとは意味が異なり、メールボックスには配送されない。④のリダイレクトを行う場合は「Bccで送信」を利用する。

OWAにシングルサインオンする（その2）

Posted on by • Posted in Exchange Online, Work, シングルサインオンとディレクトリ同期 • Leave a comment

以前 Exchange OnlineにAD FSを利用して気合いでOWAリダイレクトする の記事でOWAへのシングルサインオンを紹介しましたが、より簡単な方法を見つけましたので紹介します。

やり方は簡単で、ブラウザを立ち上げて https://outlook.com/owa/[ドメイン名] にアクセスするだけです。
または、https://www.outlook.com/[ドメイン名] でも良いらしいです。

ADFSサーバのアドレスがイントラネットサイトに入っていないといけないという条件などは他のシングルサインオンと変わりませんが、これにより自動的にそのドメインがフェデレーションドメインとして構成されていれば、ADFSにリダイレクトされて認証され、最終的にOWAの画面が開きます。

と、これだけだと少しつまらないので、ついでにFidder2で通信のシーケンスを追ってみましょう。

Fiddler2 を使用して Office 365 Id フェデレーション ログオン処理をトレースする方法を参考にしつつ、Fidder2をインストールし、セットアップします。HTTPSの中身を見る場合、ADFSサーバ側のIISの設定変更（拡張保護を使用しないようにする）が必要です。

Fidder2を立ち上げ、Decrypt HTTPS trafficにチェックを入れてアクセスを試行してみます。

outlook.com　⇒　login.microsoftonline.com　⇒　[AD FSサーバ]　⇒　login.microsoftonline.com　⇒　outlook.com　⇒　pod51xxx.outlook.com　⇒sinprdxxxx(or hknprdxxxx).outlook.comの流れてリダイレクトされ、無事シングルサインオン出来ていることが確認できました。

もちろん、ログイン後にホームを押すとOffice365のポータルにも行けますし、そこからチームサイト（SharePoint Online）にもSSOできます。

【動画】 Office365にAD FSでシングルサインオンする

Posted on by • Posted in Office365全般, シングルサインオンとディレクトリ同期 • Leave a comment

「Office365はIDを入力する必要があるからシングルサインでは無いって聞いたけど、どうなの？」という話をたまに聞くので、意外とAD FSの環境を実際に触って動きを見た人って少ないのかなと思い、適当にキャプってみました。

ブラウザアクセス（Office365ポータル、Outlook Web Access、SharePoint Online）

少し画質が粗いので、まだ少しましなFacebook動画の方も載せておきます

ADFSサーバのIEのゾーンの設定は自動認識される場合が多いですが、環境によって（例えば、example.localがAD名だった場合で、ユーザアカウントにはexample.comのUPN名を割り当てている場合）イントラネットゾーンとして認識されない場合、プロンプトが表示されてしまいシングルサインオンできませんので、https://sts.example.comなど、明示的に指定することをお勧めします。

また、*.outlook.comなどは無くてもログインはできるのですが、ログアウトの処理が実施できない（サインアウトを押しても元の画面に戻ってきてしまうなど）などの不具合がでることがありますので、「このゾーンには全てサーバの確認（https:）を必要とする」のチェックボックスを外した上でhttp､httpsともに設定できるようプロトコル指定無しで記載します。

 

メーラー（Outlook、Thunderbird:IMAP）

Facebook動画

Lyncクライアント

Facebook動画

Exchange Onlineプラン2を（ちゃんと）活用する

Posted on by • Posted in Exchange Online • Leave a comment

Office365で利用できるExchange Onlineには、プラン1とプラン2が有ります。大きく言うと、メールボックス容量が無制限で監査アーカイブ機能に対応した物がプラン2という括りになります。

プラン1とプラン2は、定価ベースで倍値段が違く、一般的な利用であればプラン1のメールボック容量の制限25GBを越えるというのは難しい為、プラン1で良いように思えますが、

「30日以上の期間を遡ってメールボックスの監査を運用上（もしくは法令上）実施する必要のある」ユーザーにとっては、プラン2を契約するのが一番の（というか唯一の）選択肢になります。もう少しクラウドサービスが出そろえば、プラン1＋クラウドのジャーナルアーカイブなども考えられますが。

というのも、Office365で謳っている「アーカイブ機能」というのは、一般的に言う「ジャーナルアーカイブ」ではなく「個人のメールボックスアーカイブ」になります。つまり、ユーザは自由にメールボックス上にある過去のメールを削除したり変更したりでき、かつ削除したアイテムは14日後にクラウド上から消え去ります。通常メールの監査を行う場合は、短くて半年なり長い場合は3年、5年間にわたり全社員の送受信したメールの記録を取る必要がございますので、ここの保全の機能でプラン2が必要になる訳です。

「高い金出してうちはプラン2を契約しているから監査対応はバッチリです。」

いえいえ、単に契約しただけでは、実際にはプラン1と変わらない状態でデプロイされてますので、プラン2向けの設定をちゃんと入れてあげる必要があります。（デフォルトのポリシー変えてくれれば良いのに…）

とりあえず、やる必要のある工程は、デフォルトの設定を考えると通常の企業だと

  1. 訴訟ホールドもしくは期間限定訴訟ホールドの有効化
  2. アーカイブメールボックスの有効化
  3. メールボックス監査ログの有効化
  4. メールボックス監査ログの有効期限の設定（任意）
  5. 必要なプロトコル以外の無効化（任意）

あたりでしょうか？　このうち1番と2番のみ（2番が容量無制限）はプラン2の機能、3～5はプラン1でもできる物です。また、1番で期間限定訴訟ホールドを実装するには、SRベースで対応をして貰う必要があります。SRだと時間が掛かるのと、ユーザの追加の度に実施するのは少し面倒なので、今回は訴訟ホールドのONでPowerShellで実装します。（1,2はECPからGUIでも実施できます）

$TarMBX = Get-Mailbox -identity user1
$Name = $TarMBX.DisplayName
Enable-Mailbox -identity user1 -Archive
Set-Mailbox -identity user1 -LitigationHoldEnabled $true -AuditEnabled $true -AuditLogAgeLimit 183.00:00:00 -ArchiveName "アーカイブ メールボックス - $Name"
Set-CASMailbox -identity user1 -ActiveSyncEnabled $false -ImapEnabled $false -PopEnabled $false -EwsEnabled $false

実施するコマンドは3つで、それぞれ以下のような感じでやってるサンプルです。

  • Enable-Mailbox…②アーカイブメールボックスの作成
  • Set-Mailbox…①訴訟ホールド有効化、③メールボックス監査ログ有効化、④メールボックス監査ログ期間半年に設定、②アーカイブメールボックス名変更（GUIのデフォルト値に）
  • Set-CASMailbox…⑤MAPI（Outlook）とOWA以外での接続のプロトコルの無効化

とりあえずこの状態にしておけば、あれば何か有っても大丈夫な気がします。強いて言うなら以下の辺を注意でしょうか

  1. ユーザーを削除すると過去のメールボックスごと30日後にクラウド上から情報が消え去る
    ※必要な期間消さないで下さい。もしくは.PSTにダウンロードしてから消して下さい
  2. 管理者監査ログの保持期限が90日なので、それより前の特権利用アクセスの有無の調査ができない
    　※Set-AdminAuditLogConfigコマンドで設定変更できるとマニュアルには記載がありますが、実装されていません

SRVレコード無しの環境でのLyncの利用

Posted on by • Posted in Lync Online • Leave a comment

Office365のLync Onlineでは、DNSのSRVレコードを利用して接続先サーバの情報などをLyncクライアントに渡しています。

この為、Office365を独自ドメインで利用する（プランP）で紹介したようなDNSを外部ホスティングなどの環境を利用して、SRVレコードが設定できない様な場合、以下のようなエラーが出てLyncが使用できません。

心配はいりません。自動ログインができないだけなので、一度だけ手動で設定を入れてあげれば解決します。メニューのツールオプションを開き、個人 – アカウントの詳細設定を開きます。

そこで設定を手動構成として、内部サーバならびに外部サーバの欄に共にsipdir.online.lync.comを入力します。

これで再度サインインを試みると、ユーザ名とパスワードを入力する欄が出ますので、ユーザ名にサインインアドレスと同じ値を、パスワード欄にパスワードを入力します。

これで無事にサインインが完了します。上記設定は保存されてますので、一度設定さえすれば次回以降は問題なく利用出来ます。

【参考】
Lync Online で発生する認証と接続に関する問題のトラブルシューティング

Office365の接続確認ツール（RCA）

Posted on by • Posted in Exchange Online, Office365全般 • Leave a comment

Exchange Remote Connectivity Analyzer(ExRCA)の名前で提供されていたExchangeの接続確認ツールが、バージョンアップしてOffice365に対応しました。

機能追加になったのは、【Microsoft Single Sign-On(BETA)】になります。これによりAD FS環境での外部からの接続確認(要AD FS Proxyです)が実施できます。

IDとパスワードの他、了解事項のチェックボックスと認証用の文字列を入力します。認証文字は大文字小文字は区別しませんが、間違えるとパスワード欄がクリアされてしまって再入力になりますので、UだかVだか分からないとか微妙な文字列だった場合は認証コードの上側のボタンを押して文字列を再生成しましょう。

ちなみに、前に紹介したCOMODOのフリー証明書は、Windows Updateしていないコンピュータだと、ルートCAが信頼済みの証明書ルートに含まれないと警告が表示されますが、動作に問題はありません。

他にも、ActiveSyncやOutlookなどは、クラウドIDでも、AD FS Proxy経由となるフェデレーションIDでも接続確認が可能です。また、受信SMTP電子メールでは実際にメールの送信の試行を行い、MXレコードが正しく構成されているか、メールサーバへのメールの受信ドメインとして受け入れられるかを試験できます。ただし、以下は注意する必要があります。

  • テストの送信元となるIPアドレスは逆引きができないアドレスで、弾かれる可能性があります（65.55.150.160など）
  • MXレコードの応答がCNAMEレコード（Exchangeをはじめ、配送できないMTAが多い）でも試験が成功する

Office365を独自ドメインで利用する（プランP）

Posted on by • Posted in Office365全般 • Tagged • 10 Comments

（2012/2/4更新）メニューのスナップショットを現行の物に変更

Office365は、SOHO、小規模企業向けのプランP（IT スタッフまたは専門家のいない、従業員が 25 人未満の組織）と、中規模企業以上の規模の企業向けのプランEがございます。機能的に一部制約がある（例えば、AD FSは利用できない）などの話は聞いてましたが、どうやら独自ドメインでの運用に大きな違いがあるらしいということで、試用版の環境をお借りして検証を実施してみました。

①まず、管理メニューのドメインからドメインの追加を選択し、ドメイン名を入力します。
　

ドメインの確認方法について表示されますので、プルダウンメニューから一般的な手順を選択すると、認証用のDNSレコード情報が表示されます。
　

Office365で独自ドメインを利用するには所有確認の為の認証が必要となりますが、認証を行うには、ここで表示されるレコード（TXTレコードもしくはMXレコード）を、ユーザが管理しているDNSサーバに設定する必要があります。つまり、ユーザはドメインを取得するだけでなく、そのドメインのレコード情報を設定できるDNSサーバを用意する必要があります。

ここでは、ドメインの登録事業者の中で、無料でDNSホスティングを提供してくれていて、かつTXTレコードにも対応しているGMO Internetさんのお名前.comを利用してドメインを設定してみたいと思います。新規で取得したドメインという設定ですが、既存の場合にも適用できるようにいくつか工程を挟んでいきます。

②お名前.comにログオンした後に、ドメイン編集メニューからレンタルDNSレコード設定をクリックします。複数ドメインを管理されている場合は、Office365で利用したい独自ドメイン名を選択し、入力画面へ進むをクリックします。
　

ホスト名は空欄のまま、TYPEに【TXT】を、VALUEに【MS=msxxxxxxx】と上記で出ていた認証用のDNSレコードの値を入力し、追加をクリックします。レコード追加の項目に正しい値が入力されていることを確認し、下の【レンタルDNSレコード設定用ネームサーバ設定確認】のチェックボックスが入っていることを確認し、確認画面へ進むをクリックし、確認するをクリックします。
　

確認画面の後に、DNSレコードが登録されます。
　

ここで、登録が終わったと思ってすぐにOffice365の認証を行ってはいけません。実際に、私はここで急いでクリックをしてしまった結果、認証に24時間掛かってしまいました。というのも、画面では処理が完了したと出ていますが、実施をしている処理は実際には数分時間を要している様です。③GMO側で処理が終わると、数分後に完了通知のメールが来ます。nslookupコマンドで登録したレコードが確認できます。

重要な工程として、裏で同時にネームサーバの切り替え（DNSホスティング無し:ns1.onamae.com→DNSホスティング有り:01.dnsv.jp）が実施されているのですが、ここが失敗すると時間が掛かるポイントです。例えば今回の場合でいう365poc.infoのTXTレコード検索ですが、先に365poc.infoのDNSサーバがどこかが検索され、その情報が1日間キャッシュされます。つまり、切り替え前のns1.onamae.comに聞きに行ったことのあるサーバは、その後1日間は01.dnsv.jpに切り替わったことに気がつかずにns1.onamae.comにTXTレコードの値を検索に行き続けます。これは事前に設定でどうこうなる問題ではないので、この事態に陥ったらあきらめましょう。

もちろん、通常はOffice365で使うDNSで、初めて使うドメイン名のNSレコードの情報がキャッシュされていることはあり得ないので、正しく他の端末から検索が可能な状態になっていれば、失敗せずに行けるはずです。
　

C:> nslookup -type=ns example.com
C:> nslookup -type=txt example.com

④DNSが引けるようになったら、晴れて認証画面の方に戻り、確認ボタンをクリックすると、ドメイン名が認証されてOffice365で利用できるようになります。

さて、プランPではここで見慣れない処理の指示が表示されます。
「ドメインのレジストラの設定でネームサーバの設定をMicrosoftの指定のDNSに向けて下さい」

えっ？だってそうしたら今まで入れていたWebサーバ用のAレコードとか、DNSサーバ用のNSレコードとかはどうするの！？　いえいえ、心配有りません。Office365はそれら全ての機能を持っています。会社のオフィシャルホームページも移して来れますので、DNSサーバを切り替えるついでに、それ以外のホスティングとか全部解約してきて下さい。

…いえ、すいません、そんなことはありません。MicrosoftのDNSでも、ちゃんとホームページ用のAレコードなどは追加出来ますので、ご自身の環境向けにカスタマイズして下さい。⑤指示は無視してキャンセルし、管理メニューのドメインから独自ドメインのプロパティの表示を選び、DNSマネージャーを選択します。ちなみにこのメニューはプランPにしかありません。
 　

⑥現在のレコードが表示されてます。最初はOffice365で利用するDNS情報のみ表示されておりますので、⑦ホームページなどを既に外部で持っている場合はそのホストのAレコード（wwwや＠）を追加します。これで、メールの切り替えが完了したら、いつの間にか会社のホームページが見れなくなっていたなどの事象は解消できます。
　

DNSの切り替えを実施する場合、原則は移行先の新しいDNSサーバで古いサーバと同じ情報を投入してから切り替えを実施するのが定石です。なぜなら、レジストラ側で保持しているネームサーバの設定は、軒並み長めのTTLが設定されていることが多く、脅し文句では無く普通にインターネット上の情報が全て切り替わるまで1～数日かかります。ここはローカルのDNSサーバの設定では制御出来ない部分なので、移行期間は新旧どちらのサーバに見に来ても同じ動作になるように設定をします。

2011/7/19現在　digコマンドで調べたネームサーバのTTL（キャッシュ期間）
.com/.net : 2日
.org/.info/co.jp/or.jp/.me/.nu/.to : 1日
.biz : 2時間

まあ、普通のホストのレコードの変更や追加などとは違って、通常は切り替えることはほとんど実施しないので、発生頻度からすると変では無い事なのですが、この状態の中いきなり切り替えを勧めてくる（しかも、移行に必要なOffice365側の設定値はネームサーバを変えろという指示をキャンセルしてからでないと表示されない）Microsoftは凄いなぁ、と思いますけど。

また、ドメインを追加した直後は⑨Exchangeや⑩アンチスパム（FOPE）のドメインの追加処理が完了していない（最大1～2日程度かかるらしい）事があったり、ユーザのメールボックスの作成が完了してないことが考えられるので、先に準備やできる限りで試験を実施しておきましょう。

そして、ようやくネームサーバ切り替えの一歩手前という事で、旧サーバの方にも新サーバの設定を入れます。ちなみに、これによりMXレコードの切り替わりが発生しますので、この時点からメールはOffice365に届くようになります。設定はDNSマネージャーで表示できますので、それを入れます。ちなみに、Exchangeで必要なのが上3つ（最低限MXレコードだけは必要）、Lyncで必要なのが下2つ（どちらとも無くても手動でセットアップ可能）になります。

⑪今回は、お名前.comで新規に取ったドメインという前提なので、既存のドメイン情報にレコードを追加したいと思います。ただし、SRVレコードは作成が出来ない為、Exchange用のMX、CNAME、TXTレコードのみ追加します。確認が終わったら変更するボタンを押します。
　

さて、これでようやくネームサーバーを（ある程度）安全に切り替えることが出来そうです。さすがに私はこれをすっ飛ばしてとりあえず「ネームサーバー切り替えて下さい」と言える勇気はさすがに無いです。⑫ネームサーバ変更から、既存で設定されているサーバを削除してns1.bdm.microsoftonline.com、ns2.bdm.microsoftonline.comを設定します。担当者の名前や電話番号を入れる部分はGMOはwhois代行サービスもやっているので、適当に既存で設定されているGMOの値を入れます。
　

これで設定終了です。簡単にまとめると以下のような感じですかね。

①管理メニューから追加するドメイン名を入力し、認証に必要なTXTレコードを取得する。
②別ウィンドウでDNSホスティングサービス等のメニューに接続するなどして、①で取得したレコードを確認する。
③②で設定したTXTレコードや必要に応じて変更したNSレコードの変更が新規検索をした際に反映されている事を確認する。
④①の画面に戻り、認証を行う
⑤ネームサーバを切り替える指示が来るが、キャンセルする
⑥DNSマネージャーを開き、Office365利用に必要なDNSの情報を取得する
⑦DNSマネージャーから、既存のDNSサーバに設定されているレコードの情報をOffice365のDNSにも追加する
⑧既存DNSサーバのMXレコードのTTLを300秒等の小さい値に変えておく（メールの切り替えを実施する場合のみ）
⑨Exchange Onlineで各ユーザのメールボックスを作成する
⑩FOPE経由で追加するドメイン宛のメールが着信出来るかtelnetコマンドなどでSMTPコマンドを叩いてチェックする
⑪既存DNSサーバにOffice365利用に必要な情報を追加し、MXレコードをxxx.mail.eo.outlook.comに切り替える
⑫ドメインのレジストラから、ネームサーバをns1.bdm.microsoftonline.com、ns2.bdm.microsoftonline.comに変更する

また、参考までに軽く触った限りのプランPのドメイン周りの制約事項ですが、以下の感じです。これでも問題ないという事であれば、無料で使えるリソースですし、活用されるのも良いかもしれません。

  1. 追加できるレコードの種類はAレコードかCNAMEレコードのみ
  2. TTLは最短で1時間
  3. Office365で利用するドメインとしてサブドメインは登録自体が不可
  4. DNSサーバはMicrosoftが用意すると言っている割には最初の登録の際にユーザが設定可能なDNSサーバまたは他のDNSサービスが必要。

監査環境下でのExchange Onlineの退職者の処理

Posted on by • Posted in Exchange Online, シングルサインオンとディレクトリ同期 • Tagged • Leave a comment

Exchangeのプラン2では、長期間に渡るメールの監査・アーカイブへの対応を実施することが可能となっております。これは、「各ユーザのメールボックスの無制限のアーカイブ＋削除/変更したアイテムの保全＋監査ログ」という要素によって構成されており、情報の分散管理（各ユーザーのメールボックス）とその横断検索がキーとなっています。

ここで1点問題になってくるのが、退職者に関する処理です。ディレクトリ同期下において、退職したからと言ってローカルのAD上でアカウントを削除してしまうと、削除した情報がそのままクラウド側に同期され、ユーザが削除され、メールボックスが一定期間（30日）後にサーバ上から削除されます。

こうしてしまうと、退職前に何か仕掛けてから辞めていった人に対しての、さかのぼっての監査が実施できなくなってしまいます。とはいえ、永久的にメールボックスを残すということは、辞めた人の分も合わせてID単位の課金を続けなくてはいけなくなり、どんどん必要なサブスクリプションを追加していかなくてはならず、非現実的です。

退職者の情報は、ネットワーク管理者が必要な分のみ.PSTファイルに落として一定期間ローカル保存しておくという運用が一般的ですが、横断検索が出来なく無くなるなどの不便が生じますので、一定期間Office365にアカウントを残すという運用を考えます。

  1. 当該ユーザーのログオンを不可にする
  2. 当該ユーザーへのメールの配送を止める
  3. 配布グループから抜いたり、グローバルアドレス一覧の非表示化などの後処理

などが考えられますが、1.に関してはローカルのADでアカウントを無効化すれば、Office365へのアクセスも不可になります。（サブスクリプションは解放されないですし、普通にメールも配送され続けますが）

2.はExchange Online側のアクセス権で普段はメールを送ることが無い管理用アカウントなどだけからのメールを受け取るようにSet-Mailboxコマンドレットで-AcceptMessagesOnlyFromを指定しておくのが楽だと思います。PowerShellからの設定になりますので、Exchange Onlineに接続してから実行します。

3.については、Office365のExchange Onlineサービス説明によりますと、

管理者は、社内の Active Directory でオブジェクトに HideInAddressList 属性を設定して (ディレクトリ同期ツールを使用している場合)、またはリモートPowerShell を使用して、ユーザー、配布グループ、および連絡先をグローバル アドレス一覧で非表示にすることができます。

とあるので、2.でSet-Mailboxコマンドを実行するついでに実施してしまおうと思います。

おろ、ディレクトリ同期環境下ではローカルのみですか…困りましたねぇ。そう、勘の良い人ならお気づきだと思いますが、GALの表示を制御するmsExchHideFromAddressLists属性は、Exchangeをインストールする際のスキーマ拡張で実装される物で、オンプレミスでExchangeがないユーザの環境では設定自体ができません。もちろん、マニュアルに誤記されているHideInAddressListなんてのも有りません。

さて、考えられるのは2つ。ディレクトリ同期(ILM)をいじって、どこか使ってない属性からマッピングしてくるか、スキーマを拡張するかです。ホントは前者で行きたいですが、このmsExchHideFromAddressLists属性はBoolean（TRUEかFALSEを保持する）形式なので、対応した良さそうな物が見つかりませんでした。ということで、不本意ながらExchange2010SP1の評価版をサイトからダウンロードして、中身は使わずセットアップの準備コマンドだけを利用します。

今回はスキーマ拡張だけを行いますので、setup.com /PrepareSchemaを実行します。

完了すると、無事msExchHideFromAddressLists属性が設定できるようになります。Set-ADUserコマンドの場合、拡張属性なので以下のような感じでしょうか

Set-ADUser -replace @{msExchHideFromAddressLists=$True}



う～ん、高々アカウント削除だけの話なんですが、面倒ですね。

ジャーナルアーカイブがOffice365の中で使えればこんなこと考えなくても良いのでしょうけど。（今は他のEnterpriseVaultとかのアーカイブに飛ばして格納しないといけないので、NW帯域考えると現実的では無いですよねぇ…）

ディレクトリ同期で同期されない携帯番号

Posted on by • Posted in シングルサインオンとディレクトリ同期 • Leave a comment

Office365でディレクトリ同期を行うと、ローカルのActiveDirectoryのオブジェクトならびにその各属性がOffice365側に同期されます。情報の不整合を防ぐ為に、基本的にディレクトリ同期で転送されたオブジェクトの情報はOffice365側では編集できません。

ただ、ユーザーの管理から、よく見ると一カ所だけ編集できるところがあります。それは携帯電話の番号です。ここに番号を入れればひょっとして値を変えられるのでしょうか？

そう、ここに値を入れると、Office365側の属性が書き換わります。ただ、この情報はローカルのActiveDirectoryには反映されません（ディレクトリ同期が一方向同期なので）

また、こちらに一度でも値を入れたユーザは、ディレクトリ同期項目から携帯電話の番号が除外されます。

つまり、今後会社携帯の番号が変わったからといってローカルのADで携帯番号を入れても、それはOffice365側には伝わらず、完全に別々の物として扱われるようになります。（ディレクトリ同期ではエラーも無く更新が成功したように見えるのですが、完全に無視されます）

また、一度もOffice365側で変更されたことのないユーザーについては、他の属性同様通常通り同期されるようになります。どうしてなのかは理由が分からないのですが、途中までは携帯も編集不可項目だったように思えるので、ベータテストの途中からそういった仕様に変更されたのではないでしょうか。

最近の個人情報関係の意識の高まりもありますので、携帯電話の番号をWeb上に載せたくないという要望もあるでしょうから、ユーザーが自信の情報公開範囲を限定したいというニーズに応える為ということであれば考えられなくもないかなとは思いますが、どちらかというとActiveSyncやSMS（まだ使えないですが）とかの機能でどうしてもOffice365側でMobileの番号の編集権限がないと困る物が有るのではないかなと考えてます。

変更処理自体はユーザが勝手に出来てしまう処理なので、管理者側ではどうしようもない事かと思いますが、どうしても管理者が一元的に同期するよう制御したいのであれば、だいぶ力業になりますが、ADならびにOffice365へのPowerShell接続ができる端末から、以下のようなスクリプトを定期的に実行することにより、強制的にローカルのADの情報をOffice365に同期できるようになります。（タスクなどで自動実行にするにはCredentialを保存して自動ログインにするなどの変更が必要です）

$LiveCred = Get-Credential
Connect-MsolService -Credential $LiveCred
$ADUser = $ADUsers = $MSOLUser = $MSOLUsers = $null
$i = 0
$ADUsers = Get-ADUser -properties Mobile -filter * | Select-Object UserPrincipalName,Mobile,SamAccountName
$MSOLUsers = Get-MSOLUser | Select-Object UserPrincipalName,MobilePhone
ForEach($ADUser in $ADUsers) {
  $MSOLUser = $MSOLUsers | Where-Object {$_.UserPrincipalName -eq $ADUser.UserPrincipalName}
  if([string]::isNullOrEmpty($MSOLUser.UserPrincipalName)){
    Write-Host "Skip - Office365に作成されていません: "$ADUser.SamAccountName
  }
  elseif($ADUser.mobile -ne $MSOLUser.MobilePhone ){
    Write-Host "ADの情報でOffice365を上書きします【"$ADUser.UserPrincipalName"】"
    Write-Host " - ActiveDirectory:"$ADUser.mobile" の値でOffice365:"$MSOLUser.MobilePhone"の値を上書きます"
    Set-MsolUser -UserPrincipalName $MSOLUser.UserPrincipalName -MobilePhone $ADUser.mobile
    Write-Host " - 完了しました"
    $i++
  }
}
Write-Host "終了: 計"$i"件の携帯電話番号レコードを同期しました"
Write-Host "（何かキーを押してください）"
[console]::ReadKey()

一元的に情報を扱うというのもなかなか難しいですね。っていうかこういった仕様とか制限とか、変更するのは構わないが、できれば公開情報にして貰いたいなぁ。

こちらですが、恐らく2011.秋に実装された管理者向けパスワードのセルフリセットツールで利用するためにこう言った設定になったと推測されます。