リソースフォレストにLync 2013をインストールする

Microsoft Lync 2013の展開にはリソースドメインが必要な場合があります。 リソースドメインは、Lync 2013サーバー自体のみが存在する場所であり、ユーザーは別のユーザードメインに存在します。 お互いの友達を作る方法を以下に説明します。 誰も気にしない、猫へようこそ。 興味深いものになります（そしてあらゆる種類の写真）。

なぜこれらすべてが必要なのでしょうか？

いつものように、設計を決定する前の最初の質問は「なぜこれが必要なのですか？」です。 この決定も例外ではありませんでした。 すべてがセットアップされ、構成され、機能している場合、なぜ庭をフェンスで囲みますか？



最初の理由は心理的です 。MSLync 2013をインストールするには、Active Directoryスキーマにいくつかの変更（拡張）が必要です。 100台のマシンに対して1つのドメインを持つ1つのフォレストがある場合、これは1つのことですが、多数のドメインと重要なサービスを備えた健全なインフラストラクチャがある場合、潜在的に危険なスキームを拡張すると、顧客と通信するときに障害になる可能性があります。 動作します-ここには触れないでください。 そして、すべてがうまくいくという事実についてのあなたの説得は、何の影響もありません。



2番目の理由は通常、パイロットプロジェクトで発生します。 顧客は、製品に精通し、それが自分に合っているかどうかを理解するために、インフラストラクチャを喜んで変更することを望んでいるとは限りません。 一番の理由にはエコーがあります。製品が導入されるかどうかがまだ明確でない場合、なぜシステムにあらゆる種類の新しいオブジェクトが必要なのでしょうか？ なぜなら 私自身はシステム管理者として長い間働いていましたが、私自身の経験から私はすべての責任をもって宣言することができます-彼らの財産の侵入の管理者は好きではありません。 そして、彼らの嫌悪感はリーダーによって完全に共有されています。



他の理由があるかもしれません。 たとえば、セキュリティガードは通信システムについて独自の見解を持っているため、この件に関して管理者に依存したくありません。 または何か他のもの。



また、MS Lync用に別のインフラストラクチャを構築することも1つだけ残されています。MSLyncでは、好きなことを実行できますが、既存のインフラストラクチャには影響しません。

それはどのように見えますか

私の例では、テスト環境ですべてを実行します。テスト環境を以下に概略的に示します。







私のラボでは、それぞれに1つのドメインを持つ2つのフォレストが作成されています。 contoso.internalドメインは、すべてが長い間確立されている既存の顧客インフラストラクチャを意味します。 lync.internalドメインは、Lyncサーバーが展開されるリソースドメインを指します。 lync.internalドメインがcontoso.internalドメインを信頼するドメイン間で、一方向の信頼が発生しました。 その逆は真実ではありません。 一方的な信頼は、セキュリティの見通しに左右されます。 ただし、ほとんどの場合、両面信頼を安全に上げることができます。これは、トラブルシューティングで非常に簡単です。



仮想環境で上記のスキームを実装するために、次のサブネット構造が展開されました。







contoso.internalドメインは192.168.1.0/24ネットワークに展開され、lync.internalドメインは192.168.2.0/24ネットワークに展開されます。 同時に、顧客の詳細のために、contosoドメインはWindows 2008に基づいて作成され、lyncドメインはWindows 2003に基づいて作成されました（読者にスクリーンショットに関する質問がないようにするため）。 ゲートウェイとして、Vyattaに基づくソフトウェアルーターが作成されました。

この記事では説明しません。

なぜなら この記事は厳密に定義された問題を解決することに専念していますが、以下の点は考慮しません。

• 仮想環境と仮想マシンのセットアップ。
• ドメインフォレストの展開。
• LyncとそのクライアントをターゲットPCにインストールする
• ドメイン間のユーザー同期を自動化します。

ただし、Lyncをインストールする前に、PKIサービスのセットアップに注意を払います。 今後の作業に便利です。



プロローグは終了しました。 降りる。

成功するために必要なもの

ネットワーク環境を展開して構成する必要があります。 ルーティングとトラフィックフローを必ず確認してください。 すべてのマシンでファイアウォールを無効にします。 それにもかかわらず、これは軍事的な紹介ではなく、研究室です。



それぞれにドメインを持つ2つのフォレストが必要です。 リソースフォレストのドメインとフォレストのレベルを必ず2003に上げてください。そうしないと、Lyncはインストールされません。



Lyncクライアントがインストールされた（たとえば、MS Office 2013スイートから）クライアントコンピューターを展開する必要があります（Windows 7など）。

PKIサービスを構成する

MS Lync 2013には証明書サービスが必要です。 もちろん、証明書をどこかで生成してシステムにインポートできます。 ただし、制限を設けるためにリソースドメインを引き上げるわけではありません。



したがって、Lync自体を展開する前に、有効な証明書サービスが必要です。 それをインストールして、証明書の発行を開始する前に、設定を少し変更しましょう。



CAのプロパティに移動し、[拡張機能]タブに移動します。 そこには次のものが表示されます。







このすべての不名誉から、CRLのローカルストレージにつながる一番上の行だけを残す必要があります。 残りは自由に削除してください。 次に、最も単純なバージョンのhttpプロトコルを介して失効した証明書のシートを公開する行を追加します。 ユーザードメインのユーザーにとって便利です。 私の例では、http行を追加しました（httpsで偽装してキャストする必要はありません。これは完全に不要です） http：//crl.lync.internal/root.crlのコンテンツ。







このCAによって発行されたすべての証明書は、上記のパスで失効した証明書のリストを確認できることを示します。 この記事では、この公開方法とファイルをコピーするメカニズムをサポートするIIS（またはその他のWebサーバー）のインストールと構成については説明しません。 読者は自分でこれを行うように招待されています。



その後、通常の方法でLync 2013を安全にインストールできます。 Lyncには、lync.internalとcontoso.internalの2つのSIPドメインがあることを忘れないでください。 したがって、Lyncを展開するときは、追加のSIPドメインを必ず指定してください。



何らかの理由で既にLyncを展開している場合は、トポロジビルダーで2番目のドメインを追加し、構成の変更（新しい証明書の発行と取得）に必要な手順を実行します。

ドメイン間の信頼の構築

信頼手順の構築は非常に簡単です。 最初に、DNSサービスの各ドメインの別のサーバーへのゾーンの転送を許可する必要があります。 ラボが全員に送信することを許可するか、厳密に指定されたDNSのみを送信する必要があることをすぐに示すことができます。







その後、contoso.internalドメインで、Lync.internalのセカンダリゾーンを作成し、lync.internalでContoso.internalのセカンダリゾーンを作成します。 これが複製されていることを確認してください。



その後、ドメイン間の一方向の信頼を高めることに進むことができます。









Lync.internalドメインの場合、Contoso.internalの信頼は発信の信頼になり、Contoso.internalドメインの場合、Lync.internalの信頼は着信の信頼になります。



信頼を作成した後、それが機能している信頼プロパティの[検証]ボタンで常に確認します。 このようなスキームでの作業に関する多くの問題は、信頼の不適切な機能に関係しています。

DNSセットアップ

Lyncクライアントがユーザードメインcontoso.internalから正しく機能するには、タイプAの2つのレコードをこのドメインのDNSに追加する必要があります。

• Meet.contoso.internal
• Sip.contoso.internal

両方のエントリは、lync.internalドメインのLyncサーバーIPを指す必要があります。

カスタム設定

ドメインごとに、便宜のためにOU Lyncユーザーを作成します。 contoso.internalドメインのこのOUで、通常の方法でアカウントを作成します。 私の例では、これらは2つのLyncTestおよびLyncTest2アカウントです。



同様のOUのlync.internalドメインで、同様のユーザーを作成します。 パスワードは関係ありません。 作成したら、これらのアカウントのステータスを無効に設定します。







Lync 2013コントロールパネルを起動し、作成および無効化されたアカウントを1つずつLyncシステムに追加します。







エントリを追加するときに、次のプロパティを指定します







つまり sipアドレスをcontoso.internalドメインからのアドレスとして指定します。



追加するアカウントごとにこのプロセスを繰り返します。

SID設定

Contoso.internalドメインで、AD U＆Cスナップインを開き、表示モードを詳細モードに切り替えます。







Lyncで使用されるアカウントごとに、次の操作を実行します。アカウントプロパティに移動し、属性エディターのタブを開いて、 ObjectSIDパラメーターの値をUSBスティックにアンロードします。







各値がlyncドメインのアカウントと一致する必要があることを忘れないでください。 社内



ところで、Lyncクライアントが最初の起動時にクライアントにユーザー名を入力することを要求しないように、ProxyAddress属性フィールドにsipアドレスを書き込むのは非常に便利です。 アドレスはsip：name @ domainの形式である必要があります。 つまり 私たちの場合、これはユーザーLyncTest2 sip：lynctest2@contoso.internalの場合：







その後、Lync.internalドメインに移動します。 なぜなら ここには2003サーバーがあり、属性の編集にはADSIeditスナップインが必要です。 配布ディスクにあるサポートツールキットに含まれています。 このスナップインがない場合は、これらのユーティリティを展開します。



ADSIeditを実行し、lync.internalドメインでバックアップアカウントを見つけます。







それらの中にmsRTCSIP-OriginatorSid属性を見つけ、それぞれのアカウントについてObjectSidから以前に保存された値をそれぞれ規定します。



同時に、CAのルート証明書をアンロードし、リムーバブルメディアに保存します。 彼は私たちにとって有用です。

クライアントの起動

contoso.internalドメインでは、Lync（この例では、LyncTestまたはLyncTest2のいずれか）を使用する準備ができているユーザーとして作業マシンにアクセスします。



Lync 2013クライアントの起動と...







証明書エラーが表示されます：







これは、以前にアップロードされたCA証明書が役立つ場所です。 何らかの方法で、この証明書を信頼されたルート証明機関コンテナーに表示されるように、Lyncで動作するマシンに（たとえばグループポリシーを介して、または手動で）配布します。







ポリシーを更新した後、Lync 2013クライアントを再度起動すると、クライアントにパスワード要求が表示されます。 OKをクリックしてください。 しばらくすると、接続が行われます。



それだけです



CRLを忘れないでください。 証明書失効シートは、Lyncクライアントが利用できる必要があります。 そうしないと、10日後、入り口にいるクライアントは失効した証明書を確認できなくなり、ログイン手順に5〜7分以上かかります。 ユーザーを激怒させます。



もちろん、グループポリシーを設定することにより、すでに受信したCRLの有効性を無限に高めることができます。 しかし、これはまったく異なる話です。 がんばって。