ハイブリッドAD環境で特定ユーザーに180日パスワード期限を設定する方法：FGPPとEntra ID連携のポイント

オンプレミスのActive DirectoryとMicrosoft Entra IDを組み合わせたハイブリッド環境では、パスワード有効期限のような基本的な設定であっても一筋縄ではいかないことがあります。しかし、特定のユーザーだけに180日ごとのパスワード変更を促したいというケースはよくあり、そのポイントを理解すればシンプルかつ柔軟に運用できます。ここでは、オンプレミス側の「きめ細かいパスワードポリシー (Fine-Grained Password Policies, FGPP)」の活用方法や、Microsoft Entra ID（旧Azure AD）との連携を踏まえた設定・注意点を詳しく解説していきます。

ハイブリッド環境におけるパスワード有効期限設定の基本

ハイブリッド環境は、オンプレミスのActive Directory (以下AD) とクラウド側のMicrosoft Entra ID（旧Azure AD）が同期されている状態を指します。ユーザーは通常、オンプレミスADで管理された資格情報を利用してMicrosoft 365（旧Office 365）や各種SaaSにシングルサインオン（SSO）する形が一般的です。この場合、多くの企業・組織ではオンプレミスAD側にパスワードの有効期限を設定し、クラウドへそのポリシーを反映する運用が行われています。

なぜハイブリッド環境だと複雑になるのか

ハイブリッド環境では、パスワードハッシュ同期 (PHS) やパススルー認証 (PTA) を使ってAzure ADと同期を行い、クラウド側の認証に反映します。しかし、パスワードの有効期限や複雑性などのポリシーは、オンプレ側で設定されている内容が基本的に優先されます。Azure AD側にもパスワードポリシーはあるものの、クラウド専用アカウント（非ハイブリッドアカウント）に適用されるケースが多く、ハイブリッドユーザーの場合はAD側の設定に従うため、Azure ADだけではきめ細かな制御がしにくいのが実情です。

特定ユーザーだけ有効期限を設定するニーズ

• 機密情報にアクセスする一部のユーザーだけパスワードを頻繁に更新したい
• 新入社員や外部委託の方など、運用上パスワード管理を厳格にしたいユーザーがいる
• 一般社員には長期の有効期限を設定し、管理負担を下げたい

こうしたニーズは多く、「全ユーザーに一律のパスワード有効期限を適用するわけにはいかない」という場面も珍しくありません。

Fine-Grained Password Policies (FGPP) の基本

Active DirectoryにはWindows Server 2008以降、FGPP (きめ細かいパスワードポリシー) という機能が備わりました。これを利用すると「特定のセキュリティグループやユーザー」にだけ別のパスワード有効期限や複雑性要件を適用できます。

FGPPの適用方法

FGPPは、通常のグループポリシー (GPO) とは異なり、ADのドメイン機能レベルがWindows Server 2008以上である必要があります。また、ドメイン全体に対する既定のパスワードポリシーとは独立して動作するため、適切に構成しないと衝突する可能性がある点に注意が必要です。設定手段としては下記の2つが代表的です。

1. ADSI Editを利用する方法

• 「Active Directory ユーザーとコンピューター」ではFGPPの設定を直接行えないため、ADSI EditやPowerShellなどを使います。
• msDS-PasswordSettingsオブジェクトを手動で作成し、適用先のユーザーやグループを指定します。

1. PowerShell (ActiveDirectoryモジュール) の利用

• PowerShellのコマンドレットを使うと比較的わかりやすく、構成しやすいのがメリットです。
• たとえばNew-ADFineGrainedPasswordPolicyやAdd-ADFineGrainedPasswordPolicySubjectを使い設定・適用します。

PowerShellによる設定例

# Active Directoryモジュールのインポート
Import-Module ActiveDirectory

# 新しいFGPPオブジェクトを作成（例：180日有効期限、14日前から警告）
New-ADFineGrainedPasswordPolicy -Name "FGPP-180Days" `
    -ComplexityEnabled $true `
    -Precedence 20 `
    -ReversibleEncryptionEnabled $false `
    -PasswordHistoryCount 5 `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:30:00" `
    -LockoutThreshold 5 `
    -MinPasswordLength 8 `
    -MinPasswordAge "1.00:00:00" `
    -MaxPasswordAge "180.00:00:00" `
    -PasswordSettingsPrecedence 20 `
    -MaxBadPasswordAttempts 5

# 適用したいグループ（例：MySecurityGroup）をFGPP-180Daysポリシーの対象に追加
Add-ADFineGrainedPasswordPolicySubject -Identity "FGPP-180Days" -Subjects "CN=MySecurityGroup,OU=Groups,DC=example,DC=local"

上記のように、新しいポリシーを作成し、適用先となるセキュリティグループを指定します。これにより、そのグループに所属するユーザーだけが180日のパスワード有効期限を強制されるようになります。

FGPP運用のポイント

• Precedence値: もし複数のFGPPが同一のユーザーに対して適用される可能性がある場合、Precedence値（優先順位）が小さいほうが優先されます。
• グループの管理: FGPPを適用したいユーザーを集めたグループのメンテナンスが重要です。誤って別のグループにも所属していると、予期しないパスワードポリシーが適用されるケースもあります。
• ドメイン機能レベル: FGPPを使うにはドメインとフォレストの機能レベルがWindows Server 2008以上であることが前提です。Windows Server 2003互換などで運用している環境では利用できないので注意が必要です。

Microsoft Entra ID（旧Azure AD）との連携

一度オンプレミスADでパスワード有効期限を設定すれば、パスワードハッシュ同期(PHS)やパススルー認証(PTA)を経由して、クラウド側にも反映されます。ユーザーがMicrosoft 365にサインインする際にパスワード期限が近づくと、Microsoft 365の画面上で「パスワードを変更してください」のような通知が表示されるようになります。

ユーザー通知の流れ

1. パスワード期限切れのカウントダウン
   オンプレ側のポリシーで定義した有効期限までの日数をベースに、期限が近づいたらクラウド側でも自動的に警告が出ます。
2. 変更要求の同期
   ユーザーがパスワード変更を実行すると、それはオンプレADで認証され、同期によってクラウドに新しいパスワードが反映されます。
3. 一括変更の回避
   全ユーザーを対象としないため、特定グループだけが180日周期で変更する仕組みが成り立ち、無駄な混乱を招くリスクが減ります。

クラウド専用アカウントとの違い

• クラウド専用アカウント: Azure AD側で直接作成されたアカウント。パスワードポリシーはAzure ADのものに従う。
• ハイブリッドアカウント: オンプレミスADから同期されたアカウント。パスワードポリシーは基本的にオンプレミスADのものを継承。

今回のようにオンプレADと同期されているユーザーを対象にしたい場合は、Azure AD Premiumのライセンス機能を活用したとしても、最終的にはオンプレ側の設定が優先されるため、FGPPを正しく設定することが最も確実です。

ハイブリッド環境での実務的な手順

ここからは、より具体的な運用手順を例示します。すでにAzure AD Connectを導入し、パスワードハッシュ同期かパススルー認証を有効にしているという前提で進めます。

手順1: グループ・OU構成の見直し

1. パスワード有効期限を適用したいユーザーを特定
   経営企画や管理部門など、情報保護の観点で定期的なパスワード変更が必要なチームを洗い出します。
2. セキュリティグループまたはOUを作成
   「PWExpire180Days」というグループを作成するなど、名前規約を定めて管理しやすい形にします。
3. 属人化を避ける
   「○○さん専用のポリシー」といった属人的な設定は、将来的に管理が煩雑になる原因です。必ずグループ管理を徹底しましょう。

手順2: FGPPを設定

• PowerShellでの設定が推奨
  ADSI EditでGUI操作を行うより、PowerShellの方が構成の可視化やスクリプト化が容易です。
• 設定値の決定
  ・180日を「MaxPasswordAge」に指定
  ・パスワード変更の通知開始を14日前にしたい場合は、New-ADFineGrainedPasswordPolicyコマンドのオプションで対応
  ・ロックアウトポリシー（LockoutThreshold, LockoutDuration など）も同時に見直す

下記は設定例の表です。

項目	値	説明
ComplexityEnabled	$true	複雑性の要件を有効にするか
MinPasswordLength	8	パスワードの最小文字数
MaxPasswordAge	180.00:00:00	パスワードの有効期限 (180日)
MinPasswordAge	1.00:00:00	変更後すぐに再度変更できない期間 (1日)
LockoutThreshold	5	連続して何回失敗したらアカウントロックか
LockoutDuration	00:30:00	ロック解除までの時間 (30分)
PasswordHistoryCount	5	パスワード履歴をどこまで保持するか

手順3: 同期設定の確認

1. Azure AD Connectの稼働確認
   Azure AD Connectのバージョンや同期スケジュールが正常かどうかを確認します。
2. パスワードハッシュが同期されているか
   「ユーザーがクラウドに接続したときに、パスワード期限切れのポップアップが実際に出るか」を検証するため、テストユーザーで試行します。
3. 通知タイミングのテスト
   有効期限に近い日数（例：2日以内）になったタイミングで、Microsoft 365 (TeamsやOutlookなど) にパスワード変更通知が出るか確認します。

手順4: ユーザー教育とガイド

• パスワード変更の方法を明示
  「Windowsのログオン画面から行う場合」「Office.comにサインインした際のリダイレクト」「自動的に出るポップアップ」など、実際にユーザーがどのようにパスワードを変えればよいのかを分かりやすく説明しましょう。
• パスワードリセットポータルの利用
  Self-Service Password Reset (SSPR) を有効にしている場合、Microsoft Entra IDのセルフサービス機能から、ユーザー自身が簡単にリセットできるようになるため、サポート工数を削減できます。
• オンプレとの連携に注意
  ユーザーが外出先でパスワードを変更した際に、オンプレADとの同期が遅れてしまうとローカルのクライアント端末で認証エラーが出る可能性があります。VPN経由で接続させるなどの運用設計も必要です。

Microsoft Entra ID (Azure AD) Premiumでの追加オプション

Azure AD Premium（P1/P2）では、条件付きアクセスや自動化されたパスワードローテーションなどの高度な機能が利用できます。しかし、ハイブリッドユーザーのパスワード有効期限については、現時点ではオンプレミスAD側の設定が優先されます。以下のようなシナリオでは、Azure AD側の機能も有効活用できるかもしれません。

デバイスへのポリシー強制

Intuneと組み合わせることで、デバイスへのセキュリティポリシーも強制できるため、パスワードだけでなくWindows Hello for Businessや多要素認証(MFA)との併用を検討しましょう。パスワード期限が近づくと同時にMFAを求めるなど、セキュリティを高める運用も可能です。

ゼロトラスト戦略との統合

Azure AD Conditional Accessや自動リスク評価を組み合わせると、たとえばパスワードが期限切れ間際のユーザーには追加の本人確認を要求する、といった高度な制御もできます。パスワード有効期限だけを頼りにするのではなく、多要素認証やデバイスコンプライアンスも合わせて検討すると、より強固なセキュリティを実現できます。

トラブルシューティングのヒント

実際に運用を始めると、思わぬ不具合や挙動に悩まされることがあります。いくつかの代表的な対処方法を紹介します。

パスワード期限切れ通知が出ない場合

• AD側での残り日数の設定: 通常14日前から通知が出る設定ですが、New-ADFineGrainedPasswordPolicyでは指定していない可能性があります。
• 同期の遅延: Azure AD Connectの同期サイクル（30分〜2時間程度）が原因で通知が出るタイミングがずれることがあります。強制同期を試してみましょう。
• ADの既定ポリシーとの競合: ドメインレベルのパスワードポリシーよりもFGPPのPrecedenceが高いかどうか、再確認が必要です。

ユーザーがパスワード変更後も再度要求される

• Azure ADへの更新反映に時間がかかっている: PHSの場合、最短でも次回の同期まで待つ必要があります。
• ローカルキャッシュの問題: 特にVPN接続で社内ネットワークに繋がっていない端末だと、Windowsのローカルキャッシュされた資格情報が古いままで、パスワード変更が反映されるまでタイムラグが生じることがあります。
• グループポリシーの競合: ほかのセキュリティポリシーがユーザーのパスワード更新を強制している可能性があります。

今後の展望：パスワードレスとクラウド専用アカウント

オンプレミスADが履歴的に残っているだけであまり活用されていない環境であれば、クラウド専用アカウント（Azure AD Joinのみ）やパスワードレス認証の導入を検討するのも手です。FIDO2キーやWindows Hello for Businessを使うと、そもそもパスワード期限切れの概念自体を減らすことも可能になります。パスワードポリシー管理から解放される方向へ舵を切ると、管理負荷とセキュリティリスクの両方を下げられるメリットがあります。

パスワードレス認証のメリット

• ユーザー体験の向上: 何度もパスワードを打つ手間が省け、パスワードを忘れるリスクも軽減。
• セキュリティ強化: パスワードクラックやフィッシングによる漏洩リスクを大幅に下げられる。
• 管理工数の削減: パスワード期限切れに関する問い合わせ対応が減る。

段階的な移行手順例

1. ハイブリッド環境を維持しながら一部ユーザーでパイロット導入
2. ユーザー教育とフィードバックの収集
3. 段階的にオンプレADの利用を縮小
4. 最終的にはクラウド専用アカウントへ移行

このように、パスワード管理を取り巻く環境はクラウド中心の構成が進むにつれ変化しつつあります。

まとめ

ハイブリッド環境で特定ユーザーだけパスワード有効期限を設定するには、オンプレミス側のFGPP (Fine-Grained Password Policies) を活用するのが最も確実です。グループを用いて対象ユーザーを整理し、PowerShellで設定を行えば、180日ごとの期限や14日前からの期限切れ通知などを柔軟にカスタマイズできます。設定が正しく同期されれば、Microsoft 365の利用時にもパスワード変更通知がしっかりと表示されるようになります。

さらに、Azure AD Premiumの機能を組み合わせれば、多要素認証や条件付きアクセスを強化しつつ、ゼロトラストの理念に沿った運用が可能です。将来的にはパスワードレス認証へ移行することで、パスワード管理の手間とリスクを大幅に下げることも視野に入れられます。現状の運用要件と将来のセキュリティ戦略を見据え、適切なタイミングでパスワードポリシーを再設計してみてはいかがでしょうか。