RE: Tracking down a user in a large AD network

From: Jannie Hanekom <jannie.hanekom(at)opendev.net>
Date: Fri Jul 25 2003 - 11:45:53 EDT

I cannot offer an answer to the question, but I can offer a suggestion for limiting the future impact of such user errors.

Since a W2K Domain Controller needs to be taken down to perform directory recoveries, it is usually best to designate a server that is not absolutely required for operation (i.e. it's a backup) as a recovery server.

The System State of this server should be backed up to the required granularity timeframe. In our environment, we deemed 4 hours to be sufficiently granular, so a small DC was set up to backup to disk the System State using NT Backup every four hours.

Whenever a scenario arose that required granular restores of the AD (i.e. only certian OU's or objects), this server would be restarted in AD recovery mode, the recovery made, and the relevant objects marked as authoritative. Once the server was restarted, the objects it was authoritative for were replicated to all other domain controllers, and it received records updated since the last 4-hour checkpoint from the other Domain Controllers.

The above setup worked well for us since it was cheap and relatively easy to use. More information can be found at https://www.microsoft.com/technet/prodtechnol/ad/windows2000/support/adr ecov.asp. The following documents are also really good starting points: http://support.microsoft.com/support/kb/articles/Q216/2/43.ASP, http://support.microsoft.com/support/kb/articles/q241/5/94.asp.

Lets hope the backup vendors catch on and build automated granular AD backups and restores into their products...

Jan

-----Original Message-----

From: simonis [mailto:simonis@myself.com] Sent: 24 July 2003 22:23
To: focus-ms@securityfocus.com
Subject: Re: Tracking down a user in a large AD network  

All,
I have quite the dilemma on my hands. I work on a pretty large AD domain with nearly 100 domain controllers. We recently had an OU with about 5000 users deleted from the directory. I know the name of the userid responsible, but....it is a shared account. (I know, but with over 100,000 users, these things slip by)

What I need to do is track back to the workstation that was used for the login, and I haven't had much luck. I'm focusing on event 673, but I'm not sure this is the right angle. Any ideas??  

TIA,
-Ds

---

---

Your network firewall and IDS products do not prevent Web application attacks - the most common form of online exploitation- resulting in Web defacement, data theft, sabotage and fraud. KaVaDo is the only company that provides a complete suite of Web application security products.
Download a FREE whitepaper on "Security Policy Automation for Web Applications":http://www.securityfocus.com/Kavado-focus-ms

---

---

---

Your network firewall and IDS products do not prevent Web application attacks - the most common form of online exploitation- resulting in Web defacement, data theft, sabotage and fraud. KaVaDo is the only company that provides a complete suite of Web application security products.
Download a FREE whitepaper on "Security Policy Automation for Web Applications":http://www.securityfocus.com/Kavado-focus-ms

---

Received on Fri Jul 25 12:54:24 2003