リソース フォレスト トポロジの展開Deploy a resource forest topology

次のセクションでは、ハイブリッドシナリオで Skype for Business 機能を提供するために、リソース/ユーザーフォレストモデルに複数のフォレストがある環境を構成する方法について説明します。The following sections provide guidance on how to configure an environment that has multiple forests in a resource/user forest model to provide Skype for Business functionality in a hybrid scenario.

ハイブリッドの複数フォレスト環境

トポロジの要件Topology requirements

複数のユーザーフォレストがサポートされています。Multiple user forests are supported. 以下の点にご注意ください。Keep the following in mind:

ユーザーのホームの考慮事項User homing considerations

オンプレミスに所属する Skype for Business ユーザーは、オンプレミスまたはオンラインの Exchange を持つことができます。Skype for Business users homed on premises can have Exchange homed on premises or online. Skype for Business Online ユーザーは、Exchange Online を使用して最適な環境を実現する必要があります。ただし、これは必須ではありません。Skype for Business Online users should use Exchange Online for an optimal experience; however, this is not required. どちらの場合も、Skype for Business を実装するために、オンプレミスの Exchange が必要になることはありません。Exchange on premises is not required to implement Skype for Business in either case.

フォレストの信頼を構成するConfigure forest trusts

リソースフォレストのトポロジでは、Skype for Business Server をホストするリソースフォレストは、それにアクセスするユーザーアカウントを含む各アカウントフォレストを信頼する必要があります。In a resource forest topology, the resource forests hosting Skype for Business Server must trust each account forest that contains users' accounts that will access it. 複数のユーザーフォレストが存在する場合、フォレスト間認証を有効にするには、これらのフォレストの信頼のそれぞれで名前サフィックスルーティングが有効になっていることが重要です。If you have multiple user forests, to enable cross-forest authentication it is important that Name Suffix Routing is enabled for each of these forest trusts. 手順については、「フォレストの信頼を管理する」を参照してください。For instructions, see Managing Forest Trusts. 別のフォレストに展開されている Exchange サーバーを使用している場合、Skype for Business ユーザー向けの機能を提供するには、Exchange をホストするフォレストが Skype for Business Server をホストしているフォレストを信頼している必要があります。If you have Exchange Server deployed in an another forest and it provides functionality for Skype for Business users, the forest hosting Exchange must trust the forest hosting Skype for Business Server. たとえば、Exchange がアカウントフォレストに展開されている場合、この構成では、アカウントと Skype for Business の両方のフォレストの間に双ウェイの信頼が必要になります。For example, if Exchange were deployed in the account forest, this would effectively mean a two-way trust between account and Skype for Business forests is required in that configuration.

Skype for Business をホストするフォレストにアカウントを同期するSynchronize accounts into the forest hosting Skype for Business

Skype for Business Server が1つのフォレスト (リソースフォレスト) に展開されているが、1つ以上の他のフォレスト (アカウントフォレスト) でユーザーに機能を提供する場合は、他のフォレスト内のユーザーが、Skype for Business Server が展開されているフォレスト内の無効なユーザーオブジェクトとして表される必要があります。When Skype for Business Server is deployed in one forest (a resource forest), but provides functionality to users in one or more other forests (account forests), users in the other forests must be represented as disabled user objects in the forest where Skype for Business Server is deployed. Microsoft Identity Manager などの id 管理製品を展開して、アカウントフォレストから Skype for Business Server が展開されているフォレストにユーザーをプロビジョニングおよび同期するように構成する必要があります。An identity management product, such as Microsoft Identity Manager, needs to be deployed and configured to provision and synchronize the users from the account forests into the forest where Skype for Business Server is deployed. ユーザーが、Skype for Business Server をホストしているフォレストの無効なユーザーオブジェクトとして同期されている必要があります。Users must be synchronized into the forest hosting Skype for Business Server as disabled user objects. Azure Active Directory Connect は、Skype で使用するために、連絡先を Azure AD に正しく同期しないため、ユーザーを Active Directory 連絡先オブジェクトとして同期することはできません。Users cannot be synchronized as Active Directory contact objects, because Azure Active Directory Connect will not properly synchronize contacts into Azure AD for use with Skype.

複数フォレストの構成に関係なく、Skype for Business Server をホストしているフォレストは、同じフォレストに存在する有効なユーザーにも機能を提供できます。Regardless of any multi-forest configuration, the forest hosting Skype for Business Server can also provide functionality for any enabled users that exist in the same forest.

適切な id 同期を取得するには、次の属性を同期する必要があります。To get proper identity synchronization, the following attributes need to be synchronized:

ユーザーフォレストUser forests リソースフォレストResource forests
選択されたアカウントリンク属性chosen account link attribute
選択されたアカウントリンク属性chosen account link attribute
mailmail
mailmail
ProxyAddressesProxyAddresses
ProxyAddressesProxyAddresses
ObjectSIDObjectSID
msRTCSIP-の場合は、SidmsRTCSIP-OriginatorSID

選択されたアカウントリンク属性がソースアンカーとして使用されます。The chosen account link attribute will be used as the Source Anchor. 使用する必要がある、別の不変の属性がある場合は、これを行うことができます。AD FS の要求ルールを編集して、AAD Connect 構成中に属性を選択する必要があります。If you have a different and immutable attribute that you would prefer to use, you may do so; just be sure to edit the AD FS claims rule and select the attribute during the AAD Connect configuration.

フォレスト間で Upn を同期しません。Do not sync the UPNs between the forests. テスト中に、複数のフォレストで同じ UPN を使用できないため、各ユーザーフォレストに一意の UPN を使用する必要があることがわかりました。We found during testing that we needed to use a unique UPN for each user forest, as you cannot use the same UPN across multiple forests. その結果、UPN を同期したり、同期したりしないようにするための2つの可能性が提供されました。As a result, we were presented with two possibilities, to synchronize the UPN or to not synchronize.

  • 各ユーザーフォレストの一意の UPN がリソースフォレスト内の関連付けられた無効なオブジェクトと同期されていない場合、シングルサインオン (SSO) は、少なくとも初回のサインイン (ユーザーがパスワードを保存するオプションを選択したと仮定) に対して中断されます。If the unique UPN from each user forest was not synchronized to the associated disabled object in the resource forest, single sign-on (SSO) would be broken for at least the initial sign-in attempt (assuming the user selected the option to save password). Skype for Business クライアントでは、SIP/UPN の値が同じであると仮定します。In the Skype for Business client, we assume that the SIP/UPN values are the same. このシナリオの SIP アドレスは user@company.com ですが、ユーザーフォレスト内の有効なオブジェクトの UPN は事実上 user@contoso.company.com ので、最初のログイン試行は失敗し、ユーザーは資格情報の入力を求められます。Since the SIP address in this scenario is user@company.com, but the UPN of the enabled object in the user forest is in fact user@contoso.company.com, the initial login attempt would fail and the user would be prompted to enter credentials. 正しい UPN を入力すると、ユーザーフォレスト内のドメインコントローラーに対して認証要求が完了し、サインインが成功します。Upon entering their correct/actual UPN, the authentication request would be completed against the domain controllers in the user forest, and sign-in would be successful.

  • 各ユーザーフォレストからの一意の UPN がリソースフォレスト内の関連付けられている無効なオブジェクトと同期されている場合、AD FS 認証は失敗します。If the unique UPN from each user forest was synchronized to the associated disabled object in the resource forest, AD FS authentication would fail. 照合ルールは、無効にされ、認証に使用できなかったリソースフォレスト内のオブジェクトの UPN を検索します。The matching rule would find the UPN on the object in the resource forest, which was disabled and could not be used for authentication.

Microsoft 365 または Office 365 組織を作成するCreate a Microsoft 365 or Office 365 organization

次に、展開で使用するために Microsoft 365 または Office 365 組織を準備する必要があります。You will next need to provision a Microsoft 365 or Office 365 organization to use with your deployment. 詳細については、「 Microsoft のクラウドサービスのサブスクリプション、ライセンス、アカウント、およびテナント」を参照してください。For more information, please see Subscriptions, licenses, accounts, and tenants for Microsoft's cloud offerings.

Active Directory フェデレーションサービスを構成するConfigure Active Directory Federation Services

テナントが作成されたら、各ユーザーフォレストで Active Directory フェデレーションサービス (AD FS) を構成する必要があります。Once you have a tenant, you will need to configure Active Directory Federation Services (AD FS) in each of the user forests. これは、フォレストごとに一意の SIP および SMTP アドレスとユーザープリンシパル名 (UPN) があることを前提としています。This assumes you have a unique SIP and SMTP address and User Principal Name (UPN) for each forest. AD FS はオプションであり、シングルサインオン (SSO) を取得するためにここで使用されます。AD FS is optional and is used here to get single sign-on (SSO). パスワード同期を使用する DirSync もサポートされており、AD FS の代わりに使用することもできます。DirSync with Password Sync is also supported and can also be used in place of AD FS.

SIP/SMTP および Upn が一致する展開のみがテストされました。Only deployments with matching SIP/SMTP and UPNs were tested. 対応する SIP/SMTP/Upn がないと、Exchange 統合および SSO の問題などの機能が低下する可能性があります。Not having matching SIP/SMTP/UPNs may result in reduced functionality, such as problems with Exchange integration and SSO.

各フォレストのユーザーに対して一意の SIP/SMTP/UPN を使用しない限り、AD FS が展開されている場所に関係なく、SSO の問題が発生する可能性があります。Unless you use a unique SIP/SMTP/UPN for users from each forest, you can still run into SSO problems, regardless of where AD FS is deployed:

  • AD FS ファームが各ユーザーフォレストに展開されているリソース/ユーザーフォレスト間の一方向または双方向の信頼。すべてのユーザーは共通の SIP/SMTP ドメインを共有しますが、ユーザーフォレストごとに一意の UPN を共有します。One-way or two-way trusts between resource/user forests with AD FS farm deployed in each user forest, all users share common SIP/SMTP domain but unique UPN for each user forest.

  • リソースフォレスト内にのみ展開された AD FS ファームを使用した、リソース/ユーザーフォレスト間の双方向の信頼。すべてのユーザーは共通の SIP/SMTP ドメインを共有しますが、ユーザーフォレストごとに一意の UPN を共有します。Two-way trusts between resource/user forests with AD FS farm deployed only in resource forest, all users share common SIP/SMTP domain but unique UPN for each user forest.

各ユーザーフォレストに AD FS ファームを配置し、フォレストごとに一意の SIP/SMTP/UPN を使用することで、両方の問題を解決します。By placing an AD FS farm in each user forest and using a unique SIP/SMTP/UPN for each forest, we resolve both issues. 認証の試行中に、特定のユーザーフォレスト内のアカウントのみが検索され、照合されます。Only the accounts in that specific user forest would be searched and matched during authentication attempts. これは、よりシームレスな認証プロセスを提供するのに役立ちます。This will help provide a more seamless authentication process.

これは、Windows Server 2012 R2 AD FS の標準的な展開であり、続行する前に動作する必要があります。This will be a standard deployment of the Windows Server 2012 R2 AD FS and should be working before continuing. 手順については、「 Microsoft 365 または Office 365 の AD FS 2012 R2 をインストールする方法」を参照してください。For instructions, see How To Install AD FS 2012 R2 For Microsoft 365 or Office 365.

いったん展開したら、前に選択したソースアンカーと一致するようにクレームルールを編集する必要があります。Once deployed, you then have to edit the claims rule to match the Source Anchor selected earlier. AD FS MMC の [証明書利用者信頼] の下で、[ microsoft 365 Identity platform ] または [ Microsoft Office 365 Identity platform] を右クリックし、[要求規則の編集] を選択します。In the AD FS MMC, under Relying Party Trusts, right-click Microsoft 365 Identity Platform or Microsoft Office 365 Identity Platform, and then select Edit Claim Rules. 最初のルールを編集し、ObjectSID をemployeeNumberに変更します。Edit the first rule, and change ObjectSID to employeeNumber.

複数フォレストの [ルールの編集] 画面

AAD 接続を構成するConfigure AAD Connect

リソースフォレストのトポロジでは、リソースフォレストとすべてのアカウントフォレストのユーザー属性を Azure AD に同期する必要があります。In resource forest topologies, it’s required that user attributes from both the resource forest and any account forests(s) are synchronized into Azure AD. 最も簡単にこれを行うには、Azure AD Connect を使用して、有効になっているユーザーアカウントと Skype for Business が含まれているフォレストのすべてのフォレストから、ユーザー id を同期させ、結合するようにします。The simplest and recommended way to do this is to have Azure AD Connect synchronize and merge user identities from all forests that have enabled user accounts and the forest that contains Skype for Business. 詳細については、「 Skype for business および Teams 用に AZURE AD Connect を構成する」を参照してください。For details see, Configure Azure AD Connect for Skype for Business and Teams.

AAD Connect では、アカウントフォレストとリソースフォレスト間でのオンプレミスの同期は提供されないことに注意してください。Note that AAD Connect does not provide synchronization on premises between the account and resource forests. これは、前に説明したように、Microsoft Identity Manager または同様の製品を使用して個別に構成する必要があります。That must be separately configured using Microsoft Identity Manager or similar product, as described earlier.

完了後に AAD Connect が結合されると、metaverse 内のオブジェクトを調べると、次のような内容が表示されます。When finished and AAD Connect is merging, if you look at an object in the metaverse, you should see something similar to this:

複数フォレストの Metaverse オブジェクト画面

緑色で強調表示されている属性は、Microsoft 365 または Office 365、ユーザーフォレストから黄色、青がリソースフォレストからマージされました。The green highlighted attributes were merged from Microsoft 365 or Office 365, the yellow are from the user forest, and the blue are from the resource forest.

これはテストユーザーなので、この1101場合は以前に選択されている employeeNumber である、Microsoft 365 または Office 365 から、cloudSourceAnchor とリソースフォレストオブジェクトを AAD Connect で識別していることを確認できます。This is a test user, and you can see that AAD Connect has identified the sourceAnchor and the cloudSourceAnchor from the user and the resource forest objects from Microsoft 365 or Office 365, in our case 1101, which is the employeeNumber selected earlier. その後、このオブジェクトを上記の表示に結合することができました。It then was able to merge this object into what you see above.

詳細については、「オンプレミスのディレクトリと Azure Active Directory を統合する」を参照してください。For more information, see Integrate your on-premises directories with Azure Active Directory.

AAD Connect は、次の点を除き、既定の設定を使用してインストールする必要があります。AAD Connect should be installed using the defaults, except for the following:

  1. AD FS が既に展開および稼働しているシングルサインイン。 [構成しない] を選択します。Single sign-in - with AD FS already deployed and working: Select Do not configure.

  2. ディレクトリを接続します。すべてのドメインを追加します。Connect your directories: Add all of the domains.

  3. オンプレミスディレクトリでユーザーを識別する: [複数のディレクトリにユーザー id が存在する] を選択し、 ObjectSID属性とmsExchangeMasterAccountSID属性を選択します。Identify users in on-premises directories: Select User identities exist across multiple directories, and select the ObjectSID and msExchangeMasterAccountSID attributes.

  4. [Azure AD でユーザーを識別する: ソースアンカー]:適切な sourceanchor 属性(ユーザープリンシパル名- UserPrincipalName) を選択した後に選択した属性を選択します。Identify users in Azure AD: Source Anchor: Select the attribute you've chosen after reading Selecting a good sourceAnchor attribute, User Principal Name - userPrincipalName.

  5. オプション機能: Exchange ハイブリッドが展開されているかどうかを選択します。Optional features: Select whether you have Exchange hybrid deployed.

    注意

    Exchange Online のみを使用している場合は、CNAME リダイレクトにより、自動検出の際に OAuth エラーに関して問題が発生する可能性があります。If you have only Exchange Online, there could be an issue with OAuth failures during autodiscover because of CNAME redirection. これを修正するには、Skype for Business Server 管理シェルから次のコマンドレットを実行して、Exchange 自動検出 URL を設定する必要があります。To correct this, you will need to set the Exchange Autodiscover URL by running the following cmdlet from the Skype for Business Server Management Shell:

    Set-CsOAuthConfiguration -ExchangeAutoDiscoverURL https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc 
    
  6. AD FS ファーム: [既存の Windows Server 2012 R2 AD fs ファームを使用する] を選択し、ad fs サーバーの名前を入力します。AD FS Farm: Select Use an existing Windows Server 2012 R2 AD FS farm and enter the name of the AD FS server.

  7. ウィザードを終了し、必要な検証を実行します。Finish the wizard and perform the necessary validations.

Skype for Business Server のハイブリッド接続を構成するConfigure hybrid connectivity for Skype for Business Server

Skype for Business ハイブリッドを構成するためのベストプラクティスに従います。Follow the best practices for configuring Skype for Business hybrid. 詳細については、「ハイブリッド接続を計画する」および「ハイブリッド接続を構成する」を参照してください。For more information information, see Plan hybrid connectivity and Configure hybrid connectivity.

Exchange Server のハイブリッド接続を構成するConfigure hybrid connectivity for Exchange Server

必要に応じて、Exchange ハイブリッドを構成するためのベストプラクティスに従います。If necessary, follow the best practices for configuring Exchange hybrid. 詳細については、「 Exchange Server のハイブリッド展開」を参照してください。For more information, see Exchange Server Hybrid Deployments.