知られざるActive Directory技術の「舞台裏」

第2回誰も教えてくれないActive DirectoryとLDAPの「本当の関係」[後編]

前回(連載第1回)は、Active Directoryの基盤といえるLDAPの重要性と、その概要のさわりをお伝えするだけで終わりました。今回は、Active DirectoryにおけるLDAPのさらに深いところを探ってみましょう。

ディレクトリ情報ツリー(DIT)と識別名(DN)とは

LDAPでは、ルートを頂点に、上位ディレクトリのエントリから下位ディレクトリのエントリへ、順にたどっていくことで、階層が構成されます。LDAPの階層構成は、ディレクトリ情報ツリー(Directory Information Tree=DIT)という概念で理解されており、たとえば「国:C」「組織:O」名前付け属性のオブジェクトを使った構成を採りますが、別の構成(たとえば「ドメインコンポーネント:DC」名前付け属性のオブジェクトを利用する)が採られるものもあります。

図1 標準的なDIT構成図
図1 標準的なDIT構成図

名前付け属性とは、階層の構成にあたっての各エントリについて、その内容の属性を指し、⁠属性の名前=属性の値」というかたちで表現します。たとえば、⁠日本」という国に本社がある「○×株式会社」という企業のディレクトリを構成したいなら、名前付け属性が「国」であるC=JPや「組織」であるO=MARUBATSUCorpを構成します。

表1 オブジェクトの名前付け属性
DNAD
CN=(一般名)CN=(一般名)
OU=(組織単位)OU=(組織単位)
O=(組織)DC=(ドメインコンポーネント)
C=(国)

Active Directoryでは、国や組織の名前付け属性を使ったDITではなく、ドメインコンポーネントを利用したDITで構成されています。たとえばシステム管理上、特に重要な「ドメイン名前付けコンテキスト」の場合、ドメインコンポーネントエントリの配下に、既存で必要な各コンテナをフラットに配置する、といった構成を採っています。初期構成されたコンテナ類はシステムが管理するため、管理者は独自のOUをドメインコンポーネントエントリの下位に作成し、これを使ってシステム管理を行なうことができます。

図2 Active Directory LDAPのDIT構成図
図2 Active Directory LDAPのDIT構成図

初期設定されるコンテナの機能のうち主要なものとして、以下のようなものがあります。

  • [Builtin]:定義済みセキュリティグループを格納する
  • [Computers]:クライアントコンピュータを格納する
  • [Domain Controllers]:ドメインコントローラを格納するOU
  • [LostAndFound]:重複して登録されたオブジェクトを格納する
  • [System]:ドメイン内の関連する設定(DFSレプリケーションやグループポリシー設定など)オブジェクトを格納する
  • [Users]:定義済みユーザアカウントやセキュリティプリンシパルを格納する

そのほか、特殊なエントリとしてRootDESがあります。これは、⁠ディレクトリサーバごとの公開情報」が含まれるエントリであり、LDAPクライアントが接続を試みる際に、接続先サーバの設定情報として利用します。rootDSEは、LDAPサーバの名前やルートエントリの情報、どのような認証をサポートしているか、といった属性で構成され、一般に接続時に認証を必要としません。

LDAPには「名前付けコンテキスト」という概念があります。名前付けコンテキストとは、LDAP名前空間(階層構造)について、特定のエントリをルートとしてその配下だけを階層構造とするよう、名前空間の範囲を設定します。実際のLDAP階層構造自体は変更されませんが、名前付けコンテキストでその一部を切り出すことで、他の階層は存在しないものとして利用することができます。

Active Directoryの名前付けコンテキストは、⁠ドメイン」⁠ドメインの情報を管理する⁠⁠、⁠設定」⁠フォレスト全体の構成情報を管理する⁠⁠、⁠スキーマ」⁠LDAPスキーマを管理する⁠⁠、⁠ForestDNSZones」および「DomainDNSZones」⁠DNSゾーン情報を管理する⁠⁠、の5つが存在し、実際には巨大なLDAP名前空間が構成されているのです。

表2 Active Directoryの名前付けコンテキスト(marubatsucorp.localドメインの場合)
ドメインDC=marubatsucorp,DC=local
設定CN=Configuration,DC=marubatsucorp,DC=local
スキーマCN=Schema,CN=Configuration,DC=marubatsucorp,
DC=local
ForestDNSZonesDC=ForestDNSZones,DC=marubatsucorp,DC=local
DomainDNSZonesDC=DomainDNSZonesDC=marubatsucorp,DC=local

LDAPの階層構成におけるエントリの絶対的な位置は、識別名(DN:Distiguished Name)で表現されます。識別名は、下位エントリから上位エントリに向かって、名前付け属性と同じ形式で表現される相対識別名(RDN:Relative Distinguished Name)をカンマでつないだものになります。たとえば、⁠山川 しずか」というユーザオブジェクトの識別名が下のようなとき、このオブジェクトは、[DC=local]→[DC=marubatsucorp]→[OU=営業部]→[OU=第一課]→[CN=山川 しずか]というディレクトリ階層をたどっている、ということになります。

  • CN=山川 しずか,OU=第一課,OU=営業部,DC=marubatsucorp,DC=local

識別名はLDAP名前空間上一意であることが必要です。そのため、同じ名前のオブジェクトを同じディレクトリ(親エントリ)に配置することはできません。別の言い方をすれば、直接の親エントリ上で一意であれば問題ない、ということですので、異なるディレクトリ上に、同じ名前のオブジェクトを配置することは可能です。たとえば、下の2つのオブジェクトは両立させることができます。

  • CN=山川 しずか,OU=第一課,OU=営業部,DC=marubatsucorp,DC=local
  • CN=山川 しずか,OU=人事課,OU=総務部,DC=marubatsucorp,DC=local

Active Directoryでもこの実装に変わりはありませんが、独自の制限事項としてWindows 2000以前のユーザ名(saMAccountName属性)を重複させることはできません。そのため、異なるディレクトリに同じ名前のオブジェクトを配置したいならば、Windows 2000以前のユーザ名を別の名前に変更する必要があります。

図3 アカウントのプロパティに表示されたWindows 2000以前のユーザ名
図3 アカウントのプロパティに表示されたWindows 2000以前のユーザ名

これに対して、特定のディレクトリ内で簡単にオブジェクトを指定したい場合、相対識別名が利用されます。相対識別名は、直接の親エントリを対象とした識別名となり、単に"CN=山川 しずか"というかたちで表現されます。親エントリ内で一意であればよく、LDAP名前空間上一意である必要はありません。

LDAPスキーマとは

LDAPでは、属性やオブジェクトの仕様(どのような内容を持つか)について、スキーマにより定義されており、具体的な実装については、RFC4519やRFC4524で勧告されています。

LDAPスキーマでは、属性あるいはオブジェクト(オブジェクトクラスとして定義されます)は一意の名前およびOIDで設定され、属性であればEQUALITY(等価照合規則:照合規則の一種)やSYNTAX(データの構文:データの型)などが、オブジェクトであればSUP(継承されたオブジェクトクラス:属性を引き継ぐオブジェクトクラス)やMUST(必須属性:必須の属性⁠⁠、MAY(オプション属性:任意で設定可能な属性⁠⁠、など必要な仕様が設定されます。

OIDとは、属性やオブジェクトクラスごとに割り当てられた、一意のIDの一種です。OIDは、一意性を保つため、IANA(Internet Assigned Numbers Authority)で管理され、オブジェクトの内容やそれを管理する(登録された)組織に添って、割り振られているのです。

そのため、一般の管理者が勝手にOIDを自組織に割り振ることはできませんが、スキーマを拡張して、新しい属性を定義したいような場合、新規のOIDについてはIANAに申請を行なって自組織に割り当てられたOIDを使うことになります。

なお、Active Directoryでは、マイクロソフトの管理下にあるOIDについて、利用者間で重複しないような生成スクリプトを使ってIANAに申請を行なわなくても、一意のOIDが利用できるようになっています。

また、各スキーマの名前は長い文字列が使われることがあります。これは名前の重複を避けるため、LDAPで行なわれる作法のひとつなのですが、このような場合そのままだと使いづらいので、lDAPDisplayName(LDAP表示名)という別の属性で、LDAPで使う属性の名前が定義されています。

オブジェクトクラスには構造型・抽象型・補助型の3つのタイプがあり、内容によって使い分けられます。一般にオブジェクトと呼ばれるものは構造型クラスにあたります。補助型クラスは構造型クラスに新しい属性を継ぐといった、仲立ちの機能をもっています。抽象型クラスは新しい構造型クラスの定義をプログラミングで行なうような場合に利用されます。

スキーマを拡張したいような場合、構造型オブジェクトを新しく定義することで、希望する属性を備えた任意のオブジェクトクラスを利用できるようになりますが、既存のオブジェクトクラスに新しい属性を加えたい、というような場合、希望する属性を備えた補助型クラスを定義して、既存のオブジェクトクラスをSUP(継承元)とすることで、既存のオブジェクトクラスに新しい属性を設定することが可能です。

Active Directoryではスキーマ情報自体がオブジェクトの集まりとして定義されており、marubatsucorp.localドメインならCN=Schema,
CN=Configuration,DC=marubatsucorp,DC=localというエントリで構成されています。

たとえば、ユーザアカウントのオブジェクトは、LDAPでは
CN=User,CN=Schema,CN=Configuration,DC=marubatsucorp,
DC=local(userクラススキーマ)として、ユーザアカウントで利用するメールアドレス(mail属性)はCN=E-mail-Address,
CN=Schema,CN=Configuration,DC=marubatsucorp,DC=local
(E-mail-Adressアトリビュートスキーマ)として、それぞれ定義されています。

図4 ユーザアカウントのプロパティ
図4 ユーザアカウントのプロパティ
図5 メールのプロパティ
図5 メールのプロパティ

Active Directory固有の実装として、グローバルカタログに自分の属性値をコピーするかどうか、が指定できます。グローバルカタログにより、フォレスト(Active Directoryの最大単位)全体の情報をいちどきに検索することができますが、グローバルカタログに属性の情報がコピーされていることで、すばやく検索させることができます。またANR(Ambiguous Name Resolution)という機能で、あいまいな検索機能を有効にすることもできます。

LDAPの認証とセキュリティとは

LDAPはデータベースの一種ですので、LDAP個別の認証システムがあります。最も単純なものは、シンプル認証という平文パスワードによる認証となります。しかし、平文による認証は実システムでは問題が多いため、他の強力な認証が使えるよう、Simple Authentication and Security Layer(SASL)という認証フレームワークが、LDAPv3より実装されています。

実際には、SASLというフレームワーク上に、Generic Security Service API(GSSAPI)と呼ばれる汎用的なセキュリティサービスを提供するアプリケーションインターフェースに準拠した、さまざまな認証プロトコルが実装されています。たとえば、SASL/GSSAPI準拠のKerberos認証やダイジェスト認証などがその代表で、必要に応じて利用する認証プロトコルを指定することができます。

Active Directoryでは、GSSAPIのマイクロソフト版であるSecurity Service Provider Interface(SSPI)に準拠した、MD5ダイジェスト認証、Kerberos認証、NTLM認証が実装されています。なお、Kerberos認証とNTLM認証については、(Windowsログオン上重要な認証プロトコルとして)必要に応じてネゴシエーションを取る必要性から、Secure Protocol Negotiation(SPNEGO)パッケージに同梱されています。詳細についてはマイクロソフトのWebサイトをご覧ください。

シンプル認証

平文パスワードによる単純な認証となります。簡単に利用できる反面、パスワードが平文で流れてしまう問題点があります。Transport Layer Security(TLS)を使った暗号化セッションを行なうことで、盗聴を防止する方法があります。

MD5ダイジェスト認証

パスワードから、元の文字を推測できない(ハッシュで変換)"チャレンジ"と呼ばれるワンタイムレベルの文字列を送り、それに応答する"レスポンス"を使って行なわれる認証です。暗号化されないデータがやりとりされる部分はシンプル認証と同じですが、実際のパスワードは盗聴されないメリットがあります。

Kerberos認証

Kerberos v5に準拠した、Active Directory標準の認証プロトコルです。KDCと呼ばれる認証機関から認証チケットを得ることで、チケットが有効な間、認証されたサービスにアクセスできるようになります。まず、認証を受ける資格チケット(TGT)を取得してから、TGTを使って、目的のサーバサービスの認証チケット(サービスチケット)をサーバとクライアント双方で取得します。高度なセキュリティを確保でき、業界標準のため汎用性も高い、というメリットがあります。

NTLM認証

NT Lanman Manager(NTLM)という認証プロトコルによる、一種のチャレンジ=レスポンス方式で認証を行う、Windowsで従来から使われている認証となります。MS-RPCプロトコルが通信に使われるため、イントラネットでの利用が前提の認証です。Active Direcotryではダウンレベル(代替の)認証として利用されます。

匿名認証

LDAPでは認証を必要としない匿名による認証を設定することもでき、Active Directoryでも可能です。匿名による認証を可能にすると、クライアントは特に認証を必要とすることなく、LDAPの各エントリにアクセスできるようになります。

LDAPでは、389/tcpまたは389/udp(非接続状態)を使って通信がなわれますが、この通信は暗号化されないため、シンプル認証時のパスワードや認証完了後のデータは特に保護されません。LDAPにはLDAP over SSLおよびLDAP over TLSという、SSL証明書を使ったサーバ認証や暗号化プロトコルがあります。

LDAP over SSLはセキュアLDAP(LDAPS)とも呼ばれ、SSLセッションによりLDAPの通信を暗号化するもので、SSLのためのサーバ証明書とクライアントにCAルート証明書を利用します。636/tcpポートが使われます。

LDAP over TLSは、Transport Layer Securityと呼ばれる、汎用的な暗号化セッションを構成するセキュリティ機能(RFC2246等で勧告されています)を使って、LDAPの通信を暗号化するものです。TLSはSSL3.0を改良したものであるので、SSLのためのサーバ証明書とCAルート証明書を利用します。LDAP over SSLとの違いとして、ポートは通常のLDAPのもの(389/tcp)を使うこと、クライアント側からの要求で必要時に暗号化を開始できる、などがあります。

LDAPを使って外部とネットワーク通信を行なう場合や、LDAPだけを使ってActive Directoryでのユーザアカウントのパスワード(unicodePwd属性)を設定したい場合、これらの暗号化技術が必要となります。

また、LDAPにおけるセキュリティ設定(オブジェクトや属性へのアクセス許可)ですが、データベースそのものへのアクセスや、各オブジェクトや属性それぞれに対してアクセス許可を個別に実装することができます。ちなみにLDAPに関するアクセス許可の実装について、現時点で正式なRFC勧告というものはないため、LDAPサーバ製品の実装に依存していることに、注意してください。

Active Directoryでは、NT Security Descriptorと呼ばれる、Windowsで利用される権限に基づくDACL(随意アクセス許可)が実装されていて、このアクセス許可はひとつひとつのオブジェクトごとに設定が可能になっています。これは、オブジェクト自体の読み取りや書き替えのほか、オブジェクトが保持する各属性や特殊なメソッド(パスワードの変更など)についても、個別に指定することができます。

図6 ユーザアカウントの「セキュリティ」プロパティ
図6 ユーザアカウントの「セキュリティ」プロパティ

上図は、特定のドメインユーザが参加可能なコンピュータアカウントについて、アクセス許可を設定する[セキュリティ]プロパティ画面をみたものですが、参加させたユーザのオブジェクトへのアクセス許可として、[DNSホスト名への検証された書き込み][サービスプリンシパル名への検証された書き込み][パスワードのリセット][パスワードの変更]等、コンピュータのドメイン参加に必要なアクセス許可が追加設定されていることがわかります。

この画面は[Active Directoryユーザーとコンピュータ]を開いてオブジェクトを右クリックし、[表示]→[拡張機能]を有効にすると、プロパティタブとして表示されるようになります。

たとえば、特定OUの管理を別のユーザに委任させたい場合に行なう「オブジェクト制御の委任ウィザード」では、このアクセス許可設定が、内部で実行されています。

図7 オブジェクト制御の委任ウィザード
図7 オブジェクト制御の委任ウィザード

Active Directoryに関する技術情報:

Microsoft TechNet Active Directory TechCenter
URLhttp://technet.microsoft.com/ja-jp/activedirectory/default.aspx
Microsoft Active Directory 機能概要ページ
URLhttp://www.microsoft.com/japan/ad/

おすすめ記事

記事・ニュース一覧