Windows Serverを複数人で管理する場合ログオンユーザーはどうすべき?

Windows Server
スポンサーリンク

Windows Serverを管理する際のログオンユーザーについて。セキュリティ面以外に、管理に必要なログオン環境を複数メンバーで共有する必要を考えると、悩むことがあります。大規模なシステムではないということを前提として、私が考えて採用している方法を紹介します。

悩みごと

ドメインに参加したWindows Serverについて、複数メンバーで構築・保守する場合、ログオンユーザーはどのユーザーにすべきか?

サーバーによっては、ローカルユーザー(ローカルのAdministratorなど)で済むケースもある。しかし、Webシステムや共有フォルダなどのドメインリソースの認証にドメインユーザーが必要なケースもある。そのようなケースでは、ドメインユーザーでログオンする方が都合がよく、どのユーザーでログオンすべきか迷う。

方策案

次の選択肢について、上から順番に検討していき、可能なものを採用しています。

  1. ドメインの個人用ユーザー
  2. ローカルユーザー
  3. サーバー管理用のドメインユーザー

解説

上の選択肢ごとに、メリット・デメリットを考えていきます。

個人用のドメインユーザー

ドメイン内で、個人毎に割り当てられたユーザーアカウントです。基本的にその個人のみが認証でき、他人は使うことはできません。必ず用意されているかというと、そうでもありません。「他社のサーバーエンジニア」用の個人用ユーザーなんてものが、そもそも用意されていない場合も考えられます。

  • メリット
    • ドメインリソースにアクセスできる
    • 操作ログなどから「誰が何をやったか」を識別しやすい
  • デメリット
    • 複数メンバーで管理する場合、ユーザー環境(設定)が共有できない

該当するユーザーが使えて、かつ上記デメリットが許容できるなら、まずはこれを採用するのが良いと思います。

共用のローカルユーザー

ドメインユーザーでなく、サーバー毎のローカルユーザーです。ビルトインのAdministratorや、ローカルに追加したユーザーです。該当サーバーにログオンするメンバー全員で、このユーザーを共用します。

  • メリット
    • 複数メンバーで管理する場合でも、ユーザー環境(設定)が共有できる
    • ユーザーアカウントの作成が容易(あるいは不要)
  • デメリット
    • ドメインリソースにアクセスできない(ドメインユーザーの資格情報の入力が必要)
    • 複数メンバーで管理する場合、操作ログなどから「誰が何をやったか」を識別しにくい
    • パスワードを知るメンバーが抜ける場合、パスワード変更が必要

個人用のドメインユーザーを使えないなら、実質的には共用のユーザーを使わざる得ないと思います。では、そのユーザーを、ドメインユーザーにするか、ローカルユーザーにするか。ポイントは、ドメインリソースにアクセスする必要があるかどうかです。もし無いなら、ローカルユーザーの方が楽かもしれません。ドメイン管理者に申請が不要ですし・・・。

共用のサーバー管理用ドメインユーザー

ドメインに「○○APサーバー管理ユーザー」みたいなユーザーアカウントを作り、それを使用します。例えばAPサーバーとDBサーバーが別なら、一緒にせず分けて作ったほうが良いと思います。該当サーバーにログオンするメンバー全員で、このユーザーを共用します。

  • メリット
    • ドメインリソースにアクセスできる
    • 複数メンバーで管理する場合でも、ユーザー環境(設定)が共有できる
  • デメリット
    • 複数メンバーで管理する場合、操作ログなどから「誰が何をやったか」を識別しにくい
    • パスワードを知るメンバーが抜ける場合、パスワード変更が必要
    • ユーザーアカウントの作成・管理の手間がかかる(申請など)

上の二つで都合が悪ければ、このようなユーザーを作る他ないかと思います。

そのほかの選択肢(NG)

「みんなでドメインのAdministrator(Domain Admins)を使っている」というケースも見られますが、これは避けるべきです。その理由は別記事で解説しています。

補足

サービス実行用とログオン用で別ユーザーにする

システムサービスの実行用ユーザーとして「SYSTEM」や「LOCAL SERVICE」 などがよく使われます。しかし、ドメインリソースの認証のためにドメインユーザーを使うケースがあります。その場合に、ログオン用ユーザーではなく、サービス専用のユーザーを用意する方が良いと思います。

なぜなら、前述のように、メンバー変更時などにログオン用ユーザーのパスワード変更が必要になる可能性があるからです。同じユーザーをサービス用としても使っていると、パスワードを変更したときに動かくなる危険があります。構築時は意識していても、いざその時のメンバーが忘れていることを考えて、あらかじめユーザーを分離しておくのが良いでしょう。

フィードバック

コメント

タイトルとURLをコピーしました