【IDM】Active Directory Federation Service が起動できない場合にはサービスアカウントのパスワードをリセットしてみる
Active Directory の最新情報をキャッチアップ！ クラウド時代の Active Directory 次の一手シリーズ 第1回～6回 公開中! 第 1 回 Active Directory の位置づけ 第 2 回 Active Directory ドメイン サービスの新しい役割 第 3 回 Active Directory フェデレーション サービスの役割 解説編 第 4 回 Active Directory フェデレーション サービスの役割 構築編 第 5 回 認証のためのプロキシ Web Application Proxy 第 6 回 Microsoft Azure Active Directory とは |
たったいまこんなことがありました。
Windows Server 2012 R2 上にインストールされている Active Directory Federation Service が「開始中」のまま起動できないのです。30分ほど待ってみましたが、まったく状況は変わりません。もちろん、AD FS に依存している Device Registration Service も起動していません。
AD FS の構成情報が格納されている Windows Internal Database は正しく起動しているようなので、Directory Service の問題かと考えイベントログを調べました。
すると、以下の警告ログが大量に見つかりました。
Event ID 2947
グループ管理サービス アカウントのパスワードを取得できませんでした。
「グループ管理サービス アカウント（gMSA：Group Managed Service Account）」とは、Windows Server 2012 でリニューアルされたサービスアカウント機能です。手元の環境では AD FS のサービスアカウントとして gMSA を設定してあるのですが、どうやらそのパスワードを取得できないことにより、AD FS が起動できない模様です。
ここですこしだけ gMSA について解説しておきます。ご存知ない方は読んでおいてください。
Winodws Server 2008 以前、サービスに使用する「サービスアカウント」は、ユーザーアカウントと同様に作成する必要がありました。ユーザーアカウントと同様の扱いなので、安全上の配慮からパスワードの変更を行った時には、サービスのアカウント設定画面でパスワードも再設定する必要がありました。
もちろん、Builtin のローカル システム アカウント等を使用することで、パスワードリセットの手間を省くことも可能ではあります。
しかし、サービスが多様化するに従い、サービスアカウントに必要な権限も多様化しました。それ以上に、強い特権を持っている Builtin ローカル システム等を使用することは、システム全体の安全性を脅かすことにもなります。
そこで、Windows Server 2008 R2（Windows 7も含む）では「管理サービスアカウント（MSA：Managed Service Account）」というアカウントがサポートされました。
MSA を使用すると、サービスに独自のアカウントを作成して、必要な権限を与えることが可能です。また、パスワードが自動管理されるため、一度作成して以降は手動でパスワードを変更する必要がありません。
ただ、これですべてが解決されたわけではありませんでした。
MSA には以下の制限があったのです。
- 複数のコンピューターで共有できない
MSAは、作成したら「特定のコンピューターにアカウントをインストールする」という作業が必要で、一度インストールされたアカウントは他のコンピューターにインストールすることができないのです。この制限は結構残念で、例えばクラスター化されたノード上のサービス間で共有したり、複数の IIS サービスで共有するといったことができませんでした。もちろん、AD FS をファーム構成にした場合にも同様です。- MSAはアプリケーションレベルでサポートされる
ちょっと意味が分かりずらいと思いますが、OS が MSA をサポートしているからといって、その上で動作するアプリケーションも MSA をサポートするわけではないということです。事実、Exchange の一部の機能や SQL Server では MSA をサポートしていませんでした。- タスクスケジューラーで使用できない
これも結構残念です。Windows Server 2012 でサポートされた「グループ管理サービスアカウント（gMSA） 」では、以下の通り"ある程度"制限が解除されています。
- 複数のコンピューターで共有できる
フェールオーバークラスターのサービスアカウントとして使用することはできませんが、クラスター化されたノード上のサービス間で共有することは可能です。- タスクスケジューラーで使用できる
アプリケーションでのサポートについては、実は従来通りの制限があります。どのアプリケーションが gMSA をサポートしているかは、その都度調べる必要があります。ちなみに、AD FSでは問題ありません。
話を戻しましょう。
冒頭に示したエラーを解消する方法を探したのですが、「これ！」というものが見つかりませんでした。
そこで、試しに gMSA のパスワードをリセットしてみることにしました。
まずは、PowerShell コンソールから以下のコマンドレットを使用して gMSA の情報を出力します。
PS C:\Windows\system32> Get-ADServiceAccount -Filter *
DistinguishedName : CN=FsGmsa,CN=Managed Service Accounts,DC=itcampjp,DC=com Enabled : True Name : FsGmsa ObjectClass : msDS-GroupManagedServiceAccount ObjectGUID : 86e6d9df-1621-48ab-b915-fe11aa58fa75 SamAccountName : FsGmsa$ SID : S-1-5-21-1369388327-1626757837-1784127236-1126 UserPrincipalName :
gMSA の sAMAccountName を見てください。アカウント名の後ろに 「$」がついていることに注意してください。
次に、以下のコマンドレットで、gMSA のパスワードをリセットします。
PS C:\Windows\system32> Reset-ADServiceAccountPassword fsgmsa$
私の手元の環境では、リセットが完了するまでに 30 秒程度要しました。なので、なかなか終わらなくても安心してください。
リセット完了後、イベントログに以下のメッセージが表示されたらしめたものです。
イベントID 2946
発信者がグループ管理サービス アカウントのパスワードを正常に取得しました。
AD FS も正常に起動することができました。
なぜ gMSA のパスワードが取得できない状態になってしまったのかは、現時点では判明しておりません。
この環境が仮想環境で、2週間程 起動していなかったことが影響している可能性があります。
gMSA のパスワードは、既定では 30日で自動更新されるのですが、それが影響しているようでもありません。この点は継続して調べてみたいと思います。
