Azure での Active Directory フェデレーション サービスのデプロイDeploying Active Directory Federation Services in Azure

AD FS は、単純かつ安全な ID フェデレーションと Web シングル サインオン (SSO) 機能を実現します。AD FS provides simplified, secured identity federation and Web single sign-on (SSO) capabilities. Azure AD または O365 とのフェデレーションによって、ユーザーはオンプレミスの資格情報を認証に使用し、クラウド内のあらゆるリソースにアクセスすることができます。Federation with Azure AD or O365 enables users to authenticate using on-premises credentials and access all resources in cloud. そのため、オンプレミスとクラウドの両方のリソースに確実にアクセスできるよう、AD FS インフラストラクチャには、高い可用性を確保することが重要となります。As a result, it becomes important to have a highly available AD FS infrastructure to ensure access to resources both on-premises and in the cloud. AD FS を Azure にデプロイすると、必要な高可用性を最小限の手間で確保できます。Deploying AD FS in Azure can help achieve the high availability required with minimal efforts. AD FS を Azure にデプロイする利点はいくつかありますが、その一部を以下に示します。There are several advantages of deploying AD FS in Azure, a few of them are listed below:

  • 高可用性 - Azure の可用性セットを使用してインフラストラクチャに高い可用性を確保できます。High Availability - With the power of Azure Availability Sets, you ensure a highly available infrastructure.
  • 拡張が容易 - パフォーマンスを強化する必要がある場合、Easy to Scale – Need more performance? Azure からの簡単なクリック操作で簡単に、より高性能なマシンに移行できます。Easily migrate to more powerful machines by just a few clicks in Azure
  • 地域を越えた冗長性 - Azure Geo Redundancy によって地域を越えた世界規模での高可用性がインフラストラクチャに確保されます。Cross-Geo Redundancy – With Azure Geo Redundancy you can be assured that your infrastructure is highly available across the globe
  • 管理しやすい - 高度に単純化された管理オプションが Azure ポータルに用意されているため、インフラストラクチャ管理の手間がかからず、ごく簡単に管理することができます。Easy to Manage – With highly simplified management options in Azure portal, managing your infrastructure is very easy and hassle-free

設計原則Design principles

Deployment design

上の図は、これから AD FS インフラストラクチャを Azure にデプロイしようとする場合に推奨される基本的なトポロジを示したものです。The diagram above shows the recommended basic topology to start deploying your AD FS infrastructure in Azure. このトポロジの各種コンポーネントの要点を以下に示します。The principles behind the various components of the topology are listed below:

  • DC / ADFS サーバー: ユーザー数が 1,000 人未満である場合、ドメイン コントローラーに AD FS ロールをインストールするだけでかまいません。DC / ADFS Servers: If you have fewer than 1,000 users you can simply install AD FS role on your domain controllers. ドメイン コントローラーへのパフォーマンスの影響が懸念される場合や、ユーザー数が 1,000 人を超える場合は、単独のサーバーに AD FS をデプロイします。If you do not want any performance impact on the domain controllers or if you have more than 1,000 users, then deploy AD FS on separate servers.
  • WAP サーバー : ユーザーが会社のネットワークに接続していないときでも AD FS に到達できるよう WAP (Web アプリケーション プロキシ) サーバーをデプロイする必要があります。WAP Server – it is necessary to deploy Web Application Proxy servers, so that users can reach the AD FS when they are not on the company network also.
  • DMZ: Web アプリケーション プロキシ サーバーは DMZ に配置し、DMZ と内部サブネットとの間の通信には TCP/443 アクセスのみを許可します。DMZ: The Web Application Proxy servers will be placed in the DMZ and ONLY TCP/443 access is allowed between the DMZ and the internal subnet.
  • ロード バランサー: AD FS サーバーと Web アプリケーション プロキシ サーバーの高可用性を確保するために、AD FS サーバーには内部ロード バランサーの使用を、Web アプリケーション プロキシ サーバーには Azure Load Balancer の使用をそれぞれお勧めします。Load Balancers: To ensure high availability of AD FS and Web Application Proxy servers, we recommend using an internal load balancer for AD FS servers and Azure Load Balancer for Web Application Proxy servers.
  • 可用性セット: AD FS のデプロイに冗長性を確保するために、同様のワークロードを処理する複数の仮想マシンは、1 つの可用性セットとしてグループ化するようお勧めします。Availability Sets: To provide redundancy to your AD FS deployment, it is recommended that you group two or more virtual machines in an Availability Set for similar workloads. このように構成されていれば、計画済みまたは計画外メンテナンスの間も、少なくとも 1 つの仮想マシンを使用できます。This configuration ensures that during either a planned or unplanned maintenance event, at least one virtual machine will be available
  • ストレージ アカウント: ストレージ アカウントは 2 つ用意することをお勧めします。Storage Accounts: It is recommended to have two storage accounts. ストレージ アカウントが 1 つである場合、単一障害点が形成され、万一ストレージ アカウントがダウンした場合に、環境が利用できなくなる可能性があります。Having a single storage account can lead to creation of a single point of failure and can cause the deployment to become unavailable in an unlikely scenario where the storage account goes down. ストレージ アカウントが 2 つあれば、障害系統ごとに 1 つのストレージ アカウントを関連付けることができます。Two storage accounts will help associate one storage account for each fault line.
  • ネットワークの分離: Web アプリケーション プロキシ サーバーは、単独の DMZ ネットワークにデプロイする必要があります。Network segregation: Web Application Proxy servers should be deployed in a separate DMZ network. 1 つの仮想ネットワークを 2 つのサブネットに分割したうえで、分離したサブネットに Web アプリケーション プロキシ サーバーをデプロイすることができます。You can divide one virtual network into two subnets and then deploy the Web Application Proxy server(s) in an isolated subnet. 単にネットワーク セキュリティ グループの設定をサブネットごとに構成し、その 2 つのサブネット間に必要な通信のみを許可してください。You can simply configure the network security group settings for each subnet and allow only required communication between the two subnets. 以降、デプロイのシナリオに従って詳しく説明します。More details are given per deployment scenario below

AD FS を Azure にデプロイする手順Steps to deploy AD FS in Azure

このセクションで取り上げる手順は、以下に示した AD FS インフラストラクチャを Azure にデプロイするうえでの指針を概説したものです。The steps mentioned in this section outline the guide to deploy the below depicted AD FS infrastructure in Azure.

1.ネットワークをデプロイする1. Deploying the network

既に述べたように、1 つの仮想ネットワークに 2 つのサブネットを作成するか、まったく異なる 2 つの仮想ネットワーク (VNet) を作成することができます。As outlined above, you can either create two subnets in a single virtual network or else create two completely different virtual networks (VNet). この記事では、1 つの仮想ネットワークをデプロイして 2 つのサブネットに分割する方法について重点的に説明します。This article will focus on deploying a single virtual network and divide it into two subnets. 現時点では、その方が簡単です。2 つの独立した VNet を使用した場合、通信に VNet 間ゲートウェイが必要となります。This is currently an easier approach as two separate VNets would require a VNet to VNet gateway for communications.

1.1 仮想ネットワークを作成する1.1 Create virtual network

Create virtual network

Azure ポータルで仮想ネットワークを選択すると、その仮想ネットワークと 1 つのサブネットを 1 回のクリックですぐにデプロイできます。In the Azure portal, select virtual network and you can deploy the virtual network and one subnet immediately with just one click. INT サブネットも定義されて VM を追加する準備が整います。INT subnet is also defined and is ready now for VMs to be added. 次の手順でこのネットワークにもう 1 つのサブネット (DMZ サブネット) を追加します。The next step is to add another subnet to the network, i.e. the DMZ subnet. DMZ サブネットを作成するには、次の手順を実行するだけです。To create the DMZ subnet, simply

  • 新しく作成したネットワークを選択するSelect the newly created network
  • プロパティからサブネットを選択するIn the properties select subnet
  • サブネット パネルで追加ボタンをクリックするIn the subnet panel click on the add button
  • サブネットの名前とアドレス空間情報を指定してサブネットを作成するProvide the subnet name and address space information to create the subnet

サブネット

Subnet DMZ

1.2.ネットワーク セキュリティ グループを作成する1.2. Creating the network security groups

ネットワーク セキュリティ グループ (NSG) には、仮想ネットワークの VM インスタンスに対するネットワーク トラフィックを許可または拒否する一連のアクセス制御リスト (ACL) 規則が含まれています。A Network security group (NSG) contains a list of Access Control List (ACL) rules that allow or deny network traffic to your VM instances in a Virtual Network. NSG は、サブネットまたはそのサブネット内の個々の VM インスタンスと関連付けることができます。NSGs can be associated with either subnets or individual VM instances within that subnet. NSG がサブネットに関連付けられている場合、ACL 規則はそのサブネット内のすべての VM インスタンスに適用されます。When an NSG is associated with a subnet, the ACL rules apply to all the VM instances in that subnet. このガイドでは、その目的上、内部ネットワーク用と DMZ 用の 2 つの NSG を作成します。For the purpose of this guidance, we will create two NSGs: one each for an internal network and a DMZ. それぞれ NSG_INT と NSG_DMZ という名前を付けます。They will be labeled NSG_INT and NSG_DMZ respectively.

Create NSG

NSG の作成直後に存在する受信規則と送信規則は、いずれも 0 個です。After the NSG is created, there will be 0 inbound and 0 outbound rules. それぞれのサーバー上にロールがインストールされ正しく動作する状態になってから、必要なセキュリティ レベルに従って受信規則と送信規則を作成することができます。Once the roles on the respective servers are installed and functional, then the inbound and outbound rules can be made according to the desired level of security.

Initialize NSG

NSG の作成後、NSG_INT をサブネット INT に、NSG_DMZ をサブネット DMZ に関連付けます。After the NSGs are created, associate NSG_INT with subnet INT and NSG_DMZ with subnet DMZ. 以下のスクリーンショットはその例です。An example screenshot is given below:

NSG configure

  • [サブネット] をクリックしてサブネットのパネルを開きます。Click on Subnets to open the panel for subnets
  • NSG に関連付けるサブネットを選択します。Select the subnet to associate with the NSG

構成後の [サブネット] のパネルは次のように表示されている必要があります。After configuration, the panel for Subnets should look like below:

Subnets after NSG

1.3.オンプレミスへの接続を作成する1.3. Create Connection to on-premises

Azure にドメイン コントローラー (DC) をデプロイするためには、オンプレミスとの接続が必要となります。We will need a connection to on-premises in order to deploy the domain controller (DC) in azure. Azure には、オンプレミスのインフラストラクチャを Azure のインフラストラクチャに接続するためのさまざまな接続方法が用意されています。Azure offers various connectivity options to connect your on-premises infrastructure to your Azure infrastructure.

  • ポイント対サイトPoint-to-site
  • Virtual Network サイト間Virtual Network Site-to-site
  • ExpressRouteExpressRoute

推奨されるのは、ExpressRoute を使用する方法です。It is recommended to use ExpressRoute. ExpressRoute を使用すると、Azure のデータセンターとオンプレミスや共用環境にあるインフラストラクチャ間にプライベート接続を作成できます。ExpressRoute lets you create private connections between Azure datacenters and infrastructure that’s on your premises or in a co-location environment. ExpressRoute 接続では、公共のインターネットを利用できません。ExpressRoute connections do not go over the public Internet. ExpressRoute 接続は一般的なインターネットでの接続よりも信頼性が高く、高速で、待ち時間が短く、セキュリティの高い接続を提供します。They offer more reliability, faster speeds, lower latencies and higher security than typical connections over the Internet. ExpressRoute の使用をお勧めしますが、所属する組織に合った任意の接続方法を選ぶことができます。While it is recommended to use ExpressRoute, you may choose any connection method best suited for your organization. ExpressRoute と ExpressRoute を使用した各種の接続方法の詳細については、「 ExpressRoute の技術概要」を参照してください。To learn more about ExpressRoute and the various connectivity options using ExpressRoute, read ExpressRoute technical overview.

2.ストレージ アカウントを作成する2. Create storage accounts

高い可用性を維持し、1 つのストレージ アカウントへの依存を回避するために、ストレージ アカウントは 2 つ作成することができます。In order to maintain high availability and avoid dependence on a single storage account, you can create two storage accounts. 可用性セットごとの 2 つのグループにマシンを分けたうえで、それぞれのグループに別個のストレージ アカウントを割り当てます。Divide the machines in each availability set into two groups and then assign each group a separate storage account.

Create storage accounts

手順 3.可用性セットを作成する3. Create availability sets

それぞれのロール (DC/AD FS と WAP) について、最低 2 つのマシンを含んだ可用性セットを作成します。For each role (DC/AD FS and WAP), create availability sets that will contain 2 machines each at the minimum. そうすることで各ロールの可用性を高めることができます。This will help achieve higher availability for each role. 可用性セットを作成する際は、次の点についての意思決定が必須となります。While creating the availability sets, it is essential to decide on the following:

  • 障害ドメイン: 同じ障害ドメインの仮想マシンは、同じ電源と物理ネットワーク スイッチを共有します。Fault Domains: Virtual machines in the same fault domain share the same power source and physical network switch. 障害ドメインは 2 以上とすることをお勧めします。A minimum of 2 fault domains are recommended. ここでは既定値の 3 をそのまま使用します。The default value is 3 and you can leave it as is for the purpose of this deployment
  • 更新ドメイン: 同じ更新ドメインに属しているマシンは、更新時に一緒に再起動されます。Update domains: Machines belonging to the same update domain are restarted together during an update. 更新ドメインは 2 以上とすることをお勧めします。You want to have minimum of 2 update domains. ここでは既定値の 5 をそのまま使用します。The default value is 5 and you can leave it as is for the purpose of this deployment

可用性セット

次の可用性セットを作成します。Create the following availability sets

可用性セットAvailability Set 役割Role 障害ドメインFault domains 更新ドメインUpdate domains
contosodcsetcontosodcset DC/ADFSDC/ADFS 33 55
contosowapsetcontosowapset WAPWAP 33 55

4.仮想マシンをデプロイする4. Deploy virtual machines

次に、インフラストラクチャ内の各ロールのホストとなる仮想マシンをデプロイします。The next step is to deploy virtual machines that will host the different roles in your infrastructure. それぞれの可用性セットには、最低でも 2 つのマシンをデプロイすることをお勧めします。A minimum of two machines are recommended in each availability set. 基本的なデプロイでは 4 つの仮想マシンを作成します。Create four virtual machines for the basic deployment.

マシンMachine 役割Role サブネットSubnet 可用性セットAvailability set ストレージ アカウントStorage account IP アドレスIP Address
contosodc1contosodc1 DC/ADFSDC/ADFS INTINT contosodcsetcontosodcset contososac1contososac1 静的Static
contosodc2contosodc2 DC/ADFSDC/ADFS INTINT contosodcsetcontosodcset contososac2contososac2 静的Static
contosowap1contosowap1 WAPWAP DMZDMZ contosowapsetcontosowapset contososac1contososac1 静的Static
contosowap2contosowap2 WAPWAP DMZDMZ contosowapsetcontosowapset contososac2contososac2 静的Static

お気付きかもしれませんが、NSG が指定されていません。As you might have noticed, no NSG has been specified. これは NSG が、Azure ではサブネット レベルで使用できるためです。This is because azure lets you use NSG at the subnet level. マシンのネットワーク トラフィックは、サブネットまたは NIC オブジェクトに関連付けられている個々の NSG を使って制御できます。Then, you can control machine network traffic by using the individual NSG associated with either the subnet or else the NIC object. 詳しくは、「 ネットワーク セキュリティ グループ (NSG) について」をご覧ください。Read more on What is a Network Security Group (NSG). DNS が管理下にある場合は、静的 IP アドレスをお勧めします。Static IP address is recommended if you are managing the DNS. Azure DNS を使用し、ドメインの DNS レコードの方から、対応する Azure FQDN で新しいマシンを参照することができます。You can use Azure DNS and instead in the DNS records for your domain, refer to the new machines by their Azure FQDNs. デプロイの完了後、[仮想マシン] ウィンドウは次のように表示されている必要があります。Your virtual machine pane should look like below after the deployment is completed:

Virtual Machines deployed

5.ドメイン コントローラー / AD FS サーバーを構成する5. Configuring the domain controller / AD FS servers

受信要求を認証するためには、AD FS がドメイン コントローラーに問い合わせを行う必要があります。In order to authenticate any incoming request, AD FS will need to contact the domain controller. 認証のたびに Azure がオンプレミスの DC とやり取りするのでは無駄が大きいため、ドメイン コントローラーのレプリカを Azure にデプロイすることをお勧めします。To save the costly trip from Azure to on-premises DC for authentication, it is recommended to deploy a replica of the domain controller in Azure. 高い可用性を確保するために、少なくとも 2 つのドメイン コントローラーから成る可用性セットを作成することをお勧めします。In order to attain high availability, it is recommended to create an availability set of at-least 2 domain controllers.

ドメイン コントローラーDomain controller 役割Role ストレージ アカウントStorage account
contosodc1contosodc1 レプリカReplica contososac1contososac1
contosodc2contosodc2 レプリカReplica contososac2contososac2
  • 2 台のサーバーをレプリカ ドメイン コントローラー (DNS を含む) として昇格させます。Promote the two servers as replica domain controllers with DNS
  • サーバー マネージャーを使用して AD FS ロールをインストールし、AD FS サーバーを構成します。Configure the AD FS servers by installing the AD FS role using the server manager.

6.内部ロード バランサー (ILB) をデプロイする6. Deploying Internal Load Balancer (ILB)

6.1.ILB を作成する6.1. Create the ILB

ILB をデプロイするには、Azure ポータルで [ロード バランサー] を選択し、[追加] (+) をクリックします。To deploy an ILB, select Load Balancers in the Azure portal and click on add (+).

注意

メニューに [ロード バランサー] が表示されない場合は、ポータルの左下にある [参照] をクリックし、[ロード バランサー] が表示されるまでスクロールします。if you do not see Load Balancers in your menu, click Browse in the lower left of the portal and scroll until you see Load Balancers. その後、黄色の星印をクリックするとメニューに追加されます。Then click the yellow star to add it to your menu. この新しいロード バランサー アイコンを選択してパネルを開き、ロード バランサーの構成を開始してください。Now select the new load balancer icon to open the panel to begin configuration of the load balancer.

Browse load balancer

  • [名前]: ロード バランサーに適切な名前を付けます。Name: Give any suitable name to the load balancer
  • [スキーム]: このロード バランサーは AD FS サーバーの前に配置されます。つまり内部的なネットワーク接続のみを意図したものであるため、[内部] を選択します。Scheme: Since this load balancer will be placed in front of the AD FS servers and is meant for internal network connections ONLY, select “Internal”
  • [仮想ネットワーク]: AD FS をデプロイする仮想ネットワークを選択します。Virtual Network: Choose the virtual network where you are deploying your AD FS
  • [サブネット]: 内部サブネットを選択します。Subnet: Choose the internal subnet here
  • [IP アドレスの割り当て]: 静的IP Address assignment: Static

内部ロード バランサー

[作成] をクリックして ILB をデプロイすると、その ILB がロード バランサーの一覧に表示されます。After you click create and the ILB is deployed, you should see it in the list of load balancers:

Load balancers after ILB

次の手順では、バックエンド プールとバックエンド プローブを構成します。Next step is to configure the backend pool and the backend probe.

6.2.ILB バックエンド プールを構成する6.2. Configure ILB backend pool

新しく作成した ILB を [ロード バランサー] パネルで選択し、Select the newly created ILB in the Load Balancers panel. 設定パネルを開きます。It will open the settings panel.

  1. 設定パネルからバックエンド プールを選択します。Select backend pools from the settings panel
  2. [バックエンド プールの追加] パネルで [仮想マシンの追加] をクリックします。In the add backend pool panel, click on add virtual machine
  3. パネルが表示され、可用性セットを選択することができます。You will be presented with a panel where you can choose availability set
  4. AD FS の可用性セットを選択します。Choose the AD FS availability set

Configure ILB backend pool

6.3.プローブを構成する6.3. Configuring probe

[ILB 設定] パネルで [プローブ] を選択します。In the ILB settings panel, select Probes.

  1. [追加] をクリックします。Click on add
  2. プローブの詳細を入力します。a. Provide details for probe a. [名前]: プローブ名。b. Name: Probe name b. [プロトコル]: TCP。c. Protocol: TCP c. [ポート]: 443 (HTTPS)。d. Port: 443 (HTTPS) d. [間隔]: 5 (既定値) - この値は、ILB がバックエンド プール内の仮想マシンをプローブする間隔です。e. Interval: 5 (default value) – this is the interval at which ILB will probe the machines in the backend pool e. [Unhealthy threshold limit (異常しきい値)]: 2 (既定値) - これはプローブ エラーの連続回数のしきい値です。この値を超えると、ILB はバックエンド プール内の仮想マシンが応答していないと判断し、トラフィックの送信を停止します。Unhealthy threshold limit: 2 (default val ue) – this is the threshold of consecutive probe failures after which ILB will declare a machine in the backend pool non-responsive and stop sending traffic to it.

Configure ILB probe

6.4.負荷分散規則を作成する6.4. Create load balancing rules

トラフィックのバランスを効果的に調整するためには、負荷分散規則を使って ILB を構成する必要があります。In order to effectively balance the traffic, the ILB should be configured with load balancing rules. 負荷分散規則を作成するには、In order to create a load balancing rule,

  1. ILB の設定パネルから負荷分散規則を選択します。Select Load balancing rule from the settings panel of the ILB
  2. [負荷分散規則] パネルの [追加] をクリックします。Click on Add in the Load balancing rule panel
  3. [負荷分散規則の追加] パネルで、a. In the Add load balancing rule panel a. [名前]: 規則の名前を入力します。b. Name: Provide a name for the rule b. [プロトコル]: [TCP] を選択します。c. Protocol: Select TCP c. [ポート]: 443。d. Port: 443 d. [バックエンド ポート]: 443。e. Backend port: 443 e. [バックエンド プール]: AD FS クラスター用に作成しておいたプールを選択します。f. Backend pool: Select the pool you created for the AD FS cluster earlier f. [プローブ]: AD FS サーバー用に作成しておいたプローブを選択します。Probe: Select the probe created for AD FS servers earlier

Configure ILB balancing rules

6.5.DNS に ILB を反映する6.5. Update DNS with ILB

DNS サーバーに移動して、ILB の CNAME を作成します。Go to your DNS server and create a CNAME for the ILB. CNAME には、IP アドレスが ILB の IP アドレスを指すフェデレーション サービスの値を指定する必要があります。The CNAME should be for the federation service with the IP address pointing to the IP address of the ILB. たとえば ILB の DIP アドレスが 10.3.0.8 であるとき、インストールされているフェデレーション サービスが fs.contoso.com である場合は、10.3.0.8 を指す fs.contoso.com の CNAME を作成します。For example if the ILB DIP address is 10.3.0.8, and the federation service installed is fs.contoso.com, then create a CNAME for fs.contoso.com pointing to 10.3.0.8. これで fs.contoso.com についてのすべての通信は最終的に ILB に到達し、適切にルーティングされます。This will ensure that all communication regarding fs.contoso.com end up at the ILB and are appropriately routed.

7.Web アプリケーション プロキシ サーバーを構成する7. Configuring the Web Application Proxy server

7.1.AD FS サーバーに到達するための構成を Web アプリケーション プロキシ サーバーに対して行う7.1. Configuring the Web Application Proxy servers to reach AD FS servers

Web アプリケーション プロキシ サーバーが ILB の内側にある AD FS サーバーに到達するためには、%systemroot%\system32\drivers\etc\hosts にその ILB のレコードを作成する必要があります。In order to ensure that Web Application Proxy servers are able to reach the AD FS servers behind the ILB, create a record in the %systemroot%\system32\drivers\etc\hosts for the ILB. 識別名 (DN) は、フェデレーション サービスの名前 (例: fs.contoso.com) となることに注意してください。また IP には、ILB の IP アドレスを入力する必要があります (この例では 10.3.0.8)。Note that the distinguished name (DN) should be the federation service name, for example fs.contoso.com. And the IP entry should be that of the ILB’s IP address (10.3.0.8 as in the example).

7.2.Web アプリケーション プロキシ ロールをインストールする7.2. Installing the Web Application Proxy role

Web アプリケーション プロキシ サーバーから ILB の内側の AD FS サーバーに到達できる状態を確保したら、続けて Web アプリケーション プロキシ サーバーをインストールすることができます。After you ensure that Web Application Proxy servers are able to reach the AD FS servers behind ILB, you can next install the Web Application Proxy servers. Web アプリケーション プロキシ サーバーはドメインに参加しません。Web Application Proxy servers do not be joined to the domain. リモート アクセス ロールを選択して、2 つの Web アプリケーション プロキシ サーバーに Web アプリケーション プロキシ ロールをインストールします。Install the Web Application Proxy roles on the two Web Application Proxy servers by selecting the Remote Access role. サーバー マネージャーの指示に従って、WAP のインストールを実行してください。The server manager will guide you to complete the WAP installation. WAP のデプロイ方法について詳しくは、「 Web アプリケーション プロキシ サーバーをインストールし、構成する」をご覧ください。For more information on how to deploy WAP, read Install and Configure the Web Application Proxy Server.

8.インターネット接続 (パブリック) ロード バランサーをデプロイする8. Deploying the Internet Facing (Public) Load Balancer

8.1.インターネット接続 (パブリック) ロード バランサーを作成する8.1. Create Internet Facing (Public) Load Balancer

Azure ポータルで [ロード バランサー] を選択し、[追加] をクリックします。In the Azure portal, select Load balancers and then click on Add. [ロード バランサーの作成] パネルで次の情報を入力します。In the Create load balancer panel, enter the following information

  1. [名前]: ロード バランサーの名前。Name: Name for the load balancer
  2. [スキーム]: [パブリック] - このオプションを選択することで、作成するロード バランサーにパブリック アドレスが必要であるという情報が Azure に提供されます。Scheme: Public – this option tells Azure that this load balancer will need a public address.
  3. [IP アドレス]: 新しい IP アドレス (動的) を作成します。IP Address: Create a new IP address (dynamic)

インターネットに接続するロード バランサー

デプロイしたロード バランサーは、[ロード バランサー] の一覧に表示されます。After deployment, the load balancer will appear in the Load balancers list.

Load balancer list

8.2.パブリック IP に DNS ラベルを割り当てる8.2. Assign a DNS label to the public IP

新しく作成したロード バランサーのエントリを [ロード バランサー] パネルでクリックして、構成用のパネルを表示します。Click on the newly created load balancer entry in the Load balancers panel to bring up the panel for configuration. 次の手順に従ってパブリック IP の DNS ラベルを構成してください。Follow below steps to configure the DNS label for the public IP:

  1. 対象のパブリック IP アドレスをクリックします。Click on the public IP address. パブリック IP とその設定に必要なパネルが開きます。This will open the panel for the public IP and its settings
  2. [構成] をクリックします。Click on Configuration
  3. DNS ラベルを指定します。Provide a DNS label. これが、任意の場所からアクセスできるパブリック DNS ラベルになります (例: contosofs.westus.cloudapp.azure.com)。外部 DNS には、この外部ロード バランサーの DNS ラベル (contosofs.westus.cloudapp.azure.com) に解決されるフェデレーション サービスのエントリ (例: fs.contoso.com) を追加してください。This will become the public DNS label that you can access from anywhere, for example contosofs.westus.cloudapp.azure.com. You can add an entry in the external DNS for the federation service (like fs.contoso.com) that resolves to the DNS label of the external load balancer (contosofs.westus.cloudapp.azure.com).

Configure internet facing load balancer

Configure internet facing load balancer (DNS)

8.3.インターネット接続 (パブリック) ロード バランサーのバックエンド プールを構成する8.3. Configure backend pool for Internet Facing (Public) Load Balancer

内部ロード バランサーの作成と同じ手順に従って、インターネット接続 (パブリック) ロード バランサーのバックエンド プールを WAP サーバーの可用性セットとして構成します。Follow the same steps as in creating the internal load balancer, to configure the backend pool for Internet Facing (Public) Load Balancer as the availability set for the WAP servers. たとえば「contosowapset」とします。For example, contosowapset.

Configure backend pool of Internet Facing Load Balancer

8.4.プローブを構成する8.4. Configure probe

内部ロード バランサーの構成と同じ手順に従って、WAP サーバーのバックエンド プールに使用するプローブを構成します。Follow the same steps as in configuring the internal load balancer to configure the probe for the backend pool of WAP servers.

Configure probe of Internet Facing Load Balancer

8.5.負荷分散規則を作成する8.5. Create load balancing rule(s)

ILB と同じ手順に従って、TCP 443 の負荷分散規則を構成します。Follow the same steps as in ILB to configure the load balancing rule for TCP 443.

Configure balancing rules of Internet Facing Load Balancer

9.ネットワークを保護する9. Securing the network

9.1.内部サブネットを保護する9.1. Securing the internal subnet

内部サブネットを効率的に保護するには、一般に次の規則が (以下に記載された順序で) 必要となります。Overall, you need the following rules to efficiently secure your internal subnet (in the order as listed below)

ルールRule [説明]Description FlowFlow
AllowHTTPSFromDMZAllowHTTPSFromDMZ DMZ からの HTTPS 通信を許可します。Allow the HTTPS communication from DMZ 受信Inbound
DenyInternetOutboundDenyInternetOutbound インターネットへのアクセスを禁止します。No access to internet 送信Outbound

INT access rules (inbound)

9.2.DMZ サブネットを保護する9.2. Securing the DMZ subnet

ルールRule [説明]Description フローFlow
AllowHTTPSFromInternetAllowHTTPSFromInternet インターネットから DMZ への HTTPS を許可します。Allow HTTPS from internet to the DMZ 受信Inbound
DenyInternetOutboundDenyInternetOutbound インターネットへの通信は HTTPS を除きすべてブロックします。Anything except HTTPS to internet is blocked 送信Outbound

EXT access rules (inbound)

注意

クライアント ユーザー証明書認証 (X509 ユーザー証明書を使用した clientTLS 認証) が必要である場合、AD FS の要件として、受信アクセス用に TCP ポート 49443 を有効にする必要があります。If client user certificate authentication (clientTLS authentication using X509 user certificates) is required, then AD FS requires TCP port 49443 be enabled for inbound access.

10.AD FS サインインをテストする10. Test the AD FS sign-in

AD FS のテストは、IdpInitiatedSignon.aspx ページを使用して行うのが最も簡単です。The easiest way is to test AD FS is by using the IdpInitiatedSignon.aspx page. そのためには、AD FS のプロパティで IdpInitiatedSignOn を有効にする必要があります。In order to be able to do that, it is required to enable the IdpInitiatedSignOn on the AD FS properties. 以下の手順に従って AD FS の設定を確認してください。Follow the steps below to verify your AD FS setup

  1. AD FS サーバーで PowerShell から以下のコマンドレットを実行し、このプロパティを有効にします。Run the below cmdlet on the AD FS server, using PowerShell, to set it to enabled. Set-AdfsProperties -EnableIdPInitiatedSignonPage $trueSet-AdfsProperties -EnableIdPInitiatedSignonPage $true
  2. 外部のコンピューターから https://adfs.thecloudadvocate.com/adfs/ls/IdpInitiatedSignon.aspx にアクセスします。From any external machine access https://adfs.thecloudadvocate.com/adfs/ls/IdpInitiatedSignon.aspx
  3. 以下の AD FS ページが表示されたら成功です。You should see the AD FS page like below:

Test login page

サインインに成功すると、その旨のメッセージが表示されます (下図)。On successful sign-in, it will provide you with a success message as shown below:

Test success

Azure で AD FS をデプロイするためのテンプレートTemplate for deploying AD FS in Azure

このテンプレートでは、ドメイン コントローラー、AD FS、WAP にそれぞれ 2 つずつ使用する、6 つのマシンのセットアップをデプロイします。The template deploys a 6 machine setup, 2 each for Domain Controllers, AD FS and WAP.

Azure での AD FS のデプロイ テンプレートAD FS in Azure Deployment Template

このテンプレートのデプロイ中、既存の仮想ネットワークを使用するか、新しい VNET を作成できます。You can use an existing virtual network or create a new VNET while deploying this template. デプロイをカスタマイズするために使用できる各種のパラメーターについて、デプロイ プロセスにおけるパラメーターの使用方法の説明と共に次の一覧に記載します。The various parameters available for customizing the deployment are listed below with the description of usage of the parameter in the deployment process.

パラメーターParameter [説明]Description
場所Location リソースのデプロイ先となるリージョン (例: 米国東部)The region to deploy the resources into, e.g. East US.
StorageAccountTypeStorageAccountType 作成するストレージ アカウントの種類The type of the Storage Account created
VirtualNetworkUsageVirtualNetworkUsage 新しい仮想ネットワークを作成するか既存のものを使用するかを示しますIndicates if a new virtual network will be created or use an existing one
VirtualNetworkNameVirtualNetworkName 作成する仮想ネットワークの名前 (新しい仮想ネットワークを使用する場合と既存のものを使用する場合の両方で必須)The name of the Virtual Network to Create, mandatory on both existing or new virtual network usage
VirtualNetworkResourceGroupNameVirtualNetworkResourceGroupName 既存の仮想ネットワークが存在するリソース グループの名前を指定します。Specifies the name of the resource group where the existing virtual network resides. これは、既存の仮想ネットワークを使用している場合、既存の仮想ネットワークの ID がデプロイによって検出されるようにするための必須のパラメーターになりますWhen using an existing virtual network, this becomes a mandatory parameter so the deployment can find the ID of the existing virtual network
VirtualNetworkAddressRangeVirtualNetworkAddressRange 新しい VNET のアドレス範囲 (新しい仮想ネットワークを作成する場合は必須)The address range of the new VNET, mandatory if creating a new virtual network
InternalSubnetNameInternalSubnetName 内部サブネットの名前 (新しい仮想ネットワークと既存の仮想ネットワークの両方で必須)The name of the internal subnet, mandatory on both virtual network usage options (new or existing)
InternalSubnetAddressRangeInternalSubnetAddressRange ドメイン コントローラーと ADFS サーバーが含まれる内部サブネットのアドレス範囲 (新しい仮想ネットワークを作成する場合は必須)The address range of the internal subnet, which contains the Domain Controllers and ADFS servers, mandatory if creating a new virtual network.
DMZSubnetAddressRangeDMZSubnetAddressRange Windows アプリケーション プロキシ サーバーが含まれる DMZ サブネットのアドレス範囲 (新しい仮想ネットワークを作成する場合は必須)The address range of the dmz subnet, which contains the Windows application proxy servers, mandatory if creating a new virtual network.
DMZSubnetNameDMZSubnetName 内部サブネットの名前 (新しい仮想ネットワークと既存の仮想ネットワークの両方で必須)The name of the internal subnet, mandatory on both virtual network usage options (new or existing).
ADDC01NICIPAddressADDC01NICIPAddress 最初のドメイン コントローラーの内部 IP アドレス。DC に静的に割り当てられるこの IP アドレスは、内部サブネットで有効な IP アドレスである必要がありますThe internal IP address of the first Domain Controller, this IP address will be statically assigned to the DC and must be a valid ip address within the Internal subnet
ADDC02NICIPAddressADDC02NICIPAddress 2 番目のドメイン コントローラーの内部 IP アドレス。DC に静的に割り当てられるこの IP アドレスは、内部サブネットで有効な IP アドレスである必要がありますThe internal IP address of the second Domain Controller, this IP address will be statically assigned to the DC and must be a valid ip address within the Internal subnet
ADFS01NICIPAddressADFS01NICIPAddress 最初の ADFS サーバーの内部 IP アドレス。ADFS サーバーに静的に割り当てられるこの IP アドレスは、内部サブネットで有効な IP アドレスである必要がありますThe internal IP address of the first ADFS server, this IP address will be statically assigned to the ADFS server and must be a valid ip address within the Internal subnet
ADFS02NICIPAddressADFS02NICIPAddress 2 番目の ADFS サーバーの内部 IP アドレス。ADFS サーバーに静的に割り当てられるこの IP アドレスは、内部サブネットで有効な IP アドレスである必要がありますThe internal IP address of the second ADFS server, this IP address will be statically assigned to the ADFS server and must be a valid ip address within the Internal subnet
WAP01NICIPAddressWAP01NICIPAddress 最初の WAP サーバーの内部 IP アドレス。WAP サーバーに静的に割り当てられるこの IP アドレスは、DMZ サブネットで有効な IP アドレスである必要がありますThe internal IP address of the first WAP server, this IP address will be statically assigned to the WAP server and must be a valid ip address within the DMZ subnet
WAP02NICIPAddressWAP02NICIPAddress 2 番目の WAP サーバーの内部 IP アドレス。WAP サーバーに静的に割り当てられるこの IP アドレスは、DMZ サブネットで有効な IP アドレスである必要がありますThe internal IP address of the second WAP server, this IP address will be statically assigned to the WAP server and must be a valid ip address within the DMZ subnet
ADFSLoadBalancerPrivateIPAddressADFSLoadBalancerPrivateIPAddress ADFS ロード バランサーの内部 IP アドレス。ロード バランサーに静的に割り当てられるこの IP アドレスは、内部サブネットで有効な IP アドレスである必要がありますThe internal IP address of the ADFS load balancer, this IP address will be statically assigned to the load balancer and must be a valid ip address within the Internal subnet
ADDCVMNamePrefixADDCVMNamePrefix ドメイン コントローラーの仮想マシン名のプレフィックスVirtual Machine name prefix for Domain Controllers
ADFSVMNamePrefixADFSVMNamePrefix ADFS サーバーの仮想マシン名のプレフィックスVirtual Machine name prefix for ADFS servers
WAPVMNamePrefixWAPVMNamePrefix WAP サーバーの仮想マシン名のプレフィックスVirtual Machine name prefix for WAP servers
ADDCVMSizeADDCVMSize ドメイン コントローラーの VM サイズThe vm size of the Domain Controllers
ADFSVMSizeADFSVMSize ADFS サーバーの VM サイズThe vm size of the ADFS servers
WAPVMSizeWAPVMSize WAP サーバーの VM サイズThe vm size of the WAP servers
AdminUserNameAdminUserName 仮想マシンのローカル管理者の名前The name of the local Administrator of the virtual machines
AdminPasswordAdminPassword 仮想マシンのローカル管理者アカウントのパスワードThe password for the local Administrator account of the virtual machines

その他のリソースAdditional resources

次の手順Next steps