Active Directoryには、人が使う「ユーザーアカウント」のほかに、「コンピュータアカウント」や「サービスアカウント」と呼ばれるアカウントがあります。KerberosやSPNの説明では「FS01$の鍵で暗号化する」「サービスを動かすアカウントにSPNを登録する」のように当たり前に出てきますが、それぞれ何を表していて、パスワードはだれが持っているのかが分かっていないと、話がつながりません。この記事では、3種類のアカウントの違いを、パスワードの持ち方を中心に整理します。
- ユーザー・コンピュータ・サービスの3種類のアカウントが、それぞれ何を表すのか
- それぞれのパスワードをだれが決め、だれが持ち、いつ変わるのか
- サービスを動かすアカウントの種類（Local System、仮想アカウント、gMSAなど）と選び方
全体像：ADの中の3種類のアカウント
3種類の違いは、「だれ（何）を表すアカウントか」です。ユーザーアカウントは人を、コンピュータアカウントはドメインに参加したコンピュータを、サービスアカウントはサーバの上で動くサービスを表します。
見た目の役割は違いますが、3種類とも中身はよく似ています。どれもSID（Windowsがアカウントを見分ける番号）とパスワードを持っていて、Kerberosで認証を受けられます。このように「認証を受けて、アクセス許可の対象になれるもの」をまとめて、セキュリティプリンシパルと呼びます。実際、ADの中ではコンピュータアカウントはユーザーアカウントの一種として定義されています。
| ユーザーアカウント | コンピュータアカウント | サービスアカウント | |
|---|---|---|---|
| 表すもの | 人 | ドメインに参加したコンピュータ | サーバで動くサービス |
| 名前の例 | user01 | FS01$ | svc-web、gmsa-web$ |
| 作られるとき | 管理者が作る | ドメインに参加したとき | 管理者が作る |
| パスワードを決める人 | 本人 | コンピュータ自身（自動） | 種類による（管理者、または自動） |
| パスワードが変わるとき | パスワードポリシーに従って本人が変える | 既定では30日ごとに自動 | 種類による |
ユーザーアカウント：人を表す
いちばんなじみがあるのがユーザーアカウントです。社員一人ひとりに1つずつ作り、PCへのサインインやメール、ファイル共有に使います。パスワードは本人が決めて、本人だけが知っています。DCが持っているのは、パスワードそのものではなく、パスワードから作った鍵です。
PCにサインインするとき、PCは入力されたパスワードから鍵を作り、その鍵でDCとKerberosのやり取りをします。DCは自分が持っている鍵と照らし合わせて、本人かどうかを確かめます。本人がパスワードを変えると、DCの鍵も新しいものに変わります。
コンピュータアカウント：コンピュータを表す
PCやサーバをドメインに参加させると、ADにそのコンピュータのアカウントが作られます。名前はコンピュータ名の最後に $ を付けたもので、FS01というサーバならFS01$です。この $ が、コンピュータアカウントの目印です。
コンピュータアカウントにもパスワードがあります。ただし、人がパスワードを決めたり入力したりすることはありません。
| だれが | どこに持っているか |
|---|---|
| コンピュータ（FS01） | LSAシークレットという、SYSTEMの権限でしか読めない保護された場所 |
| DC | ADのデータベース（パスワードから作った鍵として） |
パスワードはドメイン参加のときに決まり、その後は既定で30日ごとに、コンピュータが自分で新しいパスワードを決めてDCにも書き込みます。人が関わらないので、長く複雑なパスワードを保てます。
コンピュータアカウントは、次のような場面で使われます。
| 場面 | 使われ方 |
|---|---|
| DCとの安全な通り道 | コンピュータとDCは、このパスワードを使って「セキュアチャネル」という安全な通信路を作る。ユーザーのNTLM認証をDCに頼むときなどに使う |
| サービスの受け手として | ファイル共有などOSのサービスにKerberosでアクセスされるとき、サービスチケットはコンピュータアカウントの鍵で暗号化される。HOST/fs01.corp.example.com などのSPNもコンピュータアカウントに登録されている |
| サービスがネットワークに出るとき | Local SystemやNetwork Serviceで動くサービスが別のサーバにアクセスすると、相手からはFS01$としてアクセスしてきたように見える（次の節で説明） |
コンピュータとDCのパスワードがずれると、そのコンピュータはDCと安全に通信できなくなり、ドメインのアカウントでのサインインやアクセスが失敗するようになります。よくあるのは、古いスナップショットやバックアップに戻したときです。戻したコンピュータは古いパスワードを持っていて、DCは新しいパスワードを持っているため、ずれが起きます。PowerShellの Test-ComputerSecureChannel で状態を確かめられます。
サービスアカウント：サービスを表す
Windowsのサービスは、人がサインインしていなくても動き続けます。そのため、サービスは「だれの権限で動くか」を、サービスごとに設定で決めています。これがサービスの実行アカウントです。サービスの設定画面の「ログオン」タブで指定しているものです。
「サービスアカウント」という言葉は、少し広い意味で使われます。Microsoftのドキュメントでは、サービスに権限を与えるために作ったユーザーアカウントをサービスアカウントと呼んでいます。いっぽうで、gMSAのように、サービス専用に用意されたアカウントの種類もあります。サービスを動かす方法は、大きく分けると次のとおりです。
| 種類 | どんなものか | パスワードの管理 |
|---|---|---|
| Local System | OSに最初からある、権限がとても強いアカウント。多くのOSのサービスが使う | パスワードなし |
| Network Service | ローカルの権限を小さくしたアカウント | パスワードなし |
| Local Service | ローカルの権限が小さく、ネットワークには匿名で出る | パスワードなし |
| 仮想アカウント | サービスごとに自動で用意されるローカルのアカウント。名前は NT SERVICE\サービス名。SQL Serverの既定の設定などで使われる | 不要（Windowsが管理） |
| ドメインのユーザーアカウント （従来のサービスアカウント） | サービス用に作ったふつうのユーザーアカウント。どのサーバでも使える | 管理者が決めて、手で変える |
| sMSA | 1台のサーバ専用の管理サービスアカウント | 自動 |
| gMSA | 複数台のサーバで共有できる管理サービスアカウント | 自動（DCが管理） |
| dMSA | Windows Server 2025で追加。従来のサービスアカウントを置き換えられ、認証を特定のコンピュータに結び付ける | 自動（ランダムな鍵） |
このうち上の4つは、そのサーバの中だけのアカウントです。ネットワーク越しに別のサーバへアクセスするときは、別の名前で見えます。
Local System、Network Service、仮想アカウントで動くサービスは、ネットワークではコンピュータアカウント（FS01$）として認証されます。そのため、別のサーバの共有フォルダに、このサービスからアクセスさせたいときは、ACLにFS01$（またはFS01$が入っているグループ）を追加します。Local Serviceは匿名として扱われるので、ネットワーク越しのアクセスにはほとんど使えません。
ドメインのアカウント（ユーザーアカウント、sMSA、gMSA、dMSA）で動くサービスは、そのアカウント自身として認証されます。サービスごとに権限を分けたいときや、複数台のサーバで同じ名前で動かしたいときに使います。
従来のサービスアカウントの困りごと
ドメインのユーザーアカウントをサービスに使う方法は、昔からよく使われてきました。ただ、次のような困りごとがあります。
- パスワードを管理者が決めて、各サーバのサービスの設定に入力する必要がある
- パスワードを変えると、全部のサーバで入力し直す必要がある。そのため、無期限のパスワードのまま放置されがち
- 人が決めたパスワードなので短くなりやすく、SPNを付けると「Kerberoasting」という攻撃でパスワードを割り出されるおそれがある
sMSA、gMSA、dMSAは、この困りごとを解決するために用意されたアカウントの種類です。名前の最後には、コンピュータアカウントと同じく $ が付きます。
gMSAでは、パスワードをDCが計算して管理します。どのサーバがパスワードを受け取ってよいかをアカウントに設定しておくと、許可されたサーバだけがDCから自動でパスワードを受け取ります。パスワードは240バイトのランダムな値で、既定では30日ごとに変わります。管理者はパスワードを知らなくてよく、複数台のサーバで同じgMSAを使えます。使うには、ドメインに「KDSルートキー」を一度作っておく必要があります。
サービスアカウントの選び方
どれを使うかは、サービスがどこで、どう動くかで決まります。目安は次のとおりです。
OSに付いてくるサービスは、既定のアカウントを変えないのが基本です。自分で入れるアプリは、製品のマニュアルで対応しているアカウントの種類を確かめてから選びます。gMSAなどに対応していないアプリでは、従来どおりユーザーアカウントを使いますが、その場合は長く複雑なパスワードにして、必要以上の権限を与えないようにします。
KerberosやSPNとの関係
ここまでの話を、Kerberosの側から見るとこうなります。
| サービスの実行アカウント | SPNを登録する場所 | サービスチケットを暗号化する鍵 |
|---|---|---|
| Local System、Network Serviceなど | コンピュータアカウント（FS01$） | FS01$のパスワードから作った鍵 |
| ドメインのユーザーアカウント（svc-web） | svc-web | svc-webのパスワードから作った鍵 |
| gMSA（gmsa-web$） | gmsa-web$ | gmsa-web$のパスワード（DCが管理）から作った鍵 |
DCとサービス側の両方が同じパスワード（鍵）を知っているので、DCが作ったサービスチケットをサービスが開けられます。実行アカウントを変えたら、SPNも新しいアカウントに移す必要があるのはこのためです。
確認に使うコマンド
PC（コマンドプロンプト）：今サインインしているユーザーの名前とSIDを表示する
whoami /user
管理用PC（PowerShell）：ユーザーアカウントの最後にパスワードを変えた日時を表示する
Get-ADUser -Identity user01 -Properties PasswordLastSet | Select-Object Name, PasswordLastSet
管理用PC（PowerShell）：コンピュータアカウントのパスワードを最後に変えた日時とSPNを表示する
Get-ADComputer -Identity FS01 -Properties PasswordLastSet, ServicePrincipalNames | Select-Object Name, PasswordLastSet, ServicePrincipalNames
ドメインに参加したPC（PowerShell・管理者）：DCとのセキュアチャネルが正常かを確かめる
Test-ComputerSecureChannel -Verbose
サーバ（PowerShell）：サービスごとの実行アカウントを一覧で表示する
Get-CimInstance -ClassName Win32_Service | Select-Object Name, StartName | Sort-Object StartName
管理用PC（PowerShell）：ドメインにある管理サービスアカウント（sMSA、gMSAなど）を一覧で表示する
Get-ADServiceAccount -Filter *
サーバ（PowerShell・管理者）：このサーバでgMSAを使えるかを確かめる
Test-ADServiceAccount -Identity gmsa-web
Get-ADUser などのコマンドには、RSATのActive Directoryモジュールが必要です。
まとめ
| アカウント | ひとことで |
|---|---|
| ユーザーアカウント | 人を表す。パスワードは本人が決め、DCはパスワードから作った鍵を持つ |
| コンピュータアカウント | コンピュータを表す。名前の最後に $ が付き、パスワードはコンピュータが自動で決めて30日ごとに変える |
| サービスアカウント | サービスを動かすためのアカウント。Local Systemなどのローカルのもの、ドメインのユーザーアカウント、gMSAなどの管理サービスアカウントがある |
| ネットワーク上の見え方 | Local System、Network Service、仮想アカウントはコンピュータアカウントとして、ドメインのアカウントはそのアカウント自身として見える |
| Kerberosとの関係 | サービスチケットは、サービスの実行アカウントの鍵で暗号化される。DCとサービスの両方がその鍵を知っている |
「このサービスはだれとして動いているか」「そのアカウントのパスワードはだれが持っているか」を押さえておくと、アクセス許可の設定やKerberosのトラブルを考えるときの土台になります。
- Service accounts（Microsoft Learn）
- Group Managed Service Accounts overview（Microsoft Learn）
- Delegated Managed Service Accounts overview（Microsoft Learn）
- Secure on-premises computer accounts with Active Directory（Microsoft Learn）
- Creating a New Computer Account（Microsoft Learn）
- Computer class（Microsoft Learn）
- Event ID 5722 is logged on your domain controller（Microsoft Learn）
- Broken trust relationship between a domain-joined device and its domain due to secure channel issues（Microsoft Learn）
- Credentials processes in Windows authentication（Microsoft Learn）
- Account Database（Microsoft Learn）
- Service User Accounts（Microsoft Learn）
- LocalSystem Account（Microsoft Learn）
- NetworkService Account（Microsoft Learn）
- LocalService Account（Microsoft Learn）
コメント