こんにちは。前回はダイアルピア探索の設計をしました。

今回はiPhone/Androidなモビリティもピアに参加させるのが第一の目的ですので、Auth＆Certの設計をしないといけません。

前回触れたようにモバイルデバイスの認証・証明書管理って、いつもPCより厳格で締りがキツイですからね。

では、さっそくAuth&Cert設計図です。

重要ポイントを赤字①～③で示しました。

【①Certification/認証について】

ここでは、iPhone/Androidでも信頼可能なCA局お墨付き証明書が必須ということで、ADにCSサービスを加え証明機関にする設計です。

SFB サーバが稼働したらExchangeサーバとパートナーを組ませたいので、ついでにExchangeサーバも自己証明書を廃止し、CA/Certに切り替える設計しました。

【②Authorization/承認について】

またしてもモビリティ問題を克服しなくてはいけません。

マイクロソフト社の「Skype for Business Server の DNS 要件」を見ると、外部アクセスさせるのに、最低限でもInternal/Publicの各用途に分けたEthernet、そしてEdgeサーバも立ち上げないといけなそうですよね。

ここで私は思いました。

（え～！！やだやだ～！＞＜面倒くさいです。）と、それにですね、ここで要望したい外部接続って、例えば取引先ユーザやオフシェア人材とかではなくて、内部スタッフによる外部アクセスにもサービスを提供したい！ってことです。

ということで、同じMS社のLync2013時代の記事「Technical requirements for mobility in Lync Server 2013」を採用して、モバイルアクセスを含めたAuth設計を行います。

iPhoneを始め現在のモビリティは、基本的にCA/Certを使ったOAuthでのみLogin承認する仕様なんですよね。

で、MS社推奨は、SFBで余剰にIPを払い出し、EdgeサービスでOAuthする仕様（前者）なのですが、今回SFBはOne Local IPのみ、Edgeサーバも立てずにやってしまおうというプランで強引に行きます。

後者のMS解説を読み解きますと、SFBサーバにInternalWeb(443)とExternalWeb(4443)が展開されることがわかります。

そこで、DMZを管理するUTM（Fortigate)にReverseProxyサービスを実行してもらい、Edgeサーバの代行をしてもらえばええやん？！という設計になりました。

【③CME接続(SIP/TCP)について】

図面でわかるとおり、SFB、CME共にInternalに配置されてますのでね、ここではね、SIP/TLSはやりません！

どうしてかって？

• 暗号化通信によってネットワーク物量＆速度コストが上がる
• 各エンドポイントで暗号化＆符号化に要するCPU計算＆発熱コストが上がる
• 結果、消費電力も上がるうえに、私の設計にかかる頭脳コストで高熱にうなされるハズ

だからです。

良いことなさそうだし、疲れるし、そんなことで、ここは手早くTCPで仕上げる設計にしました。汗

では、今回はここまでとなります。興味ある方はぜひじっくり立ち読みしてください！！