RE: [ActiveDir] ADUC MMC

[Joe]

Haven't ever done it but can visualize multiple ways to pull it off depending on how soon after the lockout you have to know about it.   If it is immediate I would write an LDAP API program (no other way currently) that does change notification on the specific user object, when it detects a change it looks at the pwdlastset attribute to see if it has been changed, if so, bam it goes off and does what you want. This should be run against the PDC as it should generally be the first to know an account is locked unless someone hits a DC that can't chat with the PDC and then you don't have much you can do around waiting for replication.   If you can wait for a while then you can poll the attribute on X frequency. Again, once the delta in the attribute is detected, it pulls the info you need.   Watching multiple accounts could get more involved depending on how many there were. Watching all accounts would have to be done carefully to make sure you aren't needlessly beating your DC.   Check out unlock from www.joeware.net on the free win32 tools page and you may be able to do what you want around it with perl. I haven't seen anything else faster for enumerating locked out accounts on a domain so you could do a unlock dc * and get all accounts currently locked out on that DC and then parse the output and do what you want, of you wanted to watch a specific OU you can set the baseDN for unlock to just look for those.   If someone needed to watch accounts only with a special attribute I have thought about adding that capability to unlock (i.e. allow you to specify part of the search filter). What this would allow is someone to set up some special indexed attribute in their AD or use a specifical indexed attribute and watch only those accounts for lockouts. If anyone thinks that would be useful, email my normal joeware email address (find it on the web site) and say you think that would be useful. I thought of it a while back but didn't have a use for it myself but can see where it would be useful.   For instance say you have a bunch of service ID's that for some reason can't be stuck in a special service OU and have to be spread across an entire domain OU structure, you could set up a special indexed attribute called something like IDType and set that value equal to SVC for service accounts. Then if I modified unlock, you could do a search like   unlock servername * /view /f IDType=SVC   and it would tack the IDType=SVC to the filter it uses to look for locked accounts so only those accounts would show.   The value there is say you have service ID's that if they get locked out from someone trying to hack or a worm or virus or screwed up program, you have apps that will stop working because of it so you need to know RIGHT NOW when those ID's lock.   To do it with the current version of the tool I would add all those special ID's to one single OU and then use the /b option to specify that OU as the start base for my search OR name the ID's in some pattern like SVC-whatever so you could set the name filter to be SVC-*. The perl script running it would run the unlock command on some frequency X.   The run output for unlock looks like this:   F:\Dev\cpp\Unlock>unlock joehome.com * /view   Unlock V02.00.00cpp Joe Richards ([EMAIL PROTECTED]) March 2003   Processed at w2kasdc1.joehome.com Default Naming Context: DC=joehome,DC=com   1: joe                            11/04/2003-19:27:51 LOCKED   VIEW_ONLY   F:\Dev\cpp\Unlock>     A quick perl script could be (and this is from the hip) and most of it is so you don't have to enter parameters to get it to go or telling you what is going on, the stripped version would be tiny.     __watch.pl__ $watchserver=shift; $sleeptime=shift; $watchid=shift; $watchou=shift; if ($watchou) {$watchou="/b \"$watchou\""}; if (!$watchserver) {$watchserver="."}; if (!$sleeptime) {$sleeptime="60"}; if (!$watchid) {$watchid="*"};   print "Watching Server: $watchserver\n"; print "Poll Period: $sleeptime\n"; print "ID Filter: $watchid\n"; print "Base OU: $watchou\n";   $istillcareaboutthisjob=1; while($istillcareaboutthisjob)  {   print "Querying...\n";   $cmd="unlock $watchserver $watchid $watchou /view";   @out=`$cmd 2>nul`;   if ($out[0]!~/No objects/)    {     print "We have locked out Accounts!!!\n";     map {print $_; DoSomething($_)} @out;    }   print "Sleeping...\n";   sleep($sleeptime);  }   sub DoSomething  {   my $item=shift;   chomp $item;   print "I am doing something to locked out item - [$item]\n";  }       Then if you ran it like   watch.pl   It would watch the default domain for any locked out ID's and send them through the DoSomething function each time it hit them with a 60 second poll.   If you did   watch.pl server3 2 SVC-*   would find all ID's that start with SVC- that are in the default domain partition of server3 and would poll every 2 seconds...   Here is a live example:   F:\Dev\cpp\Unlock>watch.pl . 1 Watching Server: . Poll Period: 1 ID Filter: * Base OU: Querying... Sleeping... Querying... Sleeping... Querying... We have locked out Accounts!!! 1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY I am doing something to locked out item - [1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY] Sleeping... Querying... We have locked out Accounts!!! 1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY I am doing something to locked out item - [1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY] Sleeping... Querying... We have locked out Accounts!!! 1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY I am doing something to locked out item - [1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY] Sleeping... Querying... We have locked out Accounts!!! 1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY I am doing something to locked out item - [1: joe                            11/04/2003-20:01:14 LOCKED   VIEW_ONLY] Sleeping... Querying... Terminating on signal SIGINT(2)   F:\Dev\cpp\Unlock>       Hope this helps.         joe   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Milburn Sent: Tuesday, November 04, 2003 9:15 AM To: [EMAIL PROTECTED]   Joe speaking of scripts to unlock users… have you (or anyone else) ever set up an alert/script combo that triggers when an account gets locked out, brings up the user info to you with various info, and lets you acknowledge and unlock it / call the user / chase the hacker depending on the situation?  At a glance this seems it might be useful, but maybe I haven’t thought through the implications… From: Joe [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2003 6:57 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] ADUC MMC   OK right off the bat, I wouldn't let anyone besides the domain admins TS into a domain controller. That isn't the root of your problem but could be the root of others before or down the road. You will probably get someone on here that may say that the server could be hardened but I am going to say there is going to be someone who will find a bug or some hole you aren't aware of be able to do damage.   Other than that if you have to use that DC in that way, I would recommend uninstall and then reinstall the adminpak from the SP that you currently have running on the machine.   Note that you can script the unlock and reset of user ID's....   set o=getobject(LDAP://cn=userid,cn=users,dc=domain,dc=com) o.lockouttime=0 o.setinfo o.setpassword "newpassword"   You simply have to know the DN or do a quick search for it or use name translate to get it, see posts from yesterday.   These scripts the users could run from their machines.   …<snip> -------APPLEBEE'S INTERNATIONAL, INC. CONFIDENTIALITY NOTICE------- PRIVILEGED / CONFIDENTIAL INFORMATION may be contained in this message or any attachments. This information is strictly confidential and may be subject to attorney-client privilege. This message is intended only for the use of the named addressee. If you are not the intended recipient of this message, unauthorized forwarding, printing, copying, distribution, or using such information is strictly prohibited and may be unlawful. If you have received this in error, you should kindly notify the sender by reply e-mail and immediately destroy this message. Unauthorized interception of this e-mail is a violation of federal criminal law. Applebee's International, Inc. reserves the right to monitor and review the content of all messages sent to and from this e-mail address. Messages sent to or from this e-mail address may be stored on the Applebee's International, Inc. e-mail system.