Exchangeのアカウントロックアウトを防ぐ方法 - TechRepublic

Active Directory のアカウントロックアウトを軽減・解決する方法の開発は、ここ最近私が取り組んでいる課題の一つです。最近、アカウントロックアウトとパスワードリセットを軽減する方法と、グループポリシーを使用してアカウントロックアウトをトラブルシューティングする方法について記事を書きました。どちらも、実際の出来事や日常業務から得たアイデアに基づいています。

悪い出来事は3回ほど起こることが多いようですが、結局、同じテーマに沿ったより複雑な問題に直面しました。この問題とその解決方法は、トラブルシューティングの複雑さと、健全かつ秩序ある方法で対処する方法を示しているため、解説する価値があります。

事の発端は、Active Directoryアカウントのパスワードを定期的に変更したことでした。1日ほどは何も問題ないように見えましたが、自宅からVPNにログインし、リモートデスクトップ経由で職場のPCに接続しようとしたところ、次のようなエラーが発生しました。

Microsoftは、何かがうまくいかない理由を必ずしも正確に説明してくれるわけではありません。今回の場合、パスワードは正しかったのですが、アカウントがロックされていました。幸いにも、以前にもこの問題に遭遇したことがあったので、パスワードをリセットする手間はかかりませんでした。なぜなら、それは本題とは程遠いからです。

この記事では、このような問題を解決する方法について詳しく説明しますが、まずは簡単に説明します。

簡単に言うと、Exchange サーバーへの認証試行が失敗したため、アカウントがロックアウトされていることがわかりました。
ExMon というツールを使用して、接続元となるネットワークアドレスを特定し、モバイルデバイス経由で社外から発信されていることを確認しました。
次に、Get-ActiveSyncDeviceStatistics という Exchange Powershell コマンドを実行して、自分のアカウントに関連付けられている ActiveSync デバイスを表示したところ、サーバールームに忘れられたタブレットが数か月前のパスワードを使用して自分のメールボックスに認証しようとしていることがわかりました。

さて、これが全容です。

最初のアカウントロックアウトの後、別のドメイン管理者アカウントでログインしてロックを解除しましたが、そこからアカウントが何度もロックされるのを阻止するための厄介な戦いが始まりました。15分ごとから1日に1回まで、散発的にロックアウトが発生するようになりました。内部システムと外部システムの両方からの接続が許可されているため、状況はさらに複雑になっています。

システム管理者として、私は多くのワークステーションやサーバーに同時にログインすることが多いので、以前のパスワードでどこかにログインしていると思っていました（しかし、ロックアウトは一定期間発生するはずなのに、なぜ散発的に発生するのか疑問に思いました）。もちろん、このような問題を解決するためにシステムを次々と再起動するなんて、モグラ叩きのようなやり方では解決できません。そこで、私の記事「グループポリシーによるアカウントロックアウトのトラブルシューティング方法」の手順に従い、認証失敗が発生したIPアドレスを特定しました。

この場合、IPアドレスは会社のExchangeサーバーのものでした。問題は解決しました。そこにログインしているはずだ、と思いましたが、それは間違いでした。

排除できるものは排除する

Active Directory アカウントが Exchange 経由でロックアウトされているなら、どこかのワークステーションで Outlook が動作していて、ログオン失敗が問題の原因になっているに違いない、と簡単に結論づけられます。しかし、私が困惑したのは、ワークステーションからの認証失敗が見つからなかったことです。ワークステーションは確かに Active Directory に対してユーザー認証を行っています。もし私の仮説が正しければ、複数の PC で 4771 エラーが見つかっていたはずです（だからこそ、利用可能な情報を評価し、無関係な考えやアイデアを可能な限り排除することが重要です）。

会社のPCでOutlookのパスワード入力画面が何度も表示され、新しいパスワードが受け入れられませんでした。そこで、Outlookプロファイル自体に問題があるのではないかと考えました。例えば、古いパスワードが何らかの形でキャッシュされているなどです。プロファイルを削除して再作成してみましたが、アカウントのロックアウトは解消されませんでした。特に、すぐにログインしなければならない緊急の事態や、携帯電話で仕事用メールが受信できない状況では、イライラさせられるだけでなく、問題も発生しました。どちらの場合も、別のアカウントでログインしてから自分のアカウントのロックを解除する必要がありました。

問題が緩和されるかどうか試すため、古いパスワードに戻すか、新しいアカウントを作成することも検討しました。しかし、元に戻すのは避けたかったので、実験としてアカウントを古いパスワードに設定してみました。しかし、ロックアウトはそのままでした。他の問題を引き起こしたくなかったので、パスワードを新しいものに戻しました。

賢明な判断を下し、PCのOutlookをシャットダウンし、ドメインコントローラーでアカウントロックアウトが発生していないか監視しました。それでもロックアウトが繰り返されたため、Outlookクライアントの問題ではないと判断しましたが、念のためPCをオフラインにしたところ、問題は解決しませんでした。システムとは全く関係がないことは分かっていたので、とりあえずオフラインのままにしました。

適切なツールを使用する

問題を解決するには、Exchangeサーバーに接続して私のアカウントにアクセスしているものが何なのかを突き止める必要があることが明らかになりました。Exchange Serverユーザー監視ツール（ExMon）は、メールボックスへのアクセスに関連する送信元IPアドレスを表示できるので便利です。このツールはMAPI接続（メールクライアントなどからの接続）のみを監視し、SMTP、POP、IMAPプロトコルは監視しませんが、これらのプロトコルが問題に関連しているとは考えませんでした。

ExMonには、Exchange 2000-2010用のExMonと、

Exchange 2013 および 2016 用の ExMon。Microsoft は、監査を使用して Office 365 アカウントに接続しているクライアントの IP アドレスを確認する方法を文書化しているため、クラウドベースの Exchange を使用している場合にもこの手法が役立つ可能性があります。

正しいバージョンをロードして起動しました。

このツールはクライアント接続を監視し、デフォルトでは1分ごとに更新しますが、「ファイル」→「今すぐ更新」をクリックするか、ツールバー（「ヘルプ」の下）の更新アイコンを使用することで手動で更新できます。対象のメールボックスがすぐに表示されない場合は、この操作が必要になる場合があります。Exchangeに接続しているクライアントが多い場合、統計情報は非常に急速に変化します。

いよいよ調査開始です。そして、答えはすぐに明らかになりました。私のメールボックス（smatteso）が、社内ファイアウォールの内部IPアドレスに対応するIPアドレスからアクセスされていることが分かりました。

つまり、接続は外部から行われていたのです!

問題を特定する

優れたセキュリティ対策としては、パスワードや証明書などを用いて、承認されたデバイスのみが社外から社内メールにアクセスできるようにし、不明なデバイスはITスタッフが正当性を確認しアクセスを承認するまで「隔離」しておくことが挙げられます。不明なデバイスがメールボックスにアクセスできるようになれば、どのデバイスがアクセスしたかを確認できます。

Exchangeには、様々な問題の原因を素早く特定するのに役立つ便利なPowerShellスクリプトが多数用意されています。これらのスクリプトの多くはGUI（Exchange管理コンソールなど）で利用可能な機能と重複していますが、コマンドラインはより強力で多用途であり、速度も優れています。

私の場合、「Get-ActiveSyncDeviceStatistics -Mailbox smatteso | ft DeviceType, DeviceUserAgent, LastSuccesSync」コマンドを実行して、Exchangeで使用される通信/同期プロトコルであるActiveSync経由でメールボックスに接続しているデバイスを確認しました。コメントを「ft」にパイプすることで、出力が適切にフォーマットされ、必要なカテゴリ（デバイスの種類、デバイスで実行されているエージェント、最後に同期した日時）のみが示されます。

すぐに答えが見つかりました (注: 下部のエントリの日付は、その重要性を強調するために意図的に拡大しました)。

大量の古いデバイス（以前使っていた携帯電話）の中に、Samsung SM-G935P（別名 Samsung Galaxy S7 Edge）と Samsung SM-T217S デバイスが私のメールボックスにアクセスしようとしていたことがわかりました。最初のものはほんの数分前、2 番目は昨年 3 月のものでした。

Edgeは見覚えがありました。私のスマホです。もう一つはSamsung Galaxy Tab。データセンターに置いてあったテスト用のタブレットだったので、思わず顔面を手で覆ってしまいました。

突然、すべてが完璧に腑に落ちました。以前、そのタブレットに仕事用のメールアカウントを設定して、そのままサーバールームに置いてきてしまったのですが、環境の変化やタブレットの設置場所のせいで、Wi-Fiの接続が不安定でした。タブレットは時折私のメールボックスに接続して認証を試みましたが、失敗し続けました。パスワードはずっと前に保存されていた古いものだったので、以前のものに戻しても効果がありませんでした。最後に、この問題は3月中旬にノートパソコンの電源が切れ、最近充電するために電源に接続した際にパスワード問題が発生して以来、発生していませんでした。

まとめると、発見された重要な手がかりは次の通りです。

Exchange サーバー経由でのみ発生するロックアウトは、ワークステーションの問題を示唆しています。
ワークステーションをオフラインにすると、上記の手がかりが確認されました。
散発的なロックアウトは、接続が信頼できない、または不安定であることを意味します。
古いパスワードが依然として拒否されている場合、資格情報が完全に間違っているか、古くなっていることを示しています。
手がかりを書き留め、それらのつながりに注目すると、問題解決にかかる時間を短縮できます。
他のチームメンバーと議論してブレインストーミングすることも有益です。

これは、エンドポイントデバイス、たとえ安全な場所に設置されているデバイスであっても、常に状況を把握し、追跡し続ける方法について、良い学習経験となりました。タブレットからメールアカウントを削除し、メールボックスに関連付けられていた古いデバイスをすべて削除しました。そして、今後このような事態が発生した場合に迅速に対応できるよう、このプロセス全体を社内で記録しました。次に同じことをしようとする探偵志願者のために、常に痕跡を残しておきましょう！

以下も参照: