Azure AD と Exchange Online の同期とトラブルシューティングの基本

こんにちは、Exchange サポートの渡辺です。   Exchange Online をお使いいただいているお客様もかなり増えている中、これからオンプレミスの Exchange から移行を予定されている、あるいは今が移行の真っ最中というお客様もいらっしゃるかもしれません。 オンプレミスから移行頂く場合、Exchange のハイブリッド環境を構成いただくことが一般的ではありますが、ハイブリッド構成ではディレクトリ同期が必須のため、ユーザーやメールボックスの管理が少し複雑になります。   例えばこちらのブログでご紹介したメールボックスがオンプレミスと Exchange Online の両方に作られてしまうようなシナリオや、逆にライセンスを付与したのに Exchange Online にメールボックスが作成されないことがあったり、一度メールボックスを削除したものの復元する必要が出てきたときにオンプレミス/Exchange Online で何をしたらいいのかわからないなど、ユーザーやメールボックスの管理で様々なお問い合わせをいただくことが多くあります。 そんなときの助けになればと思い、これから何回かに分けて、このあたりの動作の説明やよくあるお問い合わせの対処方法などをご紹介できればと思っています。   まず、第一回の本記事では、ディレクトリ同期を行っている環境、特にハイブリッド環境のオブジェクトがどのように関連しているのかや、Exchange Online に設定が反映されない場合のトラブルシューティングの方法についてご紹介したいと思います。   Exchange Online とディレクトリ同期の基本 最初に登場人物の紹介をさせていただくと、ハイブリッド環境では以下の 3 つのオブジェクトを意識する必要があります。   ・ オンプレミス上のオブジェクト (リモート メールボックス) ・ Azure AD 上のオブジェクト (MsolUser) ・ Exchange Online 上のオブジェクト (メールボックス)   それぞれのオブジェクトの関係性としては以下のようなイメージになっています。 どのオンプレミスのリモート メールボックスが、どの Azure AD の MsolUser…


アカウントを乗っ取られた際の対応について

Office 365 をご利用いただいているお客様からよく寄せられるご質問のひとつとして、アカウントが乗っ取られた(ハッキングされた)際にどう対処すればよいかという質問があります。 最も一般的なシナリオは、組織のメンバーがフィッシング詐欺の被害者になり、攻撃者にアカウントのパスワードを取得されてしまったというものです。 このブログではアカウント乗っ取りの発覚から、乗っ取りが確定した場合の対応、そして再びアカウントを乗っ取られないようにするための予防策についてご紹介したいと思います。   1. 問題の発覚 アカウントが乗っ取られた際によく見られるアクションとしては、例えば以下のようなものがあります。   メッセージがなくなっている、もしくは削除されている 乗っとられたアカウントからメールを受け取ったユーザーがいるが、乗っ取られたアカウントの送信済みフォルダーには送信済みのメールがない 管理者やユーザーが設定した覚えのない受信トレイ ルールや転送ルールが設定されており、内容としては、見知らぬアドレスへ転送するものや、[メモ]/[迷惑メール]/[RSS フィード] フォルダーへアイテムを移動するようなルールが設定されている Global Address List 上のユーザー名が変更されている 乗っ取られたユーザーの外部へのメール送信がブロックされており、メールを送信すると “550 5.1.8 Access denied, bad outbound sender AS(XXXXXXX)” という NDR を受信する   ユーザーから上記のような報告があがった場合、管理者はアカウントが乗っ取られた可能性を疑い、対象のアカウントでどのようなアクティビティが行われたか調査を開始するべきです。 ※※重要※※ アカウント乗っ取りが疑われた時点で、速やかに対象のアカウントのパスワードを変更することを推奨します。 なお管理者が変更した場合は、新パスワードをメールでユーザーに通知しないでください(乗っ取った人物も確認できる可能性があるため)。   2. 管理者による調査 Security & Compliance Center や Azure ポータルから、対象のアカウントのアクティビティの詳細を確認し、アカウントが想定していない動きをしていないかを確認します。 一般的な確認項目を以下に記載します。   <Azure ポータル> 対象のアカウントにログインしているアクセス元 IP/サインインの場所 サインインに成功/失敗した回数  …


Exchange 2013 OWA におけるリダイレクト ルールの作成について

現象 OWA の受信トレイのルールにて、リダイレクト先に [個人の連絡先] を設定した場合、設定した [個人の連絡先] の “「姓」「名」“と同様の cn 値を持つ受信者が AD 上に存在すると、リダイレクト先が AD 上の受信者に置き換わる事象が発生します。 例えば以下のようなメールボックスおよび連絡先アイテムが存在する環境において、リダイレクト先として連絡先アイテム “test 01” を選択すると、リダイレクト先の SMTP アドレスは AD 上のメールボックスに設定された user1@mt.local となります。   – 連絡先アイテム   – AD 上のメールボックス   – ルールの設定画面 以下の通り、実際に保存されたルールの編集画面においても、AD 上の受信者がリダイレクト先として保存されていることを確認可能です。   回避策 本事象はルール保存の際に GAL 上でオブジェクトの検索が行われることに起因し発生しますが、以下のいずれかの方法で回避することが可能です。 1) Outlook でルールを作成する 2) リダイレクト先の指定時に連絡先アイテムを使用するのではなく、SMTP アドレス (上記例では user2@contoso.com) を直接入力する 3) 管理者が Exchange 管理シェルより New-InboxRule…


Windows Server 2016 上にインストールした Exchange 2016 でバックアップのリストアが成功しない

現象 Windows Server 2016 上にインストールした Exchange 2016 環境において、Windows Server Backup で取得したバックアップから以下の条件でリストアを行うと、エラーが発生します。   [回復の種類の選択] ページで、[アプリケーション] を選択   [回復オプションの指定] ページで、[元の場所に回復する] を選択   リストアを行うとエラーが発生     原因 現在弊社にて調査中です。   回避策 現在弊社にて調査中です。   その他 [回復オプションの指定] ページで、[別の場所に回復する] を選択すれば、リストアが可能です。 Windows Server 2012 R2 上にインストールした Exchange 2016 では [元の場所に回復する] でもリストアは可能です。 情報のアップデートや修正が確定いたしましたら本 Blog でも情報を更新いたします。   ※本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。