Global Knowledge Japan

Win Win Windows
ホーム > Win Win Windows > Active Directory

Win Win Windowsコラム
オンプレミスとクラウドのActive Directory

会社に入ってコンピューターのことについて研修等で学習すると、早い段階で「ワークグループとドメインの違い」について学習する機会があると思います。そこでは「ドメインを利用すれば、1回のサインイン操作でドメインの範囲内にあるリソースにアクセスできるようになります」という趣旨の説明があったと思います。
ここでいう1回のサインイン操作でアクセスできる「リソース」というのはドメインに参加するサーバーで共有設定されたアプリケーション、フォルダー、プリンターなどのことをさします。
会社で管理するリソースにアクセスするのに、

 アプリケーションにアクセスするためのパスワード
 共有フォルダーにアクセスするためのパスワード
 共有プリンターにアクセスするためのパスワード

などと入れていたら、とても面倒だからドメイン、つまりActive Directoryを利用して1回のサインイン操作で、すべてにアクセスできるように集約しましょう、ということだったのです。



W3-1.png

図1. Active Directoryを利用すると1回のサインインで、すべてのドメイン参加のサーバーにアクセスできる




ところが、最近ではクラウドの登場により、会社に用意されているActive Directoryではサインイン操作を集約できなくなってきています。


「私はActive Directoryでサインインをしたので、パスワードを追加で入れることなく、あなたの共有フォルダーにアクセスさせてよ」とお願いするときには、Kerberos(ケルベロス)と呼ばれるプロトコルを使って、その連携を行っていました。しかし、クラウドでは基本的にKerberosを使った連携はできないことが理由です。


そのため、Active Directoryを持っている会社でも、クラウドサービスにアクセスするときには別途、ユーザー名とパスワードを入力しなければならないのです。


クラウドサービスにアクセスするときだけユーザー名とパスワードを入力すればよいと考えるかもしれませんが、ある調査によれば、従業員一人当たりが平均的に使用するクラウドサービスの数は20以上あると言われています。それだけユーザー名とパスワードを入力すれば、パスワードの管理など面倒になり、どこのサイトでも同じパスワードにしてしまうとか、簡単なパスワードを設定してしまう、などのおざなりな管理になる可能性が高くなります。


このような問題を解決するために、クラウドサービス用のActive Directoryとして、マイクロソフトではAzure Active Directoryと呼ばれるサービスを別途用意しています。


Azure Active Directory(以降、Azure AD)はクラウドサービスへのサインイン操作を集約するためのクラウドサービスで、Azure ADに一度サインインすれば、追加でユーザー名とパスワードを入力することなく、Azure ADに関連付けられたクラウドサービスにアクセスできるようになります。



W3-2.png

図2. Active Directoryにサインインするとドメイン参加のサーバーにアクセスでき(左)、Azure Active Directoryにサインインすると連携するクラウドサービスにアクセスできる(右)



このように、1回のサインイン操作でどこにでもアクセスできる機能を提供するドメインの機能は、会社の中のリソース(オンプレミス)にアクセスするためのActive Directoryと、クラウドサービスにアクセスするためのAzure Active Directoryの2つがあるので、どちらか一方、または両方を利用して、何度もユーザー名とパスワードを入力することが無いように構成することをお勧めします。


先日、「ひとり情シスのためのWindows Server逆引きデザインパターン」を出版させていただき、Active DirectoryとAzure Active Directoryの設定方法を含む、Windows Serverの効果的な活用方法について解説をいたしました。新宿ラーニングセンターに献本をさせていただきましたので、新宿ラーニングセンターにお立ち寄りの際は、ぜひお手に取ってみていただければと思います。


また、実機を元に学習する方法として以下の2つのコースもおすすめです。

Active Directory
 「Active Directory最小構成実践(MSC0209G)」
Azure Active Directory
 「Azure Active Directory を使用した認証基盤の構築(MSC0569G)」

イマドキの時代のActive Directoryの管理方法について、ぜひ体感してみてください。

この記事を書いたのは

instructor-dummy01.png株式会社ソフィアネットワーク
マイクロソフト認定トレーナー
(グローバルナレッジパートナー講師)
国井 傑

[Active Directory ][2017年8月 4日配信]

Win Win Windowsコラム
ドメインコントローラーの降格手順【画面キャプチャ付】

今回はドメインコントローラーの降格についてご紹介します。

■ドメインコントローラーの降格とは?

ドメインコントローラーの降格とは、ドメインコントローラーを通常のサーバー(メンバーサーバー)にすることです。
老朽化により、サーバーハードウェアを変更するときや、ドメインのアップグレードに伴う、古いOSのドメインコントローラーの削除などで必要な作業です。

Windows Server 2008 R2まで

Windows Server 2008 R2までは、ドメインコントローラーで「DCPROMO コマンド」を実行します。

Windows Server 2012以降

Windows Server 2012以降、DCPROMOコマンドは使用できないため、以下いずれかの方法を実行します。


■サーバーマネージャーの役割の削除ウィザードを使用した降格

1.  サーバーマネージャーの[管理]より「役割と機能の削除」を選択します
domaincontroller01.png
2.[次へ] を押します
domaincontroller02.png

3.  降格するドメインコントローラーを選択し、[次へ]を押します
domaincontroller03.png

4.  「Active Directory Domain Services」横のチェックを外します
domaincontroller04.png

5.  管理ツールも併せて削除する場合は、[機能の削除]を押します
domaincontroller05.png

6.  「検証結果」で降格できないメッセージが表示されますが、正常な動作です。一番下の「このドメインコントローラーを降格する」を押します。
domaincontroller06.png

7.  Active Directory ドメイン サービス構成ウィザードが実行されます。必要に応じてチェックを入れます。各項目は以下の通りです。
  • 「このドメインコントローラーの削除を強制」
    ・・・ 通常の降格が失敗したときにチェックを入れます
  • 「ドメイン内の最後のドメインコントローラー」
    ・・・ ドメインをなくす場合、全ドメインコントローラーを降格しますが、最後のドメインコントローラーを降格する場合にチェックを入れます
domaincontroller07.png

8.  DNSサーバーやグローバルカタログサーバーとなっている場合、確認が表示されます。事前にDNSサーバーやグローバルカタログサーバーをほかのサーバーに移行したうえで、チェックを入れます。
domaincontroller08.png

9.  降格後のローカル Administratorのパスワードを指定します
domaincontroller09.png

10. 項目の確認後、[削除]ボタンを押します。右下の[スクリプトの表示]ボタンでPowerShellコマンドレットを表示できます。
domaincontroller10.png

■Uninstall-ADDSDomainControllerコマンドレットを使用した降格

PowerShellで降格するには、Uninstall-ADDSDomainController コマンドレットを使用します。下の例は上記ウィザードの「スクリプトの表示」で自動作成されたものです。
Import-Module ADDSDeployment コマンドレットは、PowerShellへ明示的にモジュールを組み込むコマンドレットです。Windows Server 2012 以降は自動インポート機能があるため、実行する必要はありません。

#
# AD DS 配置用の Windows PowerShell スクリプト
#

Import-Module ADDSDeployment
Uninstall-ADDSDomainController `
-DemoteOperationMasterRole:$true `
-IgnoreLastDnsServerForZone:$true `
-LastDomainControllerInDomain:$true `
-RemoveDnsDelegation:$true `
-RemoveApplicationPartitions:$true `
-Force:$true

ドメインコントローラーの昇格については、以下のコースでご紹介しています。

【無料セミナー】今さら聞けない! Active Directory入門

人気の無料セミナー「今さら聞けない! Active Directory入門」を大阪で開催いたします。満席が予想されますのでお早めにお申し込みください。



この記事を書いたのは

instructor-dummy01.pngグローバルナレッジネットワーク株式会社
ラーニングサービス本部
マイクロソフト認定トレーナー
多田 博一

[Active Directory ][2017年6月 5日配信]

Win Win Windowsコラム
認証と認可とActive Directory
執筆:横山哲也

 皆さんは、自分の身分証明書をお持ちでしょうか。おそらく、運転免許証パスポートを使う方が多いのではないかと思います。私もどちらかを使っています。

 

 ちょっと変わった身分証明書として、無線従事者免許証があります。これは、パスポートを申請するとき、1点で有効な本人確認書類ですが(法律で決まっています)、有効期限がありません。私もアマチュア無線技士の無線従事者免許証を持っていますが、40年ほど前の写真であり、さすがに使う気にはなれません。

無線従事者免許証
▲無線従事者免許証(電話級(現在の第4級)、電信級(現在の第3級)、第2級)
私の身分証明に使えると思いますか?


 さて、ほとんどの身分証明書は、身元確認の機能に加えて「どんなことが許可されるか」を示しています。たとえば、運転免許証は運転可能な車の種別が記載され、運転の条件(眼鏡等)が指定されています。

 

 でも、レンタルビデオの会員証を作るのに運転要件は必要ありません。本来は、本人確認と、何ができるかという能力の確認は別のものです。

 

 IT分野では、本人確認を「認証(Authentication)」能力の確認を「認可(Authorize)」と呼んで区別しています(「認可」の代わりに「承認」を使う場合もあります)。

 

 空港で「Authorized Person Only」と書いてあれば、それは「認可された人だけが入れる場所」であり、「関係者以外立入禁止」の意味です。Authorizeのニュアンスがお分かりいただけるでしょうか。

 

 認可を行うには、認証が不可欠です。認証できなかった人に、何かの権利を与えることはできません。「関係者以外立入禁止」の場所に、身分証明書なしに入ろうとしたら止められるでしょう。

 

 認証ができても、認可されなければ、やはり権利は与えられません。私が空港に行って「Authorized Person Only」に入ろうとして、運転免許証を提示しても入れてくれないでしょう。本人確認ができても、空港関係者(=空港管理の認可済)ではないからです。

 

 そういえば、昔のパスポートには「北朝鮮(朝鮮民主主義人民共和国)を除く全ての国と地域で有効」という意味の言葉が書いてありました(調べたら1991年より前だそうです)。つまり、一般のパスポートでは北朝鮮に行く権利がなかった(認可されていなかった)のです。

 

 このように、認証と認可は密接な関係があり、認証なしに認可は成り立ちません

 

 企業内のITシステムでは、認証システムとしてActive Directoryドメインサービス(AD DS)を使うことが多いようです。AD DSはWindows 2000とともに登場した古いシステムですが、現在に至るまでアーキテクチャを大きく変えずに使われ続けています。

 

 WindowsがAD DSに参加すると、AD DSの認証情報が利用できるようになります。AD DSの「ドメイン」とは、認証情報が有効な範囲(領域:ドメイン)の意味です。社員証が身分証明書として使える範囲は会社内だけでしょう。この場合、会社がドメインとなります。

 

 Active Directoryは昔から人気のある研修ですが、最近また増えているようです。その背景には、マイナンバーの導入や、個人情報保護の強化などがあるようです。

 

 無料セミナー「今さら聞けない! Windows Server 2012 R2 Active Directory入門」も、毎回満席になります。内容は「今さら聞けない」の言葉通り、基本的なことばかりですが、改めて勉強したいということのようです。

 

 グローバルナレッジでは、演習付きのActive Directory研修として、1日に凝縮した「Active Directory最小構成実践」や、マイクロソフト公式カリキュラムをアレンジした4日間の「Windows Server 2012 Active Directoryの実装と管理」を提供しています。

 

 Active Directoryが社内に導入されているところは多いようですが、十分に生かし切れていない例も散見されます。この機会にグローバルナレッジの教育コースを受講してみてはどうでしょう。

 

 なお、マイクロソフトではActive Directory提供15年を記念したイベントが開催されます(私は、セッションスピーカとして参加します)。詳細はマイクロソフトの社員ブログ「3/18 Active Directory 15th 記念カンファレンス 最終セッションリスト」をご覧ください。既に満席ですが、キャンセル待ちは可能なようです。懇親会もあるので、会場でお会いできる方はお会いしましょう。

あくびねこ
▲写真と本文は関係ありません

[Active Directory Windows Server][2016年3月 8日配信]

Win Win Windowsコラム
第45回 [Windows移行特集4] Active Directory マイグレーション~ADMT~
執筆:横山哲也

前回に引き続き、Active Directoryについてのお話です。

 

既存のActive Directoryドメイン構造に問題がある場合、構造を変更するよりも新しく作り直した方が早いことが多いようです。
 

既存ドメインから新規ドメインへの移行作業を「マイグレーション」と呼びます。今回は、Active Directoryマイグレーションについて紹介します。

 

単一ドメインと複数ドメイン
 

Widows 2000とともにActive Directoryが登場したとき、マイクロソフトは複数ドメイン環境がもっと一般的に使われると予想していたようです。そのため、Windows 2000の研修教材でも複数ドメイン環境の使用パターンがいくつも紹介されていました。
 

当時はWAN回線の速度が不十分だったため、地域をまたがった単一ドメインを作るのが難しかったという事情もあります。
 

しかし、現在は高速なWAN回線が安価で利用できるため、複数ドメインのメリットは薄れています。一方で、セキュリティ管理など、会社全体で統一したポリシーが要求されるシーンが増えました。ドメインを超えた統一設定は面倒だったり効率が落ちたりするので、できれば避けたいところです。
 

マイクロソフトの公式テキスト(MSU)でも「原則は単一ドメイン」と明記されるようになり、複数ドメイン構築についての記述は減っています。また、シングルドメインをサポートするための機能強化も測られています。
 

Windows Server 2003で追加された「メディアからのインストール(IFM)」は、低速回線で結ばれた拠点にドメインコントローラーを効率よく追加する機能です。Windows Server 2008で追加された「読み取り専用ドメインコントローラー(RODC)」は、低速回線で結ばれた拠点でシングルドメインを効率よく運用するための機能です。
 

もちろん、複数ドメインが必要な場合もありますから、何が何でも単一ドメインというわけではありません。ただ、当初考えられていたよりもシングルドメインの利点が大きいことが分かったということです。
 

そのため、Windows 2000当時に作成した複数ドメイン環境から、単一ドメイン環境に移行したいというニーズはよく聞きます。
 

実は、Windows Server 2003からドメインの付け替えが可能になっています。RENDOMというツールを使うことで、ドメイン名の変更や、フォレストルートを除くドメイン構造の変更が可能です。
 

RENDOM
▲RENDOMで移行可能なパターンの例

 

しかしこのRENDOM、使いこなすのはなかなか面倒です。まず、必要なステップ数が10を超えます。各ステップは、前のステップが完全に終わり、全ドメインコントローラーに設定が伝搬してから次のステップへ進む必要があります。
 

以前、ある雑誌にRENDOMの記事を書いた人が
 

編集部が付けたタイトルは『楽々移行』やけど、どこが『楽々』やねん
 

と自分で突っ込んでました(関西弁なのは、ライターが関西在住なためで、他意はありません)。

 

Active Directory Migration Tool (ADMT)
 

ドメイン構造を変更したい方の大半は、現在よりもシンプルにしたいと考えています。そして、多くの方はシングルドメインに移行しようとしています。
 

シングルドメインへの移行であれば、RENDOMを使って苦労してドメイン構造を変えるより、新しいドメインを作成し、そこに既存の情報を移行した方が簡単です。
 

Active Directory Migration Tool (ADMT) は、既存ドメインから新規ドメインへ移行するための万能ツールです。以前はその他の移行ツールも存在したのですが、現在ではADMTだけ知っていれば十分です。
 

ADMTの主な機能は以下の通りです。

  • ユーザーの移行
  • グループの移行
  • コンピューターの移行 (既存のメンバーのドメインを付け替え)
  • セキュリティの変換 (コンピューターとユーザーやグループ移行後の後始末)
  • サービスアカウントの移行

ユーザーの移行時に、パスワードエクスポートサーバー(PES)を利用することで、パスワードの移行も可能です。
 

一般的には、以下の順序でドメインを移行します。ドメインコントローラーは移行できません。

  1. ユーザーとグループの移行
  2. ユーザーが使っていたクライアントPCの移行
  3. サービスアカウントの移行
  4. メンバーサーバーの移行
  5. セキュリティ構成の後始末

ADMTは、これらの手順すべてをサポートします。
 

実際には、クライアントPCは移行せずに新しく用意することもよくあります。またサービスアカウントも移行せずに、再構成する場合もあります。
 

そのため、グローバルナレッジの教育コース「Windows環境マイグレーション実践」では、クライアント移行についてはそれほど詳しく扱っていません。新しいPCに既存の環境を移行する方法については、別のコースで扱う予定です。
 



 

ADMTのバージョン
 

ADMTの最新バージョンは3.2ですが、3.0から3.2の機能差はなく、インストール先のOSによって使い分けます。Windows Server 2012用のADMTは、現在テスト中だそうです。ADMTは大規模環境で使われることが多く、高い信頼性が求められるので十分なテストが必要だということです。
 

  • 3.0...Windows Server 2003
  • 3.1...Windows Server 2008
  • 3.2...Windows Server 2008 R2

ただし、ADMTをWindows Server 2008 R2以前で動作させれば問題ないので、移行先をWindows Server 2012にすることは可能です。
 

ADMTを使えば、ユーザーやグループは簡単に移行できるのですが、ADMTを利用するにはいくつかの事前設定が必要です。大半は自動的に設定してくれますが、どうしても管理者が別途行わなければならないものもあります。
 

また、グループの移行とユーザーの移行を同時に行うにはどうするか、パスワード移行のための追加設定をどうするのかなど、公開されている文書だけでは分かりにくい部分もあります。
 

Windows環境マイグレーション実践」では、演習を通してこれらの疑問にお答えします。

[Active Directory Windows Server 2012][2014年6月19日配信]

Win Win Windowsコラム
第37回 Windows Serverでファイルのアクセス許可を効果的に構成する冴えたやり方
執筆:横山哲也

ファイルやフォルダーに対するアクセス許可は、昔から管理者の悩みの種でした。Windows Serverでは、2種類のグループを効果的に使うことでこの問題を解決します。

グループの効果的な利用手順を「グループ戦略」と呼びます。最も広く使われているグループ戦略は「A-G-DL-P」または「I-G-DL-A」と呼ばれる構成です。ここは試験に出ます。

ファイルのアクセス許可を個人単位で行うことが望ましいと思っている人は少ないと思います。個人的には「こいつだけには見せたくない」とか「同じ部署だけど、仲のいい彼女にだけ見て欲しい」とか、そういうこともあるかもしれませんが、それでは仕事が進みません(その方が仕事が進むケースもある、という反論はこらえてください)。

グループ単位でアクセス許可を設定するとき、たいていの人は部署を基準に考えます。たとえば、商品カタログは営業部が作成するので、営業部に読み書きの許可を与えよう、という具合です。

でも、それが間違いなんです。

ある日、こんな通達が回ってきます。

今まで、カタログは営業部が担当してきたが、単なる製品情報だけでなく、会社としてのメッセージも掲載することにした。
そこで、今後はカタログ編集の許可はマーケティング部門に与える。

ファイルサーバーの管理者は、早速カタログのアクセス許可を変更し始めます。

まず、カタログの元原稿を保存したフォルダー。これは従来通り営業部の人が読み書きできますが、それに加えてマーケティング部も読み書きが必要です。

次に、カタログの版下原稿、これはマーケティング部に読み書きの許可が必要で、営業部や読み取りだけができます。

その他、いろんなフォルダーの設定変更が必要ですが、たいてい漏れてしまいます。

そこで役に立つのが、部署(人)と役割(仕事)を分ける考え方です。

「カタログ制作」という仕事に対して、「カタログ編集」という役割と「カタログ参照」という役割を考えます。従来は、営業部がカタログ編集の役割を持っていたのが、これからはカタログ参照の役割だけになり、マーケティング部がカタログ編集の役割を担当するようになったと考えます。

個々のファイルやフォルダーではなく、役割が変わったと考えれば、役割の割り当てを変えるだけで済むはずです。この考え方がA-G-DL-P戦略です。

A-G-DL-P戦略

AGDLP戦略は、最初にユーザーアカウント(A)をグローバルグループ(G)で分類します。次に、アクセス許可に利用するドメインローカルグループ(DL)を作成し、グローバルグループをドメインローカルグループに配置します。そして、ドメインローカルグループにアクセス許可(P)を割り当てます。

最近は、アカウント(A)の代わりにアイデンティティ(I)、アクセス許可(P)の代わりにアクセス(A)を使い、「I-G-DL-A」とも呼びます。

AGDLP

例を見てみましょう。

図の環境では以下の構成が必要です。

  • ファイルサーバーに商品カタログを保存する共有フォルダーを用意する
  • 商品カタログフォルダーへのアクセス許可は次の表のように設定したい

役割

アクセス許可

対象となる部署

カタログ参照

読み取り

営業部、マーケティング部

カタログ編集

読み取りと書き込み

開発部

これを元に、以下のような構成を行います。

グループの構成

グループ一覧

スコープ

メンバー

G_Sales

グローバル

営業部のユーザー全員

G_Marketing

グローバル

マーケティング部のユーザー全員

G_Develop

グローバル

開発部のユーザー全員

DL_Catalog_Readers

ドメイン
ローカル

G_SalesG_Marketing

DL_Catalog_Editors

ドメイン
ローカル

G_Develop

商品カタログフォルダーのアクセス許可

許可を与えるグループ(役割)

アクセス許可

DL_Catalog_Readers

読み取り

DL_Catalog_Editors

読み取り、書き込み

商品カタログフォルダーに対して、情報システム部のメンバーへの読み取りおよび書き込み許可(編集の権利)を追加する場合、この環境では、以下のようにグループメンバーの構成だけを行えばよく、フォルダーがいくらたくさんあってもアクセス許可を変更する必要はありません。

  • 情報システム部用グローバルグループ(G_IT)を作成し、情報システム部のユーザーをメンバーに追加
  • DL_Catalog_EditorsグループのメンバーにG_ITを追加

このように、ユーザーの分類に利用するグループとアクセス許可に利用するグループ(役割)を分けることにより、アクセス許可の追加や変更をする場合の柔軟性が増します。

アクセス許可の詳細は、教育コース「Windows Server 2008システム管理基礎(前編) ~Windows Server 2008 R2対応~」で紹介しています。Windows Server 2012への対応はもう少しお待ちください。

A-G-DL-P戦略の問題点

このように、柔軟な構成が可能なA-G-DL-P戦略ですが大きな問題があります。それは、概念が非常に理解しにくいということです。特に分類を示すGと、役割を示すDLの区別が難しいようです。

たとえば、マーケティング部員は「参照者(Readers)」という役割を持ち、開発部員は「編集者(Editors)」という役割を持ちます。しかし、普段から部署と役割を分離して考えている人はほとんどいません。組織の役割が変更になり、マーケティング部で編集作業を担当するようになって、初めて問題に気付くわけです。

通常、アクセス許可を設定するのは現場の人ですかが、現場の人はITの専門家ではありませんので、こんな複雑な、それこそMCP試験に出題されるようなレベルのことは知りませんし、本来は知る必要もないはずです。

そこで登場したのがWindows Server 2012から使える「集中型アクセス制御」ですが、これについてはまた別の機会に紹介しましょう。

教育コース「Windows Server 2012 ソリューション アップデート ~MCP 70-417対応~」でも紹介しています。

[Active Directory Windows Server][2014年3月 5日配信]

Win Win Windowsコラム
第16回: 管理権限の委任 ~共同管理と分散管理~
執筆:河野 憲義


何の記事だったか忘れてしまったのですが、「Active Directoryが登場して10年経過、これは当初の設計思想が良かったから・・・」というような事が書かれていました(編集者注)

「他に選択肢が無かったから・・・」など、賛否両論あるのかもしれませんが、10年経ったというのは事実です。言い変えれば、10年後の要望にも対応できるように、様々な機能が搭載されていたからと言えるのかもしれません。

様々な機能で真っ先に出てくるのは「グループポリシー」でしょうか。しかし「委任」もポイントが高いのではないかと感じています。

◇ ◇ ◇ ◇ ◇

さて、「パスワードは定期的に変更してください」と言われていますが、ユーザー アカウントのパスワードは、どなたが変更していますか?

A. 各ユーザー自身で自分のパスワードを変更する
B. システム管理者が各ユーザーのパスワードを変更する


もちろんAのパターンが一般的で、Bのパターンは有り得ないですね。

でも、これってよく考えたら不思議ではありませんか? パスワードはユーザー アカウントの属性として、Active Directoryに保存されています。それを管理者権限の無い一般ユーザーが変更しています。

「なるほど、言われてみれば変だぞ。」
「良く分からないが、そういうものなのだろう。」

実は、これが委任の基本です。仕組みは簡単で、[パスワードの変更]というアクセス許可が、ユーザー(本人)に許可されているのです。同じようなアクセス許可を与えることで、パスワードだけでなく、部署名や電話番号といった他のユーザー アカウント属性も、自分自身で変更可能になります。

部署名や電話番号が変わった場合、その変更をシステム管理者側で行うのは大変です。またユーザー側も、システム管理者に変更を依頼するのは面倒です。

委任を効果的に活用することで、システム管理者の労力を軽減すると同時に、一般ユーザーでも気軽に変更できるメリットが生まれます。部署名や電話番号はOutlookのアドレス帳に表示できます。これらの保守をユーザー自身で行うようにすれば、システム管理者とユーザーの双方にとって有益なのではないでしょうか。

◇ ◇ ◇ ◇ ◇

Active Directoryには様々な機能が搭載されていますから、1人のシステム管理者だけで運用していくのは大変ですね。

ある程度の規模を持つActive Directoryは、部署単位や拠点単位に分け、複数人で「分散管理」するのが常套手段と言えるでしょう。この際、管理担当者のアカウントをAdministratorsグループに登録、と考えがちですが、これでは「分散管理」ではなく「共同管理」になってしまいます。

ご存知の通りAdministratorsグループには、すべての管理権限が付与されています。すべてを管理できるということは、ある部署や拠点の管理担当者が、誤って別の部署や拠点の設定を変更してしまう懸念が出てきます。この場合、人レベルでは分散管理かもしれませんが、システムレベルでは分散管理になっていないことになります。

システムレベルで分散管理を実現するには、先ほどの「委任」が役立ちます。ある部署や拠点のシステム管理担当者には、その部署や拠点のアクセス許可のみを許可するようにします。こうすることで、誤って別の部署や拠点の設定を変更してしまうことを防止できます。

複数人で分散管理する場合、「委任」を有効に活用することで、明確な責任分担が反映されたシステム運用が可能になります。

◇ ◇ ◇ ◇ ◇

システム管理者と一般ユーザー、複数人のシステム管理者。この2つの観点から「委任」を眺めてみました。これら「委任」については次の認定コースで取り上げています。よろしければ参加をご検討ください。教室でお待ちしています。


【編集者注】
マイクロソフト主催の「Active Directory 10周年」イベントのパネルディスカッションで、横山哲也(グローバルナレッジネットワーク)が発言した内容だと思われます。

当日の様子は、マイクロソフトの高添さんのブログ「Active Directory 10 周年記念 ~ Active Directory 有名人たちが語る 10 年~」をご覧ください。

[Active Directory Windows Server 2008 R2運用管理][2011年10月 7日配信]

Win Win Windowsコラム
第1回: Active Directory 10周年
執筆:横山 哲也

Windowsを企業に導入する場合に欠かせないのが「Active Directoryドメインサービス(AD DS)」です。従来は単に「Active Directory」と呼んでいたのですが、Windows Server 2008から名称が変わりました。もっとも、私も含めて多くの人は今でもActive Directoryと呼んでいます。本当はいけないのかも知れませんが、マイクロソフトの人もActive Directoryと呼んでいるので勘弁してください。特に今回は、歴史的な話を紹介するので当時の呼称に合わせてActive Directoryとします。


さて、そのActive Directoryは2000年2月、Windows 2000の発売とともに登場しました。2010年2月で10周年です。IT業界の1年は「ドッグ・イヤー」つまりイヌの1年と同等と言われています。イヌの寿命は10年から15年くらいですから、Active Directoryさんもかなりの高齢ということになりますね。


マイクロソフトは、Active Directory 10周年を記念してイベントを開催しました。私(横山)もゲストとして呼ばれ、昔の話を語ってきました。当日の模様はTech Fielders サイトに公開される予定です。また、Twitterのハッシュタグ#ad10thで検索していただけると当日の様子が分かるでしょう。

 

●Active Directoryの始まり
私がActive Directoryを最初に触ったのは、まだ一般公開されていない「Windows NT 5.0ベータ1」の時代です。そのときの解説文書には

Windows NTのローカルグループやグローバルグループはややこしいので、単なる「グループ」に一本化する。

と、はっきり書いてあったのを覚えています。Active Directoryに詳しい方はご存じの通り、実際には一本化どころか「ドメインローカルグループ」と「ユニバーサルグループ」がさらに追加されています。
証拠の画面ショットもあるのですが、公開していいかどうか分からないので掲載は控えます。どうしても見たい方は月刊「Windows NT World」(IDGジャパン)1998年5月号の特集「Active Directoryで変貌するNTネットワークの世界」を探してみてください。

 

●Active Directoryの導入
鳴り物入りで登場したActive Directoryですが、すぐには普及しませんでした。当時は「数万人を超える規模に対応する」「より高度なセキュリティに対応する」「UNIXと認証を一本化する」といった売り文句が並んでいましたが、これが間違っていたのだと思います。

数万人を超える従業員を抱える企業はそれほど多くありません。セキュリティは高いに越したことはありませんが、2000年当時はセキュリティ意識が今ほど高くありませんでした。Windows以外のシステムとの認証を一元化するのは、現在でもそう簡単ではありません。「Active Directory 10周年」イベントでは「Linuxの認証をActive Directoryで行うデモを作るのが一番大変だった」という声もあったくらいです。

 

●Active Directoryの普及
本格的にActive Directoryが普及し始めたのは大規模なセキュリティ侵害が発生した2003年頃からでしょう。特にクライアントからのセキュリティ侵害が深刻な事態を引き起こしました。そこで注目されたのがActive Directoryです。Active Directoryと同時に提供される「グループポリシー」を使えば、クライアント環境の管理を簡単に行えます。

新しい技術は、製品ができただけでは決して普及しません。製品に加えて、消費者のニーズ、そして利用環境が必要です。たとえば自動車が普及するには、自動車という製品、自由に移動したいというニーズ、そして自動車が通行できる道路網とガソリンスタンドが必要です。

Active Directoryの場合は、製品が登場したのが2000年、信頼できるPCサーバーという環境が整ったのが少し早くて1996年くらい、そしてクライアント管理というニーズが高まったのが2003年だと考えられます。そのためActive Directoryの普及は2003年まで待つ必要がありました。マイクロソフトが当初想定した大規模環境の管理というニーズは、それほど大きくなかったようです。

 

●Active Directoryの学習
私たちは、マイクロソフトのラーニングパートナーとして教育コースを提供しています。この時、心がけているのは単に技術を紹介するだけではなく(もちろん技術解説は最低条件です)「その技術を使うには何が必要なのか(環境)」と「どんなふうに使えば便利なのか(ニーズ)」を紹介することです。
たとえば 「Windows Server 2008 R2ソリューション概要」では「...をするには」という見出しが多用されており、本文には「ここで使える...」という表現が随所に登場します。単なる技術ではなく、ビジネスに役立つソリューションを提供したいと考えた結果です。

構成上、どうしても技術的な面に偏りがちな教育コースもありますが、これからも、なるべく現場のニーズに応えられるような話をしていきたいと考えています。


 


 

横山 哲也

グローバル ナレッジネットワーク株式会社で、ITプロフェッショナル向け教育コースの企画・開発・実施を担当。Windows 2000のMCSEとしては世界で最初の2000人に入った(当時のインタビュー記事)。2003年にはWindows Server 2003のMCSA、2004年にMCSE、2008年8月にはWindows Server 2008のMCITP(Server AdministratorおよびEnterprise Administrator)を取得するなど、常に最新の資格を維持している。

Windows 関連コースのBlogも執筆中。 「千年Windows」

 


 


 

[Active Directory ][2010年3月10日配信]

※Microsoft、Windowsは、米国Microsoft社の登録商標です。
※Oracleは、米国オラクル・コーポレーションおよびその子会社、関連会社の米国およびその他の国における登録商標です。
※PMI、PMP、PMBOKは、プロジェクトマネジメント協会(Project Management Institute, Inc.)の登録商標です。
※ITIL®はAXELOS Limited の登録商標です。
※American Management Association は、米国アメリカン マネジメント アソシエーションの登録商標です。
※BOOT CAMP、NEW TRAIN、Glovalueはグローバルナレッジネットワーク株式会社の登録商標です。
※その他このサイトに掲載された社名、製品名は、各社の商標、または登録商標です。

© Global Knowledge Network Japan, Ltd. 2008-2016, All Rights Reserved.
  • Get ADOBE READER