none
Exchange2010におけるAutodiscoverの動作仕様について RRS feed

  • 質問

  • Exchange2010 環境において、Outlook を起動した際に一番最初にリクエストを受ける SCP についてご教示下さい。
    上記は、ユーザーアカウントが所属しているドメインのドメインコントローラーである認識なのですが、
    ドメインに複数サイトが存在した場合、サイトは問い合わせ先となるドメインコントローラーの選択に影響を及ぼしますでしょうか。

    できれば上記を説明しているドキュメントなどがあれば合わせてご連携いただけると助かります。

    2018年1月31日 11:42

回答

  • リソースフォレストモデルでSCPを利用する場合は、ご指摘の通り直接CASなどのアドレスが含まれる内容がアカウントフォレスト側に格納されているのではなく、リソースフォレストのSCP格納先へのLDAPのポインタが格納されています。Outlookはその情報を元に3-4の処理を行う形になります。

    ※このポインタは自動的には作成されませんので、手動でSCPのオブジェクトをリソースフォレストからアカウントフォレスト側にエクスポートしてあげる必要があります。

    ここで、1番で利用されるドメインコントローラは、基本的にはユーザーのログオンに利用したドメインコントローラなります。これはNETLOGONサービスによって選択されますので、DNSサーバのSRVレコードを元に判断し

    ①同一ADサイト上の同一ドメインのドメインコントローラがあればそこの中からランダムで選択
    ②自IPサブネットがどのADサイトにも紐づいていなければ、同一ドメインの全ドメインコントローラからランダムで選択
    ③①に失敗した場合はサイト外の同一ドメインのドメインコントローラからランダムで選択

    という流れになるかと思います。

    あと、6番はOutlookの場合はおそらく証明書認証ではなくWindows認証またはBasic認証となるかと。

    複数のフォレストにおける自動検出サービスを構成する
    https://technet.microsoft.com/ja-jp/library/aa996849(v=exchg.141).aspx


    • 編集済み Genki Watanabe 2018年2月1日 3:45
    • 回答としてマーク ayuzer 2018年2月1日 11:36
    2018年2月1日 3:44

すべての返信

  • SCPですが、Exchange側の機能ではなくクライアント側のOutlookの機能となります。

    SCP自体が格納されており、クライアントが情報を取得するのはログオン先のドメインコントローラになりますが、その中に格納されているのは接続先のExchangeのCASと対応するADサイトの情報の組み合わせとなり、Outlookはそれを元にどのCASに接続に行くかを決定し、接続を試行します。

    疑問に思われている部分が今一つ理解できていないのですが、複数サイトの場合のどういった挙動(仕様)が知りたいのかを明確にして頂ければ回答もしやすいかと思います。

    Autodiscover を振り返る エピソード 1
    https://blogs.technet.microsoft.com/exchangeteamjp/2014/03/03/autodiscover-1/

    2018年2月1日 0:11
  • ご返信ありがとうございます。ご説明が不足しており申し訳ございません。

    SCPの情報をドメインコントローラーが保持しており、最終的には Exchange の CAS から設定を受領する流れは
    ある程度理解しているのですが、autodiscover 発動の起点でクライアントが問合せ先として認識している
    ドメインコントローラーが、どのようなロジックで選定されているのかを明らかにしたいという意図がございます。

    背景としては、現在アカウントフォレストとリソースフォレストが分かれた構成のActiveDirectory組織
    Exchange 2010 を運用しており、このシステムの更改を行う中で、現状の Autodiscover の動きを
    ハッキリさせておきたいという要件が前提にございます。

    理解している動きとしては、以下の通りです。

     1.Outlook を起動するとユーザーアカウントが所属するアカウントフォレストのドメインコントローラーに
       SCP 要求が行われる

     2.アカウントフォレストのドメインコントローラーが、リソースフォレストのドメインコントローラーへの接続情報を返却する

     3.リソースフォレストのドメインコントローラーへ SCP 要求が行われる

     4.リソースフォレストのドメインコントローラーから、SCPの一覧が返却される

     5.クライアントは一覧から自身のサイト情報に対応する URL(CAS) を選択し、SCP要求を行う 

     6.証明書の検証を経て、Autodiscover接続に成功する

    この一連の動作の起点となる「1」のドメインコントローラーの選択ロジックを明らかにしたく。
    (想定では、ユーザーアカウントが所属するドメイン、かつコンピューターアカウントの持つサイト情報を
     キーに、同一ドメイン・同一サイトのドメインコントローラーが SRV レコードで解決されるといった動きをしているのではないかと
     考えているのですが、確証が無く・・・)

    2018年2月1日 2:54
  • リソースフォレストモデルでSCPを利用する場合は、ご指摘の通り直接CASなどのアドレスが含まれる内容がアカウントフォレスト側に格納されているのではなく、リソースフォレストのSCP格納先へのLDAPのポインタが格納されています。Outlookはその情報を元に3-4の処理を行う形になります。

    ※このポインタは自動的には作成されませんので、手動でSCPのオブジェクトをリソースフォレストからアカウントフォレスト側にエクスポートしてあげる必要があります。

    ここで、1番で利用されるドメインコントローラは、基本的にはユーザーのログオンに利用したドメインコントローラなります。これはNETLOGONサービスによって選択されますので、DNSサーバのSRVレコードを元に判断し

    ①同一ADサイト上の同一ドメインのドメインコントローラがあればそこの中からランダムで選択
    ②自IPサブネットがどのADサイトにも紐づいていなければ、同一ドメインの全ドメインコントローラからランダムで選択
    ③①に失敗した場合はサイト外の同一ドメインのドメインコントローラからランダムで選択

    という流れになるかと思います。

    あと、6番はOutlookの場合はおそらく証明書認証ではなくWindows認証またはBasic認証となるかと。

    複数のフォレストにおける自動検出サービスを構成する
    https://technet.microsoft.com/ja-jp/library/aa996849(v=exchg.141).aspx


    • 編集済み Genki Watanabe 2018年2月1日 3:45
    • 回答としてマーク ayuzer 2018年2月1日 11:36
    2018年2月1日 3:44
  • お世話になっております。ご返信いただきありがとうございます。
    ご丁寧にご説明いただき恐れ入ります。

    NETLOGONサービスによって選択されるという、ご説明いただいた動作については
    通常クライアントがドメインコントローラーへ情報参照へ向かう際の既定の流れであると理解しました。

    6番については、URLに"https"を利用しているため、証明書の検証が行われているようです。
    (別件で、SCP経由での認証が失敗したときに、次段の動作でこの検証に失敗して警告のポップアップが出てしまう問題があり。。。)

    ご回答いただきありがとうございました。

    • 回答としてマーク ayuzer 2018年2月1日 11:36
    • 回答としてマークされていない ayuzer 2018年2月1日 11:36
    2018年2月1日 11:36