第3回 開発環境の資源を管理する：連載：いまさら聞けないWindows Serverの開発活用術（2/2 ページ）

[亀川和史，著]

■アカウント管理

　アカウントの運用は開発環境であっても重要だ。Active Directoryを使用している場合、ユーザー・アカウントの用途は、いくつかに分類される。本稿ではそれぞれのアカウントの運用方法について、開発環境の運用という視点で説明する。

●メンバーの入れ替わりとアカウント管理

　開発メンバーの増減、および入れ替わりは、しばしば発生する。このため、アカウントの管理も運用には重要な作業だ。Active Directoryでは、ユーザーだけではなく、コンピュータ・アカウントが存在しており、1台ずつ区別されている。コンピュータ・アカウントは、第1回で書いたように定期的に認証を行わないとリセットされてしまうので、注意してほしい。

　開発者用アカウントでそのアカウントを使用しなくなった場合、Active Directoryから削除していないだろうか？ 開発者が入れ替わった際、使用していたアカウントをすぐに削除すると、問題が出る。Windowsでは、アカウントは「SID（Security Identifier）」という一意の番号列で識別されている（参考：「Windows Server Insider： オブジェクトを識別するSIDとは？」）。アカウントをすぐに削除すると、WindowsはSIDからアカウント名の参照ができなくなり、ファイルの作成者がSIDで表示されてしまうため、誰が作成したファイルかすぐに分からなくなってしまう。よって、不在となったタイミングでログオンを「無効」にしておくといい。無効であれば、該当アカウントはログインできないが、SIDの関連付けが削除されていないため、ファイルの作成者情報が消えることはないからだ。

　次の画面は、削除対象のアカウントのプロパティを開いて、「無効」にしているところだ。

削除対象のアカウントのプロパティを開いて、「無効」にしているところ

　もちろん管理者はいつでもこの無効状態を解除できる。上のプロパティ画面では、［ログオン時間］および［ログオン先］（＝ログオンするサーバを選択する）を制御することもできる（いずれもボタンを押して設定する）。例えば、「重要なサーバにだけ、ログオンできないようにする」といった運用が可能だ。

●サービス・アカウントと委任

　サービス用アカウントとは、SQL Serverなどのサービスに使用する専用アカウントのことだ。サーバ・ソフトウェアのインストール中に、そのサービスで使用するユーザー・アカウント名を入力する場合がある。例えば以下の画面は、Windows Server 2012にSQL Server 2012をインストールする際に表示される画面だ。初期状態では各サービスの［アカウント名］列にはそれぞれ異なるアカウント名が表示されており、本番環境ではセキュリティ上、異なるアカウントを指定することが推奨されている。

異なるアカウント名が表示される、各サービスの［アカウント名］（※この例では、一部のアカウント名が未入力のままとなっている）

　開発環境では複数のサーバに同一のソフトウェアをインストールすることも多いので、できればサーバ・ソフトウェアのサービスごとに専用のアカウントを作った方がよい。その際、開発者が使用するユーザー・アカウントと区別するために、異なるOU（＝組織単位）に格納しておけばよい。こうしておけば、グループ・ポリシーの適用を異なったものにすることもできるので、便利だ。次の画面では、「Developers」（＝開発者用）と「ServiceAccounts」（＝サービス専用）という2つのOUを作成して、そこに適切なユーザー・アカウントを格納している。

「Developers」（＝開発者用）と「ServiceAccounts」（＝サービス専用）という2つのOU（＝組織単位）

　サーバ・ソフトウェアによっては初期値がWindows組み込みのアカウント（具体的には、LocalSystem／System／Network Serviceアカウント。参考：「Windows TIPS： サービスで使用される「System」「Local Service」「Network Service」アカウントとは？」）が指定されていることも多いだろうが、Active Directoryを運用している場合、可能な限り、ドメインのアカウントを使用することをお勧めする。

　SQL Serverなどのサーバ・ソフトウェアのサービス・アカウントに「LocalSystem」などのWindows組み込みアカウントを使わない利点は、ネットワーク・アクセスのための権限設定が容易になることだ。例えばSQL Server Agentが実行するメンテナンス作業においてネットワーク共有フォルダを使う場合、SQL Server AgentをLocalSystemアカウントで実行していると、そのままではアクセスできない。

　ほかにもTFS（Team Foundation Server）のビルド・サーバの出力先をネットワーク共有にしたい場合や、Hyper-Vでネットワーク共有上にあるISOイメージをマウントしたいことがあるだろう。また、ISOイメージをいちいちローカルにコピーするには面倒だし、ディスク容量も無駄だ。このような場合はHyper-Vコンピュータ・アカウントの委任を設定すればよい。

　これには次の画面のように、コンピュータのプロパティを開き、［委任］タブを選択する。

Hyper-Vコンピュータ・アカウントの委任設定1（コンピュータのプロパティ）

　上の画面のように［任意のサービスへの委任でこのコンピューターを信頼する (Kerberos のみ)］ラジオボタンを選択すると、全てのサービスでコンピュータ・アカウントが信頼される（次の画面を参照）。

　なおファイル共有サービスだけであれば、ファイル共有サービス用のプロトコルである「CIFS（Common Internet File System）」のみ設定すればよい。具体的には、［指定されたサービスへの委任でのみこのコンピューターを信頼する］ラジオボタンを選択したうえで［追加］ボタンを押して、ネットワーク共有を提供しているコンピュータ（次の画面の例では「Belge」）とCIFSサービスの組み合わせを追加する。

Hyper-Vコンピュータ・アカウントの委任設定2（コンピュータのプロパティ）

　実際にフォルダ共有（＝ファイル共有）をするには、Everyoneの読み取り権限を追加するか、アクセス対象のコンピュータ・アカウントを明示的に追加する必要がある。しかし、フォルダ共有で指定可能なオブジェクトに、コンピュータ・アカウントは追加されていないため、エラーになる。よって（次の画面のように）、フォルダ共有の［オブジェクトの種類］ボタンから「コンピュータ」を追加してから指定しなくてはならない。

［ユーザー、コンピューター、サービス・アカウントまたはグループの選択］ダイアログ

　［オブジェクトの種類］ボタンをクリックして、次の画面のように［コンピューター］チェックボックスにチェックを付ける。

［コンピューター］オブジェクトを指定する（［オブジェクトの種類］ダイアログ）

　これにより、［選択するオブジェクト名を入力してください］欄にコンピュータ名を指定できるようになる。コンピュータ・アカウントは以下の「wolkeschatze (MIRAGE\WOLKESCHATZE$)」のように、末尾が「$」になっている。

Hyper-Vコンピュータ・アカウントの委任設定2（コンピュータのプロパティ）

　上記のようにコンピュータ・アカウントに対する読み取り許可を指定すれば、「Belge」というファイル・サーバ上の共有フォルダにあるISOイメージが、Hyper-Vでマウントできるようになる。委任はコンピュータ・アカウントで動作するサービスがネットワーク経由でアクセスする場合において使用することがあるが、設定によっては問題になるため、使用には注意してほしい。

●ユーザー・アカウントとリモート管理

　Active Directoryの組み込みアカウントの（Domain）Administratorは使う人も多いだろう。万が一、Administratorのパスワードを忘れると、復旧作業をはじめとして、多くの作業ができなくなる。たまにしか使わないアカウントであればパスワードは忘れてしまうこともある。開発環境であれば、いっそのこと開発環境ではDomainのAdministratorを無効にして、普段使うアカウントをDomain Adminsグループに入れてしまうという手もある。もちろん、Domain Adminsグループの権限は非常に強力なので、運用には注意が必要だ。筆者はDomain Administratorアカウントは本当に管理するときだけ、リモート接続でログオンする際に使用している。

　普段使用するアカウントをDomain Adminsに入れると便利な点は、自分のローカル環境でRSAT（＝リモート・サーバ管理ツール。下記のリンク先からダウンロードできる）を使用して、シームレスに運用できるようになる点だろう。

• Microsoft ダウンロード センター： Windows 7 SP1用リモート・サーバー管理ツール
• Microsoft ダウンロードセンター： Windows 8用リモート・サーバー管理ツール(ダウンロード・センターにはリリースプレビュー用と書かれているが、Microsoft安納氏のBlogによると正式版のようだ)

　注意点として、Windows 7のRSATではWindows Server 2012を完全に管理することはできない。恐らく最も管理したいのはHyper-Vだろうが、残念ながらWindows 7ではWindows Server 2012のHyper-Vを管理できない。現時点において、Windows Server 2012のHyper-Vを管理するには、以下の3つの方法のいずれかを取るになる。

• Windows 8にRSATをインストールする
• リモート接続で管理者ログオンする
• リモート・デスクトップ・サービスを追加して、RemoteAppで起動させる

　恐らく遠くない時期にSystem Center Virtual Machine Manager 2012（以降、SCVMM 2012）のSP1がリリースされるだろう。そうなればSCVMMで統一的に管理できるはずだ（現在、SCVMM 2012 SP1 のCTP版が公開されている）。しかし、SCVMMをインストールするのも少々敷居が高いので、リモート接続経由で管理者ログオンするという方法が現実的だろう。

●不要となったサーバの削除

　不要になったメンバ・サーバおよびクライアント・コンピュータの場合は、ユーザー・アカウントと異なり、すぐにActive Directoryから削除しても問題になることは少ないだろう。Active Directory以外にもWSUS（Windows Server Update Service）やOperations Managerで管理している場合、これらの管理対象からも削除することを忘れないようにしよう。注意点として、明示的にコンピュータ・アカウントにファイル・アクセス権を付けている場合は、アクセス権から削除しておく必要がある。削除しない場合、ユーザー・アカウント同様に不明なSIDが残った状態になる。

　開発者が行うと便利なWindows Server機能という点で3回に渡って解説を行ったが、いかがだっただろうか？ Windowsには開発者が使用しても便利な機能、知らないとサーバの運用で手間がかかって損をするという機能がたくさんある。「クラウドで運用もお任せにしてしまう」という考え方もあるが、IaaSの場合はWindowsの便利機能が使えるとシステム開発にも有利だと思うので、ぜひ活用してほしい。

「連載：いまさら聞けないWindows Serverの開発活用術」