Outlook Exchange Server認証に関連するWindowsネットワークのロックアウトを調査する方法は？
私はエンドユーザーであり、ITプロフェッショナルではありません。残念ながら、私の企業リソースではこの問題を解決できません。私は彼らに与えるためのいくつかのアドバイスを探しています。
過去4か月間、1日に平均2〜3回、企業ネットワークでアカウントがロックされています。私は何日も問題なく過ごし、1日に7回ロックアウトされました。過去8年間で、私は2回ロックアウトされていました。
ロックアウトするたびに、アカウントのロックを解除するには、企業のヘルプデスクに電話する必要があります。ロックアウトが発生するのは、セキュリティシステムが、無効な資格情報（間違ったパスワード）で繰り返し認証しようとしていると「考えている」ためです。
これまでの非常に面倒なデバッグプロセスの詳細は、私のブログ投稿にあります： http://tech.kateva.org/2009/05/debugging-network-account-lockouts.html 。
約1週間前、Outlook 2007をハッキングして、ロックアウトが解消されました。コストは、OutlookクライアントがExchangeサーバーに接続する「日」ごとに初めて手動で認証（ドメイン/ユーザー名とパスワード）を行う必要があったことでした。迷惑ですが、私はそれと一緒に暮らすことができました。
このプロセスを開始してから、ラップトップが更新されました。手付かずの企業標準ディスクイメージを備えた新しいハードウェアがあり、Outlook 2003に戻りました。また、ロックアウトに戻りました。
だから私は問題が私のラップトップにあるとは思わない。
さらに調査したところ、Outlook 2003を送信して常に資格情報を要求すると、ロックアウトされていないことがわかりました。
だから私は認証プロセスがどのように異なるかを理解する必要があります
a。 OutlookはExchangeに接続し、ユーザーアカウントに関連付けられた資格情報（NTLMネットワークドメイン/ unおよびpw）を使用して自動的に認証します（標準の動作）。
b。 OutlookはExchangeに接続し、ネットワークunとpwを手動で入力する必要があります。
どういうわけか「b」は正しく機能します。ただし、プロセス「a」では、Exchange Server（Outlook？）が間違った資格情報をActive Directoryに送信しているため、ロックアウトされていると思います。
ActiveDirectoryアカウントやExchangeServerメールボックスの構成が間違っていると思われます。
ヘルプデスクとセキュリティデスクに、ActiveDirectoryまたはExchangeServerで調査できるものの適切なリストを提供する必要があります。これができない場合は、新しいコーポレートIDを取得し、既存のユーザーIDを放棄する必要があります。
私が彼らを正しい方向に向け、かなり正確なガイダンスを与えることができれば、彼らはこの問題を解決できると思います。
どんなアドバイスも役に立ちます。 NTLM（AD）認証がExchangeServer要求でどのように機能するかを調査する必要があるかもしれません。
過去に働いていた大規模な組織で、アカウントのロックアウトに問題がありました。
私が（IT組織のメンバーとして）行ったことは、PDC（現在はPDCエミュレーター））にあるスクリプトを作成することでした。ロックアウトされると、このドメインコントローラーはイベントID＃ 644 （Windows Server 2008では4740）をセキュリティログに登録します。このイベントには、不適切なパスワードで最後のログオンを試みたクライアントマシンの名前も含まれます。そのため、私のスクリプトは5分ごとにセキュリティログをポーリングし、このデータをヘルプデスクからアクセスできるWebページに投稿しました。
これができたら、ヘルプデスクのワークフローを変更して、アカウントのロックアウトの問題が発生するたびにそのページをチェックし、ユーザーがロックアウトの原因となったそのマシンの内容を見つけられるようにするのは簡単なことでした。ブログ記事に記載されているように、犯人は通常、ユーザーがプライマリマシンからパスワードを変更したときにログオンしたことを忘れた2番目のマシンです。通常、その2番目のマシンはOutlookを実行しているか、ユーザーの（現在は古くなっている）資格情報を介してドライブがマップされています。
そして、ヘルプデスクが落ち着きを取り戻したとき、彼らは積極的にこのWebページをチェックして、自分がそうだったことをまだ知らなかった人々の問題を解決することができました。アカウントロックアウトの犠牲者。
このスクリプトに興味があれば、掘り出し、ほこりを払い、ここに投稿することができます。
Exchangeに使用するユーザー名、パスワード、およびドメインは、コンピューターにログオンするときに使用する資格情報と同じであると想定しています。
企業SOEの再インストール後に問題が再発し、それが自分だけに発生する場合...移動プロファイル、または他の方法で設定をネットワークの場所にプッシュしますか？もしそうなら、それは問題がワークステーションのリフレッシュであなたに続いた理由を説明するでしょう。あなたのブログ投稿には、新しいSOEに「データを復元」したと書かれています。問題のあるアプリケーションを復元しなかったと確信していますか？
Outlook 2003に追加した可能性のあるプラグイン、および新しいSOEを受け取ってから追加したその他の非標準（IT部門がインストールするものではない）のカスタマイズをアンインストールします。
ほとんどの場合、これは、誰かがスケジュールされたタスクまたはロックされたリモートデスクトップセッションに古い資格情報を残したことが原因です。 WiresharkツールとSysinternalsツールを組み合わせて使用して、ロックアウトの原因となっているマシン上の問題のあるプロセスを特定することができます（マシンからのものであると想定）。
更新
マイクロソフトからのこのリンクは、問題についてあなたやあなたのITチームを助けるかもしれません。
[アカウントロックアウトのトラブルシューティング]（ http://technet.Microsoft.com/en-us/library/cc773155（WS.10）.aspx "Microsoft Technet"）
ITの観点からも、別の答えは、アカウントのロックアウトポリシーを再考することです。
10分以内に10回の不正なログイン試行が完全なロックアウトを引き起こすようにロックアウトポリシーが設定されているのを見るのは珍しいことではありません管理者がアカウントをリセットするまで。それだけでなく、このような低い制限により、単純なサービス拒否（DoS）攻撃に対して脆弱になります。BadGuy（TM）は10個の不正なパスワードを使用するだけでよく、アカウントをロックアウトしました。これが500のアカウントで起こっていると想像してみてください！私はそれを見ました：それは面白くないです。さらに悪いことに、すべての管理者アカウントに対して行われていると想像してください。
この制限は、セキュリティリスクの最小限の増加で大幅に緩和できるというのが私の主張です。
ブルートフォースパスワードハッキングは、パスワードがごくわずかでも複雑な場合でも、成功する可能性が十分にある前に、数千または数百万回の試行が必要です。では、5分間で50回のログオン試行を許可し、5分後に自動的にリセットするパスワードポリシーを検討してみませんか？このレート（5分ごとに50回の試行）では、ほとんどのブルートフォーススクリプトは単純に諦めますが、大雑把なDoS試行のほとんどは制限に達しません。 didが5分後にアカウントのロックを解除し、さらに50回試行できることを理解しているブルートフォーススクリプトは、1日あたり7200回の試行に制限されます。もちろん、制限を好きなようにいじることができます。
私は自分の質問に答えるつもりです。 Outlookパススルー認証を再度有効にした後も、1週間以上ロックアウトされていないので、明確な解決策がなかったとしても、どこに置いたのかを報告できます。
念のため、前回ロックアウトされたとき、新鮮な企業イメージを備えた新しいラップトップを受け取りました。
私がした最後の2つのことは次のとおりです。
- まったく新しい企業イメージには、2つのドライブマッピングが含まれていることがわかりました。はぁ。 （頭が壁にぶつかる音。）ずっと前に古いラップトップからそれらを取り外しましたが、それらは戻ってきました。もう一度削除しました。企業イメージの問題はそれだけではありません。
- Outlook 2003認証を「自動」（デフォルト）、Kerberosのみ（モダン）、NTLMのみ（レガシー）に切り替えて実験しました。 Kerberosに切り替えることで問題が解決したように見えましたが、それは赤ニシンだったと思います。デフォルトに戻しても、ロックアウトの問題は回復しませんでした。
- Retrospect Professional for Windowsを使用して、ワークステーションを外部ドライブにバックアップしています。 （企業のバックアップは悪くありませんが、復元には約1週間かかります。）そのソフトウェアには自動起動機能があります。資格情報を提供するという危険な機能ではなく、ログインした資格情報を使用して自動起動するように設定しました。マップされたドライブと自動起動の交差点についてはどうでしょうか。今のところ、RetrospectProの自動起動をオフにしました。
NeobyteがMicrosoftの改訂されたトラブルシューティングページに提供したリンクに感謝します。
http://technet.Microsoft.com/en-us/library/cc773155%28WS.10）.aspx
私はいくつかの精神的な傷を残されています。マイクロソフトの認証サービスとそのレガシーハッキングの山に関連する驚くほど多様な問題、および分散認証と認証ロックアウトなどの事後セキュリティ機能との交差点を考えると、私は今、新しいまたは新しい企業ネットワークの使用について非常に保守的ですまたは「クラウド」イニシアチブ。これらは、マイクロソフトが提供するものよりもはるかに堅牢なインフラストラクチャ上に構築する必要があり、実装するにはIT資金とIT再編成の両方が必要です。
私を悩ませていることの1つは、DCと、場合によってはKerberosの邪魔になるワークステーションでの時間同期の問題の可能性です。悪い時間はログインの失敗につながる可能性があり、ロックアウトにカウントされます。コマンド「w32tm」は、ワークステーションがDCサーバーまたはExchangeサーバーから（または相互に）時間をドリフトしているかどうかを診断するのに役立ちます。私が信じているそのコマンドをチェックするのに特別な特権は必要ありません。
デスクトップセッションにログインしたときに取得したトークンを再利用しようとするのではなく、手動のOutlookログインがまったく新しいログインセッションを開始しているのは私の推測です。何らかの理由で、これはデスクトップログインのように古くなっていません。
次に探すのは疑わしいイベントログエントリですが、それはすでに行われていると思います。残念ながら、「疑わしい」とはどのようなものか説明できません。 Exchangeへの通常のパススルーログインと失敗したログインを比較し、明らかでない場合は違いを調べ始めます。 ：}
少し前に、ユーザーのアカウントが繰り返しロックアウトされるという問題が発生しました。彼はIMAPクライアント（この場合はiPhone）を介してメールアカウントを設定しようとしたことが判明しました。パスワードポリシーでは30日ごとにパスワードを変更する必要があるため、パスワードを変更したものの、アカウントを保持しているiPhoneでパスワードを更新しなかった場合間違ったパスワードが使用されているためにロックアウトされています。
少なくともチェックする価値があります。