ドメイン管理者アカウントが見つかりました-災害復旧シナリオの場合を除いて使用しません-LastLogonTimeStamp属性に最近の日付があります。私の知る限り、関係する期間(および数か月後)には誰もこのアカウントを使用するべきではありませんでしたが、一部の馬鹿がスケジュールされたタスクを実行するように構成した可能性があります。
セキュリティログイベントの数が多いため(および分析用のSIEMツールがないため)、どのDCに実際のlastLogonアカウントの時間(つまりnotレプリケートされた属性)ではありませんが、ドメイン内のすべてのDCをクエリしましたが、それぞれのlastLogonは "管理者はなし」。
これはフォレスト内の子ドメインなので、誰かがこの子ドメインの管理者アカウントを使用して親ドメインで何かを実行した可能性があります。
LastLogonTimestampに記録された時間の前後の16のフォレストDCからの潜在的な2,000万のイベントを調べる以外に、どのDCがログオンを行っているかを判断する方法を誰かが考えられますか?最初に親ドメインDCをターゲットにできると思います(子DCが認証を行っていないように見えるため)。
説明
[以下のrepadmin
を使用した後、原因を特定した後に追加されます]
このリクエストの元々の理由は、ITセキュリティチームが原因で、なぜデフォルトのドメイン管理者アカウントで頻繁にログオンしているのかと疑問に思っていたためです。
WEがログオンしていないことはわかっていました。ローカルシステムとして実行されている呼び出しプロセスが特権の昇格を行っているときに、「Kerberos S4u2Self」と呼ばれるメカニズムがあることがわかりました。ドメインコントローラーで管理者としてnetworkログオン(対話型ではない)を実行します。非対話型であるため、DCのアカウントにはlastLogon
がないのはこのためです(このアカウントは現在のドメインコントローラーにログオンしたことはありません)。
この記事では、なぜログがpingされ、セキュリティチームに子猫がいるのかについて説明します(事態を悪化させるため、ソースマシンはServer 2003です)。そして、それを追跡する方法。 https://blogs.technet.Microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/
学んだ教訓-管理者のログオンに関する場合のみ、lastLogon
属性に関するレポートをITセキュリティチームに提供してください。
repadmin /showobjmeta DCNAME "ObjectDN"
元のDSAを表示します。
例:
repadmin /showobjmeta CONTOSOMDDC1 "CN=Administrator,CN=Users,DC=contoso,DC=com"
54 entries.
Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
4178442 CONTOSO-MDSite\CONTOSOMDDC1 4178442 2017-03-15 11:37:30 55 lastLogonTimestamp