アカウントのAD連携をしているが、POP3認証時にLSAプロセス（LSASS.exe）の使用率が高くなる？ new!

E-PostでユーザーアカウントのAD連携またはWindowsアカウント連携を行っている環境において、POP3認証時にLSAプロセス（LSASS.exe）のCPU使用率が高くなる場合の考え方と確認事項を説明します。

AD連携またはWindowsアカウント連携を使用している場合、POP3認証時にはWindowsの認証処理としてLSAプロセス（LSASS.exe）が使用されます。このため、POP3の認証要求が発生した時点でLSASS.exeのCPU使用率が一時的に上昇すること自体は考えられます。

ただし、POP3認証時にLSASS.exeの使用率が異常に高い状態となる場合は、アンチウイルスソフトの除外設定だけでなく、認証要求の頻度、メールサーバ上のWindowsユーザープロファイルの状態、ADとの通信状態なども併せて確認してください。原因はアンチウイルスソフトや除外設定だけとは限りません。

【アンチウイルスソフトの除外設定との関係】
アンチウイルスソフトの検索除外設定が行われていない場合、E-Postサービスによるファイルアクセスとアンチウイルスソフトによる監視が競合し、E-Post側の処理が異常に遅くなったり、サーバ負荷が高くなったりすることがあります。

特に、AD連携またはWindowsアカウント連携を行っている環境では、POP3認証処理がLSASS.exeを経由するため、E-Postサービス側の処理遅延やファイルアクセス競合が重なることで、LSASS.exeの使用率が高くなる可能性があります。過去にも、AD連携環境でアンチウイルスソフトの除外設定が不足していたことにより、同様の現象が発生した事例があります。

【確認する項目】
まず、POP3認証の発生状況とCPU負荷の関係を確認します。以下は原因を切り分けるための調査項目であり、メール利用に必要な設定を追加するものではありません。
  1. 認証頻度・同時接続数：単位時間あたりの認証要求数とCPU上昇が対応するか確認します。短い受信間隔や、複数端末・監視プログラムによる接続集中も確認します。
  2. 負荷の時間推移：同じ認証頻度でも負荷が増加するか、接続が落ち着いた後も高負荷が残るかを確認します。CPU使用率の採取方法と論理CPU数も記録します。
  3. 追加検証で差が見られたメールサーバ側の状態：下記「追加検証」で、メールサーバ上のローカルユーザープロファイルの有無によるCPU負荷の差を確認しました。このため、対象ADアカウントのプロファイル登録・ロード状態も、読み取りのみで確認します。クライアントPCの状態や事前ログオンを求める項目ではなく、未登録・未ロードだけで設定不備とは判断しません。
  4. 認証失敗・特定アカウントへの集中：古いパスワードによる再試行、不正な接続、共有アカウントへの集中がないか、POP3ログのユーザー名・送信元・頻度を確認します。
  5. ADとの通信状態：ドメインコントローラーの名前解決、通信、時刻同期、セキュアチャネルを確認し、Netlogonなどのイベントにエラーがないか調べます。
  6. アンチウイルスの介入：現在のE-Postのインストール先とメール作業用フォルダに除外設定が反映されているか、検査・遮断・隔離の記録がないか確認します。
  7. 認証とメールボックス処理の区別：POP3ログとWindowsの認証イベント（監査が有効な場合）を照合します。メール件数・容量・ディスク応答も確認し、メールボックス処理の遅延をLSASS.exeの高CPUと混同しないようにします。
  8. 発生前後の変更：Windows・E-Post・セキュリティソフトの更新や設定変更と、発生開始時期を確認します。変更前のログを保存し、比較時は認証頻度などの条件をそろえます。

【切り分けの考え方】
除外設定の再適用後に改善した場合：アンチウイルスソフトの監視がE-Postの処理に介入し、POP3認証時のLSASS.exe負荷を高めていた可能性があります。
POP3認証時だけ負荷が高い場合：AD連携またはWindowsアカウント連携による認証処理との関係を優先して確認します。
POP3認証がない時間帯にも負荷が高い場合：E-Post以外のWindows認証処理、ドメインコントローラーとの通信、セキュリティソフト、OS側のイベントなども含めて切り分けます。
除外設定を再適用しても改善しない場合：POP3接続数、認証失敗の連続、総当たり攻撃、AD応答遅延、ネットワーク遅延など、別の負荷要因を調査します。

【調査時に採取するとよい情報】

【追加検証：メールサーバ上のローカルユーザープロファイルとの関係】（2026年10月7日追記・10月8日補足）
弊社検証では、E-Postが動作するメールサーバ上で、対象ADアカウントのローカルユーザープロファイル作成前後を同じ認証頻度で比較しました。LSASS.exeの平均CPU使用率は、直接Windows認証で約21%から約8%、E-Post経由のPOP3認証で約24%から約12%へ低下し、再試験でも近い値を確認しています。

クライアントPCでADユーザーとしてWindowsへログオンしても、メールサーバ上に同じユーザーのローカルプロファイルが作成されるわけではありません。本検証は、クライアントPCのAD参加や事前のWindowsログオンを、メール利用の必須条件・推奨条件に追加するものではありません。AD未参加のクライアントを使用する構成を否定するものでもありません。

また、各ユーザーでメールサーバへ事前にWindowsログオンすることを推奨するものでもありません。プロファイルの登録とロードは別であり、メール認証に使用するLogonUserではプロファイルは自動的にはロードされません。今回の結果は調査の手掛かりであり、お客様環境の原因特定や改善保証ではありません。運用環境でのプロファイル一括作成・削除、ProfileListの変更、DPAPI関連ファイルの削除は行わず、対策は個別にご相談ください。

（参考：Microsoft公式資料）
●ローカル ユーザー プロファイル（LogonUserとプロファイルのロードについて）

なお、LSASS.exeはWindowsの認証に関係する重要なシステムプロセスです。LSASS.exeを停止、強制終了、除外対象として直接指定するのではなく、E-Postが使用するフォルダやファイルに対して、必要なアンチウイルス除外設定を行ってください。

（関連FAQ）
●アンチウイルスソフトをメールサーバマシンに入れる場合、除外設定を必須とする理由について