マネージド サービス アカウント (MSA および gMSA) を使用してサービスとスケジュールされたタスクを管理する方法
サービスやスケジュールされたタスクのパスワード管理にうんざりしているなら、マネージド サービス アカウント (MSA) とグループ マネージド サービス アカウント (gMSA) がまさに救世主です。パスワード変更は自動的に処理され、何より嬉しいのは、従来のパスワード管理から解放されることです。もちろん、これらは主にドメイン参加型の環境向けですが、AD を導入していて、資格情報の管理に煩わされることなく安全に作業を実行する必要がある場合は、これらが最適です。正直なところ、その仕組みは少し奇妙ですが、一度設定してしまえば、本当に助かります。さらに、gMSA を使えば複数のサーバーにまたがって実行できるため、アプリのスケーリングやクラスタリングを行う際の負担を軽減できます。Windows サーバーや AD に接続された PC 上のサービスやスケジュールされたジョブ用にこれらのアカウントを作成、インストール、使用する方法について、以下に詳しく説明します。
- Active Directoryで管理アカウント（MSA）を作成する方法
- Active Directory でグループ管理サービス アカウント (gMSA) を作成する
- Windowsにマネージドサービスアカウントをインストールする
- Windows サービスを管理されたサービス アカウントとして実行する方法
- 管理されたサービス アカウント (gMSA) を使用して Windows のスケジュールされたタスクを実行する
まず、AD には主に 2 つの種類があります。
- MSA : 単一サーバーでの使用には適しています
msDS-ManagedServiceAccountが ( )、クラスタリングや複数サーバーでの使用には適していません。通常、これは1台のマシンで実行されるサービス向けです。 - gMSA : Windows Server 2012 で導入され、複数のサーバーを対象としており、共通の ID を必要とするクラスター化されたアプリやサービスに最適です (
msDS-GroupManagedServiceAccount)。
Active Directoryで管理アカウント（MSA）を作成する方法
MSAを作成する前に、KDSルートキーを生成する必要があります。そうしないと、ADはMSAのパスワードを生成できません。コマンドはシンプルですが、一度だけ実行します。powershell Add-KdsRootKey –EffectiveImmediately を実行すると、キーの作成が開始されます。ただし、ほとんどの環境では、ADレプリケーションによるキーの同期に約10時間かかるため、すぐに完了するとは限りません。テスト中または急いでいる場合は、次のコマンドですぐに有効にすることができます: powershell Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10)) とにかく、キーが存在することを確認するには、次のコマンドを実行します: powershell Get-KdsRootKey その後、次のコマンドで検証します: powershell Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId 一度整理すると、MSA の作成は簡単です: powershell New-ADServiceAccount -Name msaAppService -RestrictToSingleComputer おそらく、この MSA を特定のサーバーに結び付けて、安全にサービスを実行できるようにする必要があります。そのためには、AD でコンピューターのオブジェクトを取得し、サービスアカウントを追加します。powershell $identity = Get-ADComputer -Identity “Server01” Add-ADComputerServiceAccount -Identity $identity -ServiceAccount msaAppService ADUC の CN=Managed Service Accounts の下にアカウントが表示されていることを再度確認することをお勧めします。ただし、ADUC の 表示 メニューで *高度な機能* をオンにしない限り、このコンテナーは非表示になります。非表示のものは誰も好みません。
Active Directory でグループ管理サービス アカウント (gMSA) を作成する
GMSAは少し複雑ですが、複数のサーバーで同じIDが必要な場合に非常に便利です。まず、このgMSAを実行するサーバーを追加するためのADセキュリティグループが必要です。グループを作成します: powershell New-ADGroup -Name grWebServers -Path “OU=Servers, DC=domain, DC=com” -GroupScope Global そして、次のようにサーバーを追加します: powershell Add-ADGroupMember -Identity grWebServers -Members server01$, server02$, server03$ 完了したら、gMSA を作成し、許可されたプリンシパルとしてサーバー グループを指定します: powershell New-ADServiceAccount -Name gmsaWebApp -DNSHostName gmsaWebApp.domain.com -PrincipalsAllowedToRetrieveManagedPassword grWebServers -Verbose サーバーをグループに追加したばかりの場合は、サーバーを再起動するか、AD グループ キャッシュを更新します: cmd klist.exe -lh 0 -li 0x3e7 purge (はい、これで Kerberos チケット キャッシュが更新されます)。gMSA は Managed Service Accounts OU に自動的に表示され、AD はパスワードのローテーションをシームレスに処理します。 Kerberos SPN 登録を必要とするサービスの場合は、SPN を設定する必要があります: cmd setspn -s MSSQLSvc/mssql01 domain\gmsaWebApp$ setspn -s MSSQLSvc/mssql01.domain.com domain\gmsaWebApp$ この部分は一部の人を混乱させますが、SQL Server やその他の Kerberos 依存のアプリにとっては不可欠です。
Windowsにマネージドサービスアカウントをインストールする
Windows で MSA または gMSA を使用するには、Active Directory モジュールの準備ができていることを確認します: powershell Add-WindowsFeature RSAT-AD-PowerShell 次に、サーバーにアカウントをインストールします: powershell Install-ADServiceAccount -Identity gmsaWebApp ここで、MSA の場合は、Windows が認識できるようにインストールする必要があります。一方、GMSA は、AD が認識し、サーバーにアクセス許可があれば自動的に使用可能になります。動作しているかどうかを確認します: powershell Test-ADServiceAccount gmsaWebApp True が返された場合は、問題ありません。False の場合、アカウントが正しくインストールされていないか、アクセス許可が不足している可能性があります。 補足: 通常の RunAs では、MSA を使用してサービスを実行することはできません。代わりに、サービス構成または PowerShell でアカウントを指定する必要があります。テストには*PsExec*を使うことができます：cmd PsExec64.exe -i -u domain\gmsaWebApp$ -p ~ cmd.exe `~`は、理論上はWindowsがADからパスワードを自動的に取得するためのプレースホルダです。その後、内部で`whoami`を実行して確認します。
Windows サービスを管理されたサービス アカウントとして実行する方法
ここからが本題です。MSA または gMSA でサービスを実行するように設定するには、次の手順に従ってください。- `services.msc` を開きます。- 必要なサービスを見つけます。- 右クリックして [プロパティ] を選択し、[ログオン] タブに移動します。- アカウント を選択し、末尾に `$` が付いたアカウント名を入力します (例: `domain\gmsaWebApp$`)。- パスワードは不要です。Windows が自動的に権限を付与します。- [OK] をクリックして、サービスを再起動します。IIS アプリ プールでも同様です。ID をカスタム アカウントに設定できます。IIS にアクセスし、アプリ プールを選択して [詳細設定] をクリックします。*Identity* を `ApplicationPoolIdentity` から *Custom Account* に変更し、`
管理されたサービス アカウント (gMSA) を使用してスケジュールされたタスクを実行する
gMSA としてスケジュールされたタスクを実行するのは GUI では少々面倒です。Microsoft はこのために PowerShell を強く推奨しています。PowerShell でタスクを作成します。powershell $action = New-ScheduledTaskAction -Execute powershell.exe -Argument “-file C:\Scripts\Backup.ps1 -executionpolicy bypass” $trigger = New-ScheduledTaskTrigger -At 23:00 -Daily $principal = New-ScheduledTaskPrincipal -UserID domain\gmsaWebApp$ -LogonType Password -RunLevel Highest Register-ScheduledTask -TaskName “DailyBackup” -Action $action -Trigger $trigger -Principal $principal 注: gMSA アカウントでは -UserID を指定する必要があります。一部の設定では、GUIで作成されたタスクは、PowerShellまたはschtasks.exeを使用しない限りgMSAを受け付けません。cmd schtasks /Create /TN “Backup” /TR “powershell.exe -file C:\Scripts\Backup.ps1” /SC DAILY /ST 23:00 /RU “domain\gmsaWebApp$” 権限については、gMSAをBackup Operatorsグループに追加して読み取り/書き込み権限を付与し、ローカルグループポリシー（`gpedit.msc`）でバッチジョブとしてログオン権限を付与する必要があります。gMSAの利点は？Windowsがパスワードを自動更新するため、スケジュールされたタスクが中断されないことです。アップデートや再構成は不要です。—
基本的に、マネージドサービスアカウント、特にgMSAはセキュリティを合理化し、手間を軽減します。設定には事前に少し手間がかかりますが、一度設定すれば、サービスとスケジュールはパスワード入力に煩わされることなくスムーズに実行されます。それでも問題が解決しない場合は、権限やGPOを確認するか、ADサービスを再起動してレプリケーションを待つだけでも良いでしょう。この情報が誰かの頭痛の種を解消するのに役立つことを願っています。
まとめ
- gMSA パスワード生成用の KDS ルート キーを作成しました。
- コンピューターまたはグループにリンクされた MSA と gMSA を AD に設定します。
- Windows サーバーに MSA/gMSA をインストールしました。
- 管理対象アカウントで実行するようにサービスと IIS を構成しました。
- PowerShell または schtasks を使用して、gMSA アカウントでスケジュールされたタスクを設定します。
まとめ
これらの管理アカウントをうまく連携させるには少し手間がかかりますが、一度設定してしまえば、生活はずっと楽になります。パスワードをあちこちに持ち歩く必要も、手動で更新する必要もなく、安全で自動化されたサービスが稼働するだけです。これで、数ヶ月ごとにサービスが停止することなく稼働するサービスが一つ増えれば、ミッション達成です。他の方にも同じように機能することを願っています。