証明書サービスのインストールとセットアップ

前回までの作業でドメインコントローラーが構築できた。ここからは、次回に取り上げるActive Directory フェデレーションサービスをインストールするための準備を行っていく。

サービスアカウントの作成

Active Directory フェデレーションサービス(AD FS)を使用するには、それを実行するためのサービスアカウントが必要だ。今回作成するサービスアカウントは「Group Managed Service Account(GMSA)」と呼ばれるもので、ドメイン内で共通で使用することができるサービスアカウントだ。

GMSAを使用すると、AD FSが複数のサーバからなるロードバランス構成であっても共通のサービスアカウントを使用できる。また、GMSAはマネージドサービスアカウントの一種でもあるため、パスワードの変更も自動的に行われる。これは運用管理上、とても大きなメリットだ。

今回はGMSAに細かな設定を行うため、Windows PowerShell を使用することにする。Azure Portal から DS1に接続して、タスクバーにある PowerShell アイコンを右クリックし、「管理者として実行」を選択して起動しよう。

PowerShell コンソールが起動したら、まずは「KDSルートキー」と呼ばれるキーを作成しておく必要がある。このキーは GMSA のパスワードを生成するために必須のものだ。

ただし、Windows Server 2012 以降のサーバではルートキーを使用したパスワードの生成は、ドメインコントローラーが作成されてから10時間を経過していなければならないという内部的な制限がある。これは、複数のドメインコントローラーが存在する場合、すべての初期複製が完了して安定稼働するまでに10時間を見込んでいるからだ。

かといって、単なるテスト環境で10時間も待つのはナンセンスなので、ここではちょっとしたコツを紹介しよう。それには、PowerShell コンソールから以下のコマンドを実行すればよい。

Add-KdsRootKey   -EffectiveTime  (Get-Date).AddHours(-10)

Add-KdsRootKey はルートキーを作成するためのコマンドであり、重要なのはその後ろのパラメータ「-EffectiveTime」だ。EffectiveTimeを使用すると、このキーをドメインコントローラーに複製する時間を指定できる。ここでは、現在の時刻から10時間前を指定している。EffectiveTime を指定しない場合、キーは10時間後に有効になる。

キーが作成できたら、Get-KdsRootKey コマンドで作成されたキーを確認しておこう。

次に、このキーを使用するGMSAを作成する。以下のコマンドは表示上2行に分かれているが、1行で入力し実行していただきたい。

New-ADServiceAccount   FsGmsa  -DNSHostName  sts.mynavi.mydns.jp               -ServicePrincipalNames  http/sts.mynavi.mydns.jp

FsGmsa はサービスアカウントの名前だ。パラメータ「-DNSHostName」では GMSAを使用するサーバのホスト名を指定している。今回はAD FSとなるサーバ「FS1」が使用するので fs1.mynavi.mydns.jp を指定すればよいのだが、ここでは sts という別のホスト名を使用している。

今回の演習ではAD FSは1台だが、本番環境ではそうはいかない。AD FSが停止することは認証機能が停止することに匹敵し、結果として業務にログオンできない状態となる。これを回避するには複数のAD FSサービスを構築してロードバランス構成にする必要がある。GMSAはロードバランスを構成する複数のサーバで共通で使用されるため、ここで指定するホスト名も共通のものでなければならない。

AD FSの慣例として、共通のホスト名は「sts(Security Token Service)」を使用することになっており、今回もその慣例に従って sts を使用している。-ServicePrincipalNames はKerberos 内での識別名であるサービスプリンシパル名を指定するパラメータだ。httpは当然使用するプロトコルであり、そのあとにホスト名が続く。間のスラッシュ(/)は1つなので注意しよう。

もしパラメータやホスト名、プリンシパル名のつづりを間違えた場合は、Remove-ADServiceAccount で作成したサービスアカウントを一度削除してから再度実行してみよう。作成されたことを確認するには、Get-ADServiceAccount コマンドを使用する。

DNS にホスト名を登録

次に、sts.mynavi.mydns.jp をDNSに登録する。使用するアドレスは、FS1と同じアドレスでよい。この演習では10.0.0.5 を使用している。

サーバマネージャーの「ツール」メニューから「DNS」を選択してDNSマネージャーを起動する。次に、「前方参照ゾーン」の下にあるドメイン名(ここでは mynavi.mydns.jp)を右クリックして「新しいホスト」を選択する。名前蘭には sts、IPアドレスには FS1 のアドレス(ここでは10.0.0.5)を入力し、「ホストの追加」をクリックして保存しよう。

DNSマネージャーには以下のようにエントリーが登録されているはずだ。

証明書サービスのインストール

AD FSを使用するにはサーバ証明書が必要になる。通常は信頼されている証明機関から購入した証明書を使用するが、今回は演習なので自己署名証明書を使用することにする。とはいえ、ある程度本番運用に近い操作を覚えるため、Active Directory 証明書サービス(Active Directory Certificate Service)を使用することにする。今回は証明書サービスをDS1 にインストールしよう。

DS1に接続してサーバマネージャーの「管理」メニューから「役割の追加」を選択する。ウィザードが起動したら「役割の追加」画面まで進み、「Active Directory Certificate Service」を選択しよう。機能を追加するポップアップが表示されるので「機能の追加」をクリックする。

「次へ」をクリックし続けて「役割サービスの選択」画面が表示されたら「Certification Authority(証明機関)」が選択されていることを確認。他はひとまず必要ない。このまま「次へ」。

そして「インストール」をクリックしてインストールを開始する。3分程度で完了する。

証明書サービスのセットアップ

証明書サービスのインストールが完了したら、証明機関のセットアップを行う。それには、サーバマネージャーの右上にある旗印をクリックして「対象サーバーにActive Directory 証明書サービスを構成する」をクリックすればよい。

すると、ウィザードが起動し、最初に「資格情報」画面が表示される。ここでは証明書サービスを構成するための管理者アカウントを指定するが、規定で現在のアカウントが表示されているはずなので(CloudAdmin)、このまま「次へ」をクリックすればよい。

次に「役割サービス」の選択画面が表示される。ここではこれから構成する役割サービスを選択するが、今回は「証明機関」を選択して「次へ」。

「セットアップの種類」画面では、証明機関の用途を指定する。エンタープライズCAは、Active Directory ドメイン内での証明書管理を自動化するなどの機能を実装している。今回はこちらを選択する。スタンドアロンCAはその名の通りスタンドアロンで証明書を管理するもので、一般的にはActive Directoryドメインが存在しない環境や閉じたネットワークで使用するものだ。

次の画面ではCAの種類を指定する。今回は初めて作成するCAなので「ルートCA」を選択する。

「秘密キー」画面では「新しい秘密キーを作成する」(既定値)を選択する。証明書の発行には秘密キーが必須となるが、本番環境ですでに秘密キーを保持している場合には、それを使用することができる。今回は新しい秘密キーを作成することにする。

「CAの暗号化」ページでは、暗号化の強度を指定する。既定値ではSHA1が選択されているが、SHA1の危険性が取りざたされるご時世でもあるので、ここではSHA256を選択しよう。ちなみに、Windows Server 2016 では SHA256が既定値となる。

「CAの名前」ページは既定値のままでよいだろう。このまま「次へ」をクリックしよう。

「有効期間」ページではCAが発行する証明書の有効期間を指定する。既定では5年が指定されており、今回はこのままでよいだろう。

最後に証明書データベースの場所を指定する。今回は既定のままでよい。

最後に確認画面が表示されるので、指定した値に間違いがないことを確認して「構成」ボタンをクリックしよう。構成は1分程度で完了する。

証明書テンプレートの準備

サーバ証明書を発行するにあたり、証明書のテンプレートを準備しておく必要がある。サーバマネージャーの「ツール」メニューから「証明機関」を選択しよう。メニューの一番下にあるはずだ。

証明機関が起動したら、「証明書テンプレート」を選択する。

ここには公開されている証明書テンプレートの一覧が表示されている。「Web サーバー」と書かれているのが既存のサーバ証明書用のテンプレートだが、今回は少し設定を変更したいので新たにテンプレートを作成する。

「証明書テンプレート」を右クリックして「管理」をクリックしていただきたい。

「証明書テンプレートコンソール」が起動するので、テンプレートの一覧から「Webサーバー」を探し、「Webサーバー」を右クリックして「テンプレートの複製」をクリックする。

「新しいテンプレートのプロパティ」画面が表示されたら「全般」タブを開き、「テンプレートの表示名」を「SSL Cert」などのわかりやすい名前を指定する。

次に「要求処理」タブを開き、「秘密キーのエクスポートを許可する」をチェックする。

最後に「セキュリティ」タブを表示する。ここでは証明書の発行を許可するサーバを指定する。今回証明書を発行するのはAD FSサーバである FS1 なので、ここでは FS1 に対する証明書発行権限を設定する。

「追加」をクリックすると「ユーザー、コンピューター、サービスアカウントまたはグループの選択」画面が表示されるので「オブジェクトの種類」をクリックする。オブジェクトの種類の一覧が表示されるので、「コンピューター」をチェックして「OK」をクリックする。

次に、「選択するオブジェクト名を入力してください」欄で「FS1」と入力し「OK」をクリックする。

「新しいテンプレートのプロパティ」画面に戻るので、FS1 を選択して、下にあるアクセス許可の一覧から「登録」をチェックする。

完了したら「OK」をクリックして保存する。証明書テンプレートコンソールに戻ったら、これを閉じる。その後、「証明機関」コンソールで「証明書テンプレート」を右クリックして「新規作成」から「発行する証明書テンプレート」を選択する。

テンプレートの一覧から、先ほど作成した「SSL Cert」を選択し「OK」をクリック。

証明機関コンソールの「証明機関テンプレート」の一覧画面に SSL Cert が表示されていることを確認しよう。

以上でテンプレートの準備は完了だ。次回はFS1用の証明書を発行し、AD FSのインストールとセットアップを行う。

編集協力:ユニゾン

安納 順一

日本マイクロソフト テクニカル エバンジェリスト
主にインフラ系テクノロジーの日本市場への訴求を担当。近年はパブリッククラウド上のアイデンティティ・プロバイダーであるAzure Active Directoryを活用したセキュリティ基盤のデザインや実装方法などがメインのフィールドである。
Technetで個人ブログもさまざまな技術情報を発信している。