前回「(1/2)Windowsサービスアカウントを学ぶ」で過去のサービスアカウントから管理サービスアカウントの走りとなるMSAを学びました。
ここから更に進化していくのがgMSAです。さらにdMSAに続きます。
「dMSA」を理解するために、（今更ですけど）なんとなく使っていた「gMSA」ってなに？というところを学んだのでご報告します。
二代目はgMSA
「gMSA」は「グループ管理サービスアカウント」といい、Windows Server 2012 でリニューアルされたサービスアカウント機能です。前の世代のMSAという管理されたサービスアカウントが進化してgMSAとなり使えるようになりました。
公式：グループの管理されたサービス アカウントの概要
https://docs.microsoft.com/ja-jp/previous-versions/windows/server/hh831782(v=ws.11)
MSAでActive Directory環境では「管理されたサービスアカウント」を使用することができるようになり、パスワードやSPNが自動的にActive Directoryが管理してくれるようになったのですが、MSAにも制限があってこの使い勝手の向上がgMSAで実現しました。
一つ目はMSAは複数のコンピュータで同一のサービスアカウントが使えない、という点をgMSAでは複数のコンピュータで同一のサービスアカウントが使えるようになりました。
これはMSAではコンピュータ一台に対して決め打ちしてMSAのアカウントをインストールするという作業の都合上、一度割り当てられたサービスアカウントは他の（コンピュータ名が異なる）サーバでアカウントをインストールすることができない、という仕様がありました。
例えば内製アプリケーションサーバが複数台あるActive Directory環境内では、全アプリケーションサーバでMSAを統一したいと思っても一台づつMSAを用意する必要がありました。MSFCのようなクラスタ環境は2台で1台のように使いますが、コンピュータ（ノード）としては2台なので同一のMSAを配置してクラスタ上のサービスにMSAを使う、ということもできない仕様でした。
これがgMSAとなって複数のコンピュータで1つのMSAを共有することができるようになりました。gMSAを使うことで前述の制限を考慮せず、複数のサーバに（あるいは複数のサーバに跨がるサービスに対して）同じグループ管理サービスアカウント（gMSA）を割り当てることが出来るようになりました。
二つ目はMSAはタスクスケジューラでの使用が不可、という点です。
タスクスケジューラでタスクごとにユーザを指定する箇所があるのですが、この箇所にMSAを指定することができませんでした。
gMSAとなって、このタスクスケジューラで使用できない仕様は、gMSAならタスクスケジューラで使用できるようになっています。
使いドコロ
使いどころとしてはMSAと同様にサービスを起動するアカウントとしgMSAを指定することで使います。
LocalSystemとかSYSTEMアカウントとか使っているサービスを明示的にActive Directoryに登録されたgMSAアカウントで置き換える、というイメージです。
gMSAになってからのサービスアカウントは従来のMSAに加えて選択肢が四つとなります。
- gMSA
- 既存のドメインユーザアカウント
- sMSA（従来のMSA）
- 仮想アカウント
参考：Microsoft Learn：オンプレミスのサービス アカウントのセキュリティ保護
https://learn.microsoft.com/ja-jp/entra/architecture/service-accounts-on-premises
※このURL中の「適切な種類のサービス アカウントの選択」の箇所を参照
例えば、MSAやgMSAを使う前までは、
前述のような箇所に、
※画面は一例です。この画面のようにAdministratorを使うのはセキュリティ的に良くないと昔から言われています。
「既存のドメインユーザアカウント」であるAdministratorアカウントのようなDomain Adminsグループに所属する通常使うユーザアカウントを入力していたような箇所があります。
このAdministratorのパスワード欄は、前述の作業を実施した時点でのパスワードなので、時を経てドメインコントローラで「Administrator」アカウントのパスワードを変更する必要があった場合、Windows管理ツールのサービス画面からパスワードの変更を実施する必要がありました。
このAdministratorの箇所をgMSAに置き換えて、パスワード管理はActive Directoryで自動化することにより、パスワード変更が発生した時の手間や抜け漏れによるトラブルの発生を予防することができるようになります。
サービスアカウントを指定するなら、gMSAを利用するのが良いとされているのはこういうところにあるます。
MSAの進化がgMSA
ここまでのようにWindows Server 2012から導入されたグループ管理サービスアカウント（gMSA）でMSAが進化し、使い勝手の向上からサービスアカウントとしてはgMSAを使うことが一般的になってきました。
要件というのも、機能レベルがWindows Server 2008 R2以上となったActive Directoryドメインで、Windows Server 2012以降のバージョンで構築されたドメインコントローラが必要で、RSATツール（中のPowerShellのActive Directoryモジュール）のインストールが要求されますが、現状では条件を満たさないActive Directory環境のほうが少ないといえます。自然に使えそうです。
MSAではメンバサーバ1台だけで使えるという制限も、gMSAでは複数のメンバサーバで使えるようになりましたので、複数のサーバから1つのサービスを構成するような規模のサービス（IIDとかAD FSなど）でも一つのgMSAでサービスアカウントを統一することが出来るようになりました。
Windows Server 2025でさらに進化したdMSA
前置きが大分長くなってしまいましたが、Windows Server 2025でgMSAがさらに進化して
Delegated Managed Service Accounts（dMSA）
となったようです。当然ですがWindows Server 2025から提供された機能なので、今すぐ利用可能になる機能ではありません。
※委任された管理サービス アカウントのセットアップ
https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-set-up-dmsa
上記URLのページにdMSAを使用するために必要な初期の作業が解説されています。
またイベントビューア（eventvwr.msc）でdMSAイベントログを参照するための方法が記載されています。
（※イベントは「Microsoft\Windows\Security-Kerberos\Operational」に保管、デフォルト無効なためログを有効化しておく必要があります。）
dMSAと既存のgMSAやMSAとの比較が、以下のURL、
参考：Microsoft Learn：サービスアカウント
https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/manage/understand-service-accounts
※注：URL中のdMSAが新しいサービスアカウントである「Delegated Managed Service Accounts（dMSA）」となります。
このURL中の「サービス アカウントの選択」の項に従来のグループ管理サービスアカウント（gMSA）との違いを確認することができます。
dMSAは、既存の（MSAやgMSA）の置き換えが可能なサービスアカウントで、資格情報が収集されても認証が特定のマシンIDにリンクしているので、不正なアクセスを防ぐことができる、という記述が見て取れます。
実際、前述の「Microsoft Learn：サービスアカウント」にある「サービス アカウントの選択」の項を見比べてみても、gMSAで対象となっていた「複数のサーバでアプリケーションを実行」とか「ロードバランサ（LB）の杯後でアプリを実行」という箇所はdMSAではサポート外となっています。
実際に手順として置き換えが可能ではあるものの、gMSAとdMSAとは"使い分ける関係"のように見えます。
サービスアカウントを1台のサーバに制限する場合にはdMSAを使う、複数のサーバでサービスアカウントを使用する必要がある場合にはgMSAを使う、という使い分けのように見えます。
さらに高いセキュリティが要求される環境のサービスアカウントはdMSAが（gMSAより厳格な承認プロセスがあることで）ベストプラクティスになる、という感じに思えます。
