SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Active Directory入門

Active Directoryの認証の仕組み

Active Directory 入門(3)


  • X ポスト
  • このエントリーをはてなブックマークに追加

 この連載では、企業システムでWindows Serverを利用する場合に、すべての基盤となっている「Active Directory」について説明していきます。今回は、Active Directoryでどのようにユーザー認証が行われるのかについて、ワークグループ環境とドメイン環境を比較して紹介したいと思います。

  • X ポスト
  • このエントリーをはてなブックマークに追加

Active Directory - 認証の仕組み

 Active Directoryでユーザー認証などを行えることを、前回までで紹介しました。ここではどのようにユーザー認証が行われるのかについて、ワークグループ環境とドメイン環境を比較して紹介したいと思います。

ワークグループとドメイン

 Active Directoryによる認証を行う環境を「ドメイン環境」と呼びます。対して Active Directoryを使わない環境は「ワークグループ環境」と呼ばれています。この2つの環境の違いについて、まず紹介します。

 ワークグループ環境は、アクセスを要求してきたユーザーに対する認証をそれぞれのコンピュータが独自に実行する形態です。この環境では、アクセスを要求するクライアントから、アクセス先のコンピュータに対して、ユーザー名とパスワードを基にした認証データを送信します。この認証データを受け取ったアクセス先のコンピュータは、自身のシステムに登録されているアカウント情報とこの認証データを照合します。そして照合が成功した場合に、そのシステムへのアクセスがユーザーに許可されます。

 かわってドメイン環境では、はじめにすべてのユーザー/コンピュータがドメインに参加するという仕組みを通して、Active Directoryを構成するドメインコントローラを信頼することから始まります。ドメインに参加しているユーザーがアクセスを要求すると、その認証データはActive Directoryデータを格納しているドメインコントローラに送信されます。認証データを受け取ったドメインコントローラは、その認証データとActive Directoryに保存されているアカウント情報との照合を行い、正しいユーザーであることが確認できた場合には、チケットと呼ばれるアクセス用トークンをクライアントに送信します。チケットを受け取ったクライアントは、そのチケットを認証データとしてアクセス先コンピュータに提示します。アクセス先のコンピュータは、このチケットが属しているドメインから正しく発行されたものかどうかを検証し、正しいチケットであればそのクライアントにアクセスを許可します。このチケットを使った認証の仕組みは、 「Kerberos認証」と呼ばれています。

図1: ワークグループ環境とドメイン環境
図1: ワークグループ環境とドメイン環境

 このようにドメイン環境では、アカウント情報の照合をドメインコントローラ上の Active Directoryの情報を基に行うことで、同じドメインに所属するユーザー/コンピュータは同じアカウント情報を基に認証されることになります。これによって、ワークグループ環境ではそれぞれのコンピュータ上にアカウント情報(ユーザー)を登録する必要がありましたが、ドメイン環境では Active Directoryにユーザーを登録することによって、どのコンピュータでも同じアカウント情報が利用できるようになります。これはユーザーを一度登録すればどのコンピュータでも認証をすることができるだけではなく、ユーザーを削除した場合には確実にそのアカウントが無効になるということも意味します。これはセキュリティを確保するために重要な要素と言えます。

スキーマとオブジェクト

 ドメイン環境の認証では、Active Directory上に保存されたアカウント情報を基に認証が行われることを紹介しました。Active Directoryではユーザー情報をはじめ、「スキーマ」という定義に沿ったさまざまな情報を格納することが可能です。このスキーマは Active Directoryに保存するデータのセット(クラス)を定義する仕組みであり、ユーザー情報であればユーザーに関連する一連のデータをひとかたまりにした定義を、ユーザー情報のスキーマとして保持しています。新しいユーザー情報を作成した場合には、このスキーマを基にして一連のデータのセットが、ユーザー情報を表す「オブジェクト」として新規作成されます。

 Active Directoryのスキーマはユーザーの手により拡張することが可能です。ここでは Active Directoryのスキーマに標準で含まれてる代表的なものを紹介します。

User - ユーザー

 その名の通り、ユーザー情報を格納するクラスです。ユーザー情報には、ユーザーの名前やログオンID、パスワードなどが含まれています。このユーザー情報として格納されたIDとパスワードを使って、ユーザーの認証が行われます。

図2: ユーザー
図2: ユーザー

Security Group - セキュリティグループ

 セキュリティグループは、ユーザーをひとまとめにグループ化するためのクラスです。セキュリティグループのメンバーとしてユーザーを追加することで、共有フォルダなどのリソースへのアクセス権の設定をそれぞれのユーザーに与えるのでなく、セキュリティグループに対して権限の設定をすることが可能になります。これによってグループに登録されているメンバーを追加/削除するだけで、グループに対して権限を設定したリソースにアクセスできるユーザーを操作できるようになります。

 多数のリソースに対して個別のユーザーごとに権限を与えた場合、権限の変更は大変手間がかかります。リソースへの権限をグループを通して与えておくことで、グループのメンバーを変更するだけで多数のリソースへの権限を管理できます。

図3: セキュリティグループ
図3: セキュリティグループ

Contact - 連絡先

 連絡先は、ユーザーと同様に人を表すクラスですが、ユーザーと大きく違うのはログオンに利用できるIDやパスワードの情報を持たないことです。そのため連絡先として登録された情報を使って、コンピュータにログオンするようなことはできません。

 連絡先を利用するケースとしては、Exchange Serverと連動してメールアドレスのエイリアスとして利用する場合などがあります。

Distribution List - 配布リスト

 配布リストは、セキュリティグループと同じようにユーザーをグループ化するために利用します。ただし配布リストはセキュリティグループと違ってリソースのアクセス権限の設定に利用することはできません。先の連絡先と同じように、Exchange Serverと連動して配布リストに追加したメンバーへまとめてメールを送る、メーリングリストのような機能を利用したい場合に、配布リストを作成します。

まとめ

 Active Directoryを使ったドメイン環境では、アカウントの認証がドメインコントローラで行われます。認証がドメインコントローラで行われることによって、ユーザーの追加や変更/無効化を一元管理できるというメリットが生まれます。

 また Active Directoryでは、スキーマという情報を使ってユーザーやグループといったオブジェクトを定義しています。このスキーマはユーザーに応じて拡張可能なため、一つのオブジェクトに多様な情報を関連づけることが可能です。Exchange Serverではこのスキーマ拡張を利用し、ユーザーやグループを拡張して追加の情報を格納して利用しています。

 このように企業内で利用されるさまざまな情報、ユーザーやグループといったID管理にかかわるものを、Active Directoryによって一元管理することが可能になっています。

関連資料

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
Active Directory入門連載記事一覧

もっと読む

この記事の著者

櫻井 敬子(たーきょん)(サクライ タカコ)

コンピュータ関係の総合商社、アミューズメント系企業の情報システムを経て、NTTデータ先端技術(株)へ入社。2008年9月より(株)NTTデータ 基盤システム事業本部へ出向し、Microsoft製品、VMwareなどを中心とする部門にて勤務。2011年4月よりシステム基盤全般にかかわる部署へ異動し、各種トラブル対応や標準化にかかわる業務を担当。2011年6月中旬よりNTTデータ先端技術(株)へ出向復帰。Windowsを含...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

黒田 剛(クロダ ゴウ)

(株)NTTデータ 基盤システム事業本部にて、システム基盤全体の技術支援を行う。 

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

KEUNA(ケウナ)

: Admintech.jpオンラインコミュニティで長く活動を続けており、Windows Server や Network 技術を中心に、開発までを含めた幅広い経験を持つ。Windows Server を利用した Web Service の設計や運用、Active Directory を中心とした企...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4212 2011/06/13 13:21

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング