Active Directory ドメイン サービスは、システム管理者が組織内のユーザーやリソースを管理するための仕組みを提供しているサービスです。ドメインは組織単位で管理されており、ドメイン内のリソースを利用できるのは認証されたドメイン ユーザーとなります。
Active Directory ドメイン サービスには「信頼関係」と呼ばれる仕組みがあり、信頼してもよいドメインに対してリソースを利用させることができます。一般的には、同じグループ会社や企業統合などで別のドメインを利用したいときに有効な機能です。
ドメイン環境で管理されているリソースを利用するには、リソースを利用したいユーザーが「認証」できる必要があります。信頼関係を構築しているドメイン間では、リソースとユーザーを管理しているドメインが異なることがあるため、ユーザーの認証要求を転送して、一方のドメインに認証処理を依頼しなければなりません。
今回は、信頼関係を結ぶ環境にて、別ドメインに認証要求を行う仕組みについて紹介します。
AD の信頼関係とは？
Active Directory での「信頼関係」とは、異なるドメインやフォレスト間でリソースにアクセスできる仕組みです。
基本的にはドメインで管理しているリソースにアクセスできるのは、ドメイン内で管理されているアカウントのみとなります。しかしながら、同じグループ会社のドメインのように、信頼ができるドメインからのアクセスは許可したいことがあります。異なるドメインやアドレスにアクセスを許可したい場合は、信頼関係を結びます。アクセスを許可するドメインは「信頼する」側のドlメインで、アクセスを許可されたドメインは「信頼される」ドメインとなります。
信頼関係を結ぶと、信頼される側は信頼する側のリソースを利用することができるようになります。信頼関係は、下図のようなイメージとなります。
信頼関係の基本的な仕組みについては、以下の記事で紹介しております。
Active Directory ドメイン サービスは、システム管理者が組織内のユーザーやリソースを管理するための仕組みを提供しているサービスです。ドメインは組織単位で管理されており、ドメイン内のリソースを利用できるのは認証されたドメイン […]
ドメイン環境で管理されているリソースを利用するには、リソースを利用したいユーザーが「認証」できる必要があります。信頼関係を構築しているドメイン間では、リソースとユーザーを管理しているドメインが異なることがあり、その場合にはユーザーの認証要求を転送して、一方のドメインに認証処理を依頼しなければなりません。
信頼関係を結ぶ別ドメインに認証要求を転送し、認証が成功すれば、ユーザーにアクセスを許可するという動作になります。
外部信頼とフォレスト信頼
他ドメインと結ぶ信頼関係の種類として、主に「外部信頼」と「フォレスト信頼」があります。
「外部信頼」とは、異なるフォレストのドメイン間で結ぶ信頼関係のことです。外部信頼は推移性がない信頼関係となり、外部信頼を結んでいるドメイン同士で完結しています。外部信頼の場合は、２つのドメイン間で認証要求が転送されます。
「フォレスト信頼」とは、異なるフォレスト間で結ぶ信頼関係のことです。厳密に言うと、異なるフォレストのルート ドメイン同士で信頼関係を結びます。フォレスト信頼は推移性がある信頼関係となり、フォレスト内の全てのドメインが推移的な信頼関係があります。フォレスト信頼を構築している場合、ドメインの推移性があるため、認証要求を転送する際に複数のドメインを経由することがあります。
ドメイン環境で利用される認証方式
Active Directory のドメイン環境における認証基盤として、Kerberos 認証と NTLM 認証が主に利用されています。基本的には Kerberos 認証の方がセキュアな認証方式であるため、Kerberos 認証が優先して利用されます。しかしながら、認証を必要とするアプリケーションが Kerberos 認証に対応していない等、何らかの理由で Kerberos 認証が利用できない場合の代替として、NTLM 認証が利用されます。
Kerberos 認証と NTLM 認証の基本的な仕組みや認証フローについては、以下の記事で紹介しています。
Kerberos 認証とは、ネットワーク認証方式の一つです。 Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されていま[…]
NTLM 認証とは、ネットワーク認証方式の一つです。 Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証や NTLM 認証などで[…]
Kerberos 認証と NTLM 認証では、以下の通り認証のフローが異なります。Kerberos 認証と NTLM 認証の基本フローは以下の通りです。
Kerberos 認証では、クライアントがドメイン コントローラーに認証要求を行い、認証が通ったらリソースへアクセスができます。一方、NTLM 認証では、クライアントはリソースへのアクセスを行い、その際に認証情報を提示します。リソースサーバーはクライアントから受け取った認証情報をもってドメイン コントローラへ認証を行います。
信頼関係を構築しているドメイン環境にて、クライアントとリソース サーバーが所属しているドメインが異なる場合、別のドメインへ認証要求を転送する必要があります。Kerberos 認証と NTLM 認証のそれぞれが、ドメインをまたぐ場合、どのような認証フローとなるのか見ていきます。
ドメインをまたいだ Kerberos 認証
外部信頼やシングル ドメイン同士のフォレスト信頼の場合、２つのドメイン間にて Kerberos 認証が行われます。
Kerberos 認証では、ユーザーが本人であることを証明する TGT と、サービスにアクセスに必要となるサービス チケットの２つのチケットが発行されます。TGT が発行できるのはユーザー プリンシパルが所属するドメインで、サービス チケットを発行できるのはサービス プリンシパルが所属するドメインとなります。
接続先のクライアント(ユーザー プリンシパル)と接続先のサーバー(サービス プリンシパル)が所属しているドメインが異なる場合、それぞれのドメインの KDC が TGT とサービス チケットを発行します。
ドメインをまたいだ Kerberos 認証のフローは、以下の通り、[A] ～ [F] のフローとなります。今回の説明では、nekomaru.com ドメインと fish.com ドメインが外部信頼を結んでいる環境において、nekomaru.com のユーザーが fish.com のサーバーにアクセスするシナリオにおける認証フローを想定しています。
[A] nekomaru.com の KDC へ AS Request
接続元のクライアント(nekomaru.com のユーザー プリンシパル)は、nekomaru.com の KDC に対して TGT の発行を要求します。
AS Request には、認証を行うユーザーのユーザー名やドメイン名と認証情報などが含まれています。ユーザー アカウントを管理しているのは nekomaru.com ドメインであるため、nekomaru.com の KDC に対して AS Request を送信します。
[B] nekomaru.com の KDC から AS Response
nekomaru.com ドメインの KDC は TGT の発行要求(AS Request)を受け取ったら、要求に含まれる認証情報をもとにユーザーの認証を行います。認証情報によりユーザーの正当性の確認がとれたら、KDC は TGT を発行してクライアントへ送信します。
[C] nekomaru.com の KDC へ TGS Request
接続元のクライアントは、まず nekomaru.com の KDC に対して TGS Request を送信します。
TGT を受け取ったら、次はサービスを利用するためのサービス チケットを入手しなくてはなりません。しかし、今回のシナリオでは接続先のサーバーは fish.com に所属しているため、nekomaru.com の KDC はサービス チケットを発行することができません。サービス チケットはサービス プリンシパルの Service Key(サービス プリンシパルのパスワードをもとに作成された鍵)で暗号化する必要があり、サービス プリンシパルのアカウントの情報は nekomaru.com は管理していないからです。
nekomaru.com の KDC はサービス チケットを発行する代わりに、fish.com の紹介チケットを発行します。
[D] nekomaru.com の KDC から TGS Response
KDC は TGS Request を受け取ったら、まず TGT に問題がないことを確認します。TGT に問題がないことを確認がとれたら、fish.com の紹介チケットを発行してクライアントへ送信します。
[E] fish.com の KDC へ TGS Request
接続元のクライアント(ユーザー プリンシパル)は、fish.com の KDC の TGS に対してサービス チケットの発行要求を行います。
[A]、[B] のフローによりユーザーには本人証明となる TGT が発行されています。また、[C]、[D] のフローによりユーザーには fish.com ドメインへの紹介チケットが発行されています。fish.com の KDC にサービス チケットを要求する際には、ユーザー認証が完了していることを示すため、また fish.com の KDC へ問い合わせるための紹介チケットも併せて送信します。
TGS Request には、利用するサービス名を指定するために、SPN(Service Name Principal Name) を指定します。
[F] fish.com の KDC から TGS Response
fish.com の KDC はサービス チケットの要求(TGS Request)を受け取ったら、まず紹介チケットに問題がないことを確認します。紹介チケットに問題がないことを確認がとれたら、TGS Request に指定されている SPN を確認し、対象のサービスへアクセスするためのサービス チケットを発行します。
サービス チケットは SPN が紐づいているアカウント(サービス プリンシパル)のパスワードで暗号化されます。fish.com はサービス プリンシパルのアカウントを管理しているため、fish.com の KDC はサービス チケットを発行できます。
[G] fish.com のリソース サーバーへ AP Request
接続元のクライアント(ユーザー プリンシパル)は、fish.com の KDC から発行されたサービス チケットを提示して利用を要求します。
[H] fish.com のリソース サーバーへ AP Response
サービスを提供する fish.com のサーバーは、クライアントから提示されたサービス チケットを検証します。
サービス チケットはサービス アカウントのパスワードをもとに作成された Service Key で暗号化されているため、復号できるか確認します。確認の結果、サービス チケットに問題がなければ、Kerberos 認証が成功したことを示す結果を応答します。
フォレスト信頼による推移的な信頼関係があるドメイン環境での Kerberos 認証
フォレスト信頼は、異なるフォレストのルート ドメイン同士で結ばれる信頼関係です。フォレスト信頼は推移性がある信頼関係となり、フォレスト内の全てのドメインは推移的な信頼関係があります。
nekomaru.com フォレストと fish.com フォレストでフォレスト信頼を結んでいる場合、信頼関係の推移性により、nekomaru.com の子ドメインのユーザーが、fish.com の子ドメインで管理されているサーバーを利用することができます。直接信頼関係を結んでおらず、フォレスト信頼による推移性による信頼の環境における Kerberos 認証のフローは以下の通りとなります。
フォレストをまたいだ Kerberos 認証のフローは、以下のフローとなります。今回の説明では、nekomaru.com フォレストの子ドメインである sub.nekomaru.com のユーザーが、fish.com フォレストの子ドメインである sub.fish.com のサーバーにアクセスするシナリオにおける認証フローを想定しています。
Kerberos 認証にて信頼関係でドメインをまたぐ場合、前章で説明したように、基本的には TGS Request の応答に信頼関係先のドメインへの紹介チケットを発行される動作になります。フォレスト信頼を結ぶ環境にて、推移性のある信頼関係においては、サービス アカウントを管理しているドメインの紹介チケットを得られるまで TGS Request を送信する動作となります。
- クライアントは sub.nekomaru.com の KDC へ AS Request を送信します
- sub.nekomaru.com の KDC は TGT を発行して、クライアントへ送信します
- クライアントは sub.nekomaru.com の KDC へ TGS Request を送信します
- sub.nekomaru.com の KDC は親子関係の信頼関係をもつ親ドメインの nekomaru.com の紹介チケットをクライアントはへ送信します。
- クライアントは nekomaru.com の KDC へ TGS Request を送信します
- nekomaru.com の KDC はフォレスト信頼関係をもつ fish.com の紹介チケットをクライアントへ送信します。
- クライアントは fish.com の KDC へ TGS Request を送信します
- fish.com の KDC は親子関係の信頼関係をもつ子ドメインの sub.nekomaru.com の紹介チケットをクライアントはへ送信します。
- クライアントは sub.fish.com の KDC へ TGS Request を送信します
- sub.fish.com の KDC はサービス チケットを発行してクライアントへ送信します
- クライアントはリソース サーバーへ AP Request を送信します
- リソース サーバーは AP Response を応答し、アクセスを許可します
ドメインをまたいだ NTLM 認証
外部信頼やシングル ドメイン同士のフォレスト信頼の場合、２つのドメイン間にて NTLM 認証が行われます。
NTLM 認証では、クライアントは認証要求をリソース サーバーに送信しますが、リソース サーバーは認証情報を保持しないため、ドメイン コントローラーへ認証要求を転送する動作となります。認証要求の転送先は、リソース サーバーがセキュア チャネルを確立しているドメイン コントローラーとなります。ドメイン端末は、自身が参加しているドメインのドメイン コントローラーとセキュア チャネルを確立する動作となり、別のドメインのドメイン コントローラーとセキュア チャネルを確立することはできません。
接続元のクライアントと接続先のリソース サーバーが所属しているドメインが異なる場合、NTLM 認証において、認証要求の転送先はリソース サーバー自身が所属するドメインのドメイン コントローラーとなります。しかし、接続元のクライアントのユーザーが所属するドメインは別であるため、転送先のドメイン コントローラーではユーザーの認証を行うことはできません。そのため、転送先のドメイン コントローラーは、さらにユーザーが所属するドメインのドメイン コントローラーへ認証の転送を行います。
ドメインをまたいだ NTLM 認証のフローは、以下の通り、[A] ～ [F] のフローとなります。
２つのドメイン間で信頼関係を結ぶと、それぞれのドメインにある各ドメイン コントローラーとの間ではセキュア チャネルが確立されるようになります。NTLM 認証にて、nekomaru.com のドメイン コントローラーが fish.com のドメイン コントローラーへ認証要求を転送する時は、セキュア チャネルの確立先のドメイン コントローラーへ転送する動作となります。
フォレスト信頼による推移的な信頼関係があるドメイン環境での NTLM 認証
フォレスト信頼は、異なるフォレストのルート ドメイン同士で結ばれる信頼関係です。フォレスト信頼は推移性がある信頼関係となり、フォレスト内の全てのドメインは推移的な信頼関係があります。
nekomaru.com フォレストと fish.com フォレストでフォレスト信頼を結んでいる場合、信頼関係の推移性により、nekomaru.com の子ドメインのユーザーが、fish.com の子ドメインで管理されているサーバーを利用することができます。直接信頼関係を結んでおらず、フォレスト信頼による推移性による信頼の環境における NTLM 認証のフローは以下の通りとなります。
フォレストをまたいだ NTLM 認証のフローは、以下のフローとなります。今回の説明では、nekomaru.com フォレストの子ドメインである sub.nekomaru.com のユーザーが、fish.com フォレストの子ドメインである sub.fish.com のサーバーにアクセスするシナリオにおける認証フローを想定しています。
NTLM 認にてドメインをまたいで認証する場合、前章で説明したように、NTLM 認証の要求をセキュア チャネルのなぞって転送されていきます。フォレスト信頼を結ぶ環境にて、推移性のある信頼関係においては、ユーザー アカウントを管理しているドメインのドメイン コントローラーまでセキュア チャネルをなぞって認証が転送される動作となります。
- クライアントは、サービスを提供しているサーバーに NTLM 認証の要求を送信します
- サーバーは乱数を算出して、「チャレンジ」と呼ばれるデータをクライアントに送信します
- クライアントは認証情報として「レスポンス」と呼ばれるデータをサーバーに送信します
- サーバーはセキュア チャネルの確立先である、sub.fish.com のドメイン コントローラーに認証情報を転送します
- ユーザー アカウントは sub.fish.com のユーザーではないため、sub.fish.com のドメイン コントローラーを処理することはできません。そのため、セキュア チャネルの確立先である親ドメイン fish.com のドメイン コントローラーに認証情報を転送します
- ユーザー アカウントは fish.com のユーザーではないため、fish.com のドメイン コントローラーを処理することはできません。そのため、セキュア チャネルの確立先であるフォレスト信頼先の nekomaru.com のドメイン コントローラーに認証情報を転送します
- ユーザー アカウントは nekomaru.com のユーザーではないため、nekomaru.com のドメイン コントローラーを処理することはできません。そのため、セキュア チャネルの確立先である子ドメインの sub.nekomaru.com のドメイン コントローラーに認証情報を転送します
- アカウントを管理する sub.nekomaru.com のドメイン コントローラーは、送信されてきた認証情報を検証します。認証結果は、認証要求の転送元へ送信します。
- 認証結果は、認証要求が通ってきた経路を逆戻りする形でクライアントまで応答が返されます。(⑨～⑫)
ポチップ
