過去3日間の深夜、ログにイベントID 539を取得しました...自分のアカウントについて:
Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 539
Date: 2010-04-26
Time: 12:00:20 AM
User: NT AUTHORITY\SYSTEM
Computer: SERVERNAME
Description:
Logon Failure:
Reason: Account locked out
User Name: MyUser
Domain: MYDOMAIN
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: SERVERNAME
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: -
Source Port: -
常に深夜0分から30分以内です。それ以前のログイン試行はありません。その直後(同じ秒内)に、成功監査エントリがあります。
Logon attempt using explicit credentials:
Logged on user:
User Name: SERVERNAME$
Domain: MYDOMAIN
Logon ID: (0x0,0x3E7)
Logon GUID: -
User whose credentials were used:
Target User Name: MyUser
Target Domain: MYDOMAIN
Target Logon GUID: -
Target Server Name: servername.mydomain.lan
Target Server Info: servername.mydomain.lan
Caller Process ID: 2724
Source Network Address: -
Source Port: -
プロセスIDは3つすべてで同じだったので、調べてみました。現時点では、少なくともTCP/IPサービス(Microsoft)にマップされています。
金曜日にポリシーなどを変更したとは思いません。これをどのように解釈すればよいですか?
深夜に共有に接続するアカウントで実行されるスケジュールタスクがありますか?イベントID 552(2番目のイベント)は通常、ユーザー(この場合はシステム)がrunasを使用して別のアカウントとしてプロセスを実行したときに生成されます。
ただし、詳しく見ると、ログオンID:(0x0,0x3E7)-は、サービスが偽装を行っていることを示しています。マシン上のサービスを詳しく見てみましょう。別のマシンが自分の資格情報を使用してドライブをマッピングしていて、保存された資格情報の有効期限が切れている場合にも、これを取得できます。サービスがtcpipだったので、ここでニッケルを賭けています。
アカウントのロックアウトは、トラブルシューティングが難しい場合があります。私の最初の推奨事項は、Microsoftから アカウントロックアウトツール を入手することです。
これらのツールを使用すると、どのDCが実際にアカウントをロックアウトしているかを把握できます。そこから、セキュリティログをスヌーピングして、ロックアウトが発生しているサーバーを特定する必要があります。次に、そのサーバーの何がアカウントをロックしているかを特定できます。
資格情報の下で実行されているサービスのように、自動化されたイベントである可能性があります。サーバーにホップしてソートservices.msc
[ログオン]フィールドで、そこにいるかどうかを確認します。
ユーザーIDを使用してプログラムまたはサービスをインストールした可能性があります。ほとんどの場合、これらはバックアップソフトウェアまたは同様のサービス/タスクです。 「スケジュールされたタスク」からすべてのスケジュールされたタスクを見つけることができない、自動化されたサービス、IIS、Backup Execなどを確認する。