Skype for Business Online に Web Proxy で接続「2018 年 1 月更新」

  • Article

こんばんは、Lync サポートのワトソンです。

Lync 2013/SfB  クライアントから、SfB Online に接続を行う際、Lync 2013 / SfB クライアントは端末の IE の Proxy 設定を利用し、各 URL に接続を行います。Proxy をご利用頂く際、以下 1,2,3 の準備が必要になります。

 

■ 1. Proxy サーバーで必要な URL およびに IP のワイトリスト登録

内部のユーザーから Lync Online へのアクセスが発生した際、そのアクセスがプロキシ上で許可されており、認証などが求められない事が必須要件となります。 製品によっては設定の名称が異なりますが、一般的に、ホワイトリスト登録や認証除外設定と呼ばれています。 登録が必要な URL に関しましては以下のサイトをご覧ください。

Skype for Business Online に関連する宛先は、以下のセクションをご参照ください。

注意.1 :
弊社サーバーが提供する証明書については、公的な認証局 (CA) で発行されたものが利用されております。そのため、上記にて公開されている弊社設備宛の通信以外の宛先に対し、証明書失効リスト (CRL) を取得するための接続が発生いたします。証明書失効リストが取得できるよう、以下の公開情報をもとに認証局が提供する宛先についても、接続可能となる様に登録が必要となります。

注意.2 :
一般的な企業ではカスタムドメインが用いられており、このカスタムドメインに関連したいくつかの宛先に通信が発生します。これらのカスタムドメインに関しては上記公開情報には記載されていないため、以下についても Proxy Server を適切に経由できるよう、考慮する必要があります。

  • lyncdiscover.<SIP domain> / Skype for Business Server Online の自動検出
    サインイン時、クライアントが SfB Server を検出する際、規定の動作として接続が発生いたします。
    HTTP と HTTPS の両方で接続が試行され、証明書の関係で HTTP による接続が成立します。
  • autodiscover.<SMTP domain> / Exchange Online の自動検出 (EWS 接続)
    EWS 接続時、クライアントが Exchange Server を検出する際、規定の動作として接続が発生いたします。
    Exchange Online に直接接続する場合は、証明書の関係で HTTP による接続が成立します。
    なお、ホストを含まない <SMTP domain> 宛にも試行されますが、接続できる必要はありません。
    認証 Proxy Server によりダイアログが表示されない様、同様に除外いただきますようお願いいたします。

なお、これらの自動検出 URL を PAC で制御する場合、OS のバージョンに応じて書き方を考慮する必要があります。詳細につきましては、以降で説明させていただきます。

_

■ 2. インターネットオプションで Proxy Server を設定

Skype for Business クライアントはインターネットオプションで定義された Proxy Server の定義を用いて、Proxy Server を経由する接続を行います。その際、直接 Proxy Server や除外設定を定義する方法や、より複雑なルールとするために、PAC ファイルや WPAD による自動構成を行う方法があります。これら Proxy Server の設定に関する注意点を、以下に説明いたします。

  • Proxy Server を直接定義する場合の設定例
  • PAC ファイルを指定する場合の設定例

注意.1 :
認証に AD FS を利用している場合、組織の AD FS サーバーへの接続が Proxy Server 経由ではなく、Direct へ除外される様に例外や PAC ファイルにて設定する必要があります。これは、セキュリティトークンサービスへの接続が Proxy Server を経由し、WAP (Web Application Proxy) を介した外部からの接続となった場合、クレームルールにより認証が許可されないケースが発生するためとなります。
もし、Proxy Server を経由せざる負えない事情がある場合は、Proxy Server の hosts ファイルなどに、セキュリティトークンサービスのレコードを社内の AD FS 向けに登録するなどの対応が必要となります。

注意.2 :
WPAD による自動構成を利用していない環境においては、インターネットオプションの [設定を自動的に検出する] を無効にします。Skype for Business クライアントが Proxy Sever を検出するプロセスが早くなり、不要な Broadcast パケットの送信が削減されるためとなります。また、一部環境では具体的に通信に失敗するケースも報告されています。_

注意.3 :
自動構成を利用する場合は、WinHTTP Web Proxy Auto-Discovery Service を無効化しないでください。アドレスを指定して PAC ファイルを利用する構成においても、本サービスが利用されます。

_

■3. Proxy Server 環境におけるその他注意事項

Proxy Server を利用するネットワーク環境における注意事項を、まとめて以下に記載します。

a. Proxy Server の HTTPS/SSL セッションのタイムアウト
サインインが完了すると、Skype for Business クライアントとサーバー間では SIP MTLS による接続が維持されます。そのため、TCP セッションや HTTP/SSL セッションが経路上の装置で切断された場合、サーバーへのレジストレーション処理が実行されます。再レジストレーションの処理は自動的完了するため影響は小さいものとなりますが、Proxy Server におけるセッションタイムアウトを 8 時間に設定することが推奨されます。

b. 自動検出用の lyncdiscover.<SIP domain> に関する PAC 内の記述
lyncdiscover URL への接続を PAC ファイル内で定義する場合、url.substring 関数を用いる必要があります。その他の関数で定義した場合、OS に依存して正しく反映されない場合があります。なお、Windows 10 では dnsDomainIs など、その他関数でも定義可能となっていますが、Windows 7 などが混在するケースを考慮し、url.substring を利用することが推奨されます。

  • 例：
    function FindProxyForURL(url,host)
    {
    if (url.substring(0, 20) == "https://lyncdiscover."||
    url.substring(0, 21) == "https://lyncdiscover.")
    return "PROXY 10.1.1.1:8080";
    else
    return "DIRECT";
    }

以下の関数では、lyncdiscover.contoso.com へのアクセスが正しく反映されない場合があります。

  • 例 :
    dnsDomainIs(host, "*.contoso.com")

c. ローカルリソースへをダイレクトに除外する PAC 内の記述
基本的に、社内からの認証は AD FS Server へ直接要求される構成とします。そのため、セキュリティトークンサービスへの接続や、ローカルサブネットへの接続については、Proxy Server 経由では無くダイレクトに接続される様構成します。以下の例では、sts.contoso.com への接続はダイレクトと定義され、それ以外の接続は Proxy Server 経由となります。

  • 例：
    function FindProxyForURL(url,host)
    {
    var hostip = dnsResolve(host);
    if (isInNet(hostip, "127.0.0.0", "255.0.0.0") ||
    isInNet(hostip, "10.0.0.0", "255.0.0.0") ||
    isInNet(hostip, "172.16.0.0", "255.240.0.0") ||
    isInNet(hostip, "192.168.0.0", "255.255.0.0"))
    return  "Direct";
    else
    if (shExpMatch(host, "sts.contoso.com"))
    return  "Direct";
    else
    return "PROXY 10.1.1.1:8080";
    }

d. EWS 接続に関連して Proxy Server の認証が求められるケース
認証 Proxy Server を利用している環境で、Skype for Business が利用する宛先を認証除外しているにも関わらず、Proxy Server からの認証を求められるケースが発生します。これは、EWS の自動検出プロセスにおいて、autodiscover.<SMTP domain> への接続より前に、以下 URL への接続も試行されることが要因となるケースがあります。

  • https://<SMTP domain>/autodiscover/autodiscover.xml

上記 URL への接続は、Skype for Business クライアントにハードコートされているため無効化できません。そのため、Exchange Online 環境では上記 URL への接続に失敗した結果、以下いずれかの URL に対する接続により自動検出が成功することが期待される動作となります。

  • https://autodiscover.<SMTP domain>/autodiscover/autodiscover.xml
  • https://autodiscover.<SMTP domain>/autodiscover/autodiscover.xml
    ※Exchange がハイブリッド構成では無い場合、証明書の関係で HTTP による接続が必須となります。

以上のとおり、<SMTP domain> へのアクセスは失敗しても問題は無いものの、想定外のルールに従って認証 Proxy Server を経由してしまうケースがあります。Proxy Server 側で認証から除外するなどの対策も可能ですが、認証 Proxy Server と非認証 Proxy Server を PAC で使い分けている場合など、以下の様に PAC 内のルールで回避することも可能となります。

  • 例 :
    ユーザのメールアドレスが user@contoso.com の場合
    function FindProxyForURL(url,host)
    {
    // non auth proxy
    if (url.substring(0, 20) == "https://contoso.com")
    return "PROXY 10.1.1.1:8080";
    else
    // Office 365
    if (dnsDomainIs(host, ".office365.com")||
    dnsDomainIs(host, ".lync.com")||
    dnsDomainIs(host, ".onmicrosoft.com"))
    return "PROXY 10.1.1.1:8080";
    else
    // auth proxy
    return "PROXY 10.2.2.2:8080";
    }

注意.1 :
ドメイン名だけの URL を、Exchange 以外のその他システムで利用している場合、いくつかの考慮が必要となります。

  • 該当システムへの接続を認証 Proxy Server 経由とした場合、上記回避策と競合します。
  • 該当のシステムが HTTPS で公開されている場合、SIP と SMTP でドメインが異なる場合、証明書に含まれるドメインが信頼されないものとしてダイアログが表示されます。グループポリシーを用いて Trusted Domain List を配布することにより回避可能となります。（TrustModelData のレジストリも同様です。）

e. Proxy Server を経由した接続動作のみに限定したい
Skype for Business クライアントの実装では、Proxy Server が利用可能なネットワーク環境であったとしても、DNS の名前解決が可能な接続先についてはダイレクトによる接続を試みた後に、Proxy Server による接続を試みる動作が既定となります。この実装を要因として、以下の様な問題が発生いたします。

  • ダイレクトの接続がファイアウォールでブロックされ、TCP のタイムアウトやリトライが発生することでサインイン完了までに多くの時間を要します。
  • ファイアウォールにおける通信のブロックが、TCP コネクション確立後に行われる実装の場合、サインイン処理に失敗します。
  • DNS サーバーの構成により、名前解決に失敗するまで時間を要する場合、さらに時間を要したり、失敗する状況が発生します。
    参考 : Skype for Business Online – Proxy 環境における DNS の影響

Skype for Business Online の普及に伴い、影響を受けるネットワーク環境が増加したこともあり、サインイン時の認証やユーザー検索 (SOAP)、 クライアント制御 (SIP) の通信に関しては、ダイレクト接続を試みない実装が追加されています。以下のレジストリを追加していただくことにより、Proxy Server が利用できる宛先については、ダイレクト接続が試行されずに Proxy Server 経由の接続が行われます。

メディアやオンライン会議に関連する以下の通信は対象では無いため、引き続きダイレクト接続も試行されます。

  • 音声/ビデオ
  • デスクトップ共有/アプリケーション共有
  • P2P 接続時のファイル転送
  • オンライン会議制御用の PSOM

なお、一部の通信だけが Proxy Server を経由せずに直接接続が確立できてしまった場合、オンライン会議への参加に失敗する問題が発生いたします。その様な状況を避けるためには、適切に Proxy Server を経由するように構成し、ファイヤーウォールにおいて適切に通信をブロックすることが重要となりますが、上記レジストリの追加についてもご検討ください。
反対に、Proxy Server を経由させない場合は、PAC ファイルを用いてダイレクト接続とすることと、ファイヤーウォールで適切に開放頂けますようお願い致します。

f. Windows 10 における自動検出  lyncdiscover.<SIP domain> に関する注意事項 (2017/1 追記) 上記 d. で記載いたしましたように、Windows 10 より前の OS では、lyncdiscover.<SIP domain> の自動検出 URL を PAC 内で定義するために url.substring の関数を利用する必要がありました。そのため、例えば以下のような記述でも lyncdiscover.<SIP domain> 宛の接続は Proxy Server 経由となり、サインイン時に問題は発生しませんでした。

  • 例 :
    function FindProxyForURL(url,host)
    {
    if (dnsDomainIs(host, ".contoso.com")||
    dnsDomainIs(host, ".fabrikam.com"))
    return "DIRECT";
    else
    return "PROXY 10.1.1.1:8080";
    }
    ※ lyncdiscover.contoso.com は、dnsDomainIs 関数では一致しませんでした。

しかしながら、Windows 10 では url.substring 以外の関数でも lyncdiscover.<SIP domain> の処理が一致するようになったため、上記の例ではダイレクト接続となるルールに一致してしまい Proxy Server 経由となりません。その結果、Windows 7 ではサインインに成功していたにもかかわらず、Windows 10 では同じ PAC ファイルを用いているにも関わらずサインインに失敗する問題が発生します。この問題を考慮した PAC の記述は以下のようになります。

  • 例 :
    function FindProxyForURL(url,host)
    {
    if (url.substring(0, 20) == "https://lyncdiscover."||
    url.substring(0, 21) == "https://lyncdiscover.")
    return "PROXY 10.1.1.1:8080";
    else
    if (dnsDomainIs(host, ".contoso.com")||
    dnsDomainIs(host, ".fabrikam.com"))
    return "DIRECT";
    else
    return "PROXY 10.1.1.1:8080";
    }
    ※ lyncdiscover.contoso.com は、あらかじめ古い OS でも対応するように url.substring 関数で Proxy Server 経由とします。
    ※ Exchange Online の場合、autodiscover.contoso.com も同様に考慮する必要があります。

 

引き続き快適な Sfb Life をお楽しみください。

免責事項:
本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

 

 

https://support.microsoft.com/ja-jp/help/3207112/skype-for-business-should-use-proxy-server-to-sign-in-instead-of-trying-direct-connection