This technique was demonstrated by Alain Lissoir at DEC, Spring 2003. The link to the code is included in our email exchange below:
-----Original Message----- From: Lissoir, Alain [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2003 10:20 AM To: Palenchar, Jeremy Subject: RE: Group membership monitoring in WMI from Spring DEC It is in the samples of my volume 2 book at http://www.LissWare.Net See "Sample 3.54 - GroupMonitor.wsf" The code I wrote in life during the presentation is attached. Hope this helps. /Alain -----Original Message----- From: Palenchar, Jeremy [mailto:[EMAIL PROTECTED] Sent: Thursday, 25 September, 2003 16:29 To: Lissoir, Alain Subject: Group membership monitoring in WMI from Spring DEC Alain, I am looking for the code for the group monitoring script you showed at the Spring DEC. I checked your web site but can't seem to find it. Can you please send me a link? Thanks! -Jeremy On Wed, 9 Mar 2005 15:49:30 -0800, Isenhour, Joseph <[EMAIL PROTECTED]> wrote: > It's not an alert that I configure. You can make an asynchronous WMI call > witch basically sends you replication events for any object. So you end up > with the replication meta data. You can see the previous value, the new > value, and the DC that made the change. I don't believe there is a way to > prevent AD from sending replication information without some serious hack. > ________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, March 09, 2005 3:23 PM > > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > > > > How is AD telling you something changed? Through the "you can add things > like logging and email alerts" method? > > > > If you "register" where? There is a lot an admin can do, including > configuring your alert to not fire or misfire. It is frightening when you > see privilege escalation in practice - at least I was frightened. Escalation > is made much easier by DA membership. I believe that AD was intentionally > designed to prevent a DA's access to resources in a given domain from being > limited in any meaningful way. > > > > BTW, I think there is a DEC "hackfest" next week, maybe we'll see some > things there. > > > > Deji > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph > Sent: Wednesday, March 09, 2005 12:21 PM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > > > How would you get around AD telling me that something changed? You can > modify a group; however, if I register to recieve changes for that object, > there's nothing an admin can do to prevent that is there? > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Wednesday, March 09, 2005 10:56 AM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > >>> Of course if the admins are smart enough they will simply modify your > script :) > > > > IF they are smart enough, they will NOT touch your script. They will write a > new one, or none at all. I am not really smart, but you can't lock me out of > your domain IF you make me a Domain Admin. And, I can do things you can't > track. > > > > Deji > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Isenhour, Joseph > Sent: Wednesday, March 09, 2005 10:21 AM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > > > If you want to lock down a group and add auditing you can take the > Restricted Group approach. Programatically control the members of your > admin groups. You can use just about any scripting language to do this and > if you go the script route you can add things like logging and email alerts. > > > > Of course if the admins are smart enough they will simply modify your script > :) So you'll have to come up with a way to lock down the script. This > solution does not get around the fact that the admin can still add someone > to the group; however, the membership will be short lived and you will be > notified if they do modify the group. > > > > -Joe Isenhour > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick > Sent: Wednesday, March 09, 2005 9:31 AM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > Who monitor's the admins? That's an organizational problem, not an > administrative one. Somewhere in the organizational hierarchy someone is > sufficiently trusted and endowed with enough responsibility to carry out > that task. Someone who is trusted as an EA perhaps? The CIO (I hope not)? > But there's going to be someone. > > > > CAAD uses various mechanisms for ensuring the security and integrety of its > audit data ("best practices"), but CAAD isn't a mechanism for protecting > against rogue admins. There's ultimately no way to do that. The best you can > do is mitigate the consequences. > > > > In my experience, trusting admins not to do something malicious isn't the > major issue. If you've given them admin priveleges, you've already convinced > yourself that they won't do something malicious (I hope!). Trusting admins > to not do something stupid is by far the more prevelant problem. And that's > where the trust but verify strategy can work well. > > > > -gil > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ruston, Neil > Sent: Wednesday, March 09, 2005 10:06 AM > To: '[email protected]' > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > > These are all valid points but when put into practice can be troublesome. > > > > > > Firstly, who monitors the admins? It certainly cannot be the admins > themselves, so then who should it be? If the buck stops somewhere outside > these admins, then where does it actually stop? Ideally, a forest (and each > domain) is assigned an owner, who would be that person. Deciding who that > should be is the tough part, however. > > > > > > Secondly, where are these admin events sent? If sent to a console that the > admins themselves manage, then again, we have a conflict of interest. So now > we need a separate, secure, isolated application which monitors the admins > and sends alters to this as yet undefined forest / domain Owner. How do we > implement this such that the Admins cannot alter the data in that app etc > etc? > > > > > > Change Auditor is a great facilitator which may be used to help monitor the > admins, but the 2 points above (and no doubt others) still need to be > understand, addressed and overcome. > > > > > > > > > neil > > > MVP - dir services > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick > Sent: 09 March 2005 16:55 > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > Rick's comments are spot-on. Trust is a gradient thing, not binary. You > trust people *up to a point*. Where that point is depends on you, your > admins, and your environment. Unfortunately, delegation of administrative > rights isn't a gradient thing... you get rights in great clumps. Once you > put the domain admins SID in a person's token, you've given him the keys to > the car, along with a credit card. > > > > I think a good approach is "trust but verify". Grant the admins the rights > they need, and audit and review their administrative actions in detail and > in real(ish) time. You can catch and repair most screw ups before they have > a significant impact on the enterprise, and over time you develop a better > (read: more accurate) level of trust in your admins. Good service > administration requires an up-front approval process and a reliable auditing > process. That's in fact why we built Change Auditor for AD :) > > > > -gil > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Wednesday, March 09, 2005 8:11 AM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > Hey Rick, I didn't say how it should be done below, specifically I didn't > say fire anyone. I just indicated he couldn't do what he wanted to do and > other things that he has to avoid if he wants to avoid that same issue. > Actually I agree with what you recommended in your previous post about > spinning up role specific groups and delegated permissions. > > > > The answer is really simple in all worlds, mine, the perfect one, and the > real one. Either you don't give people those rights or if you can't go that > route, you MUST realize and understand you can't lock it down. No amount of > doing anything will ever get you to the point where you can block a > determined and knowledgeable admin or someone who is in a position to grant > that to themselves. Period. > > > > One of the biggest security issues I see anywhere is the assumption that > things are safe due to people not understanding the basic mechanics of > Windows security. Because one person doesn't know how to compromise a system > or do something doesn't mean someone else doesn't, that goes for you, me, > Dean, or even your best MS Internal Security experts. You can never prove a > system safe, only unsafe. > > > > The straight up answer to any question of how do I block a DA from doing x > in the directory is always, YOU CAN'T. At that point you make the decision > of not granting the rights, granting the rights and putting a bunch of > procedures in place that make you think (or maybe you don't but the infosec > people do) it is safe to assuage yourself or a clueless information security > group[1], grant the rights and putting a bunch of auditing around it, > granting the rights and forcing yourself to trust the person who you have > given a gun. > > > > Once you understand you can't block DA's from doing anything they want, > EVER, you have to start to understand who can get DA. The easiest is > obviously anyone with admin rights on a DC. But anyone who can manipulate > services, drivers (even print drivers if the server executes them) or any > other system files, schedule AT jobs, can get local interactive logon (this > will depend on what vulns are currently available and not patched on the DC > or what files you can get placed where - lots of stupid admins you can take > advantage of), or anyone with physical access to the DC. > > > > The last thing we as a group should ever say to anyone is that you can make > an environment safe from Admins. We can't, others can't. People need to > understand that. Once people get over that thought, then they are better > prepared to come up with the solution that has the consessions necessary to > work. If a company doesn't have a very small group of people that it can > safely trust with its crown jewel of base security (auth and authorization > at least) then it has to concede that it has to give permissions to people > they can't trust and need the appropriate compensating measures dependent on > how much the company really cares whether or not the person does something > bad. > > > > joe > > > > > > [1] Being paranoid doesn't make you a good security person, though it is a > good start. Many security people I have met are more paranoid than > technical. Their technical knowledge is limited to understanding how to use > the the available security tools, not necessarily the concepts and the guts > behind them. > > > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan > Sent: Tuesday, March 08, 2005 11:10 PM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > joe - > > > > Great answer in a perfect world. Great answer in the joe-run world. I'd > like to do the same, but it's kind of funny that the guys I can't really > trust, the company still employs because I can't get evidence that is going > to get them fired to the degree in which HR is not going to spend the next > 30 years in a court room over false termination. If Rick Neuheisal can get > $4.7 Million for being fired as a coach because he violated NCAA rules, I'm > sure that the morons that I have to employ can make our life tough by being > stupid on our network. > > > > I can't move them off to other functions. Why? If I can't fire them, I > can't replace them. Management (upper) is kind of funny that way in the > world that I live in. The best that I can hope to do is to remove rights to > the point that if they piss themselves, it's just their own mess - no one > elses. > > > > I suspect Mr. Lunsford is much more like me. He's in an environment where > he has to employ people that aren't as good as we'd like them to be. Or, > maybe even as trustworthy as we'd like. So, that means that we: > > > protect ourselves as well as possible while we build the long trail of > documentation to shit-can them > figure out a way to mitigate the damage as much as possible - hence the > suggestions that I posted > > > > Usually, the advice that "You can't do that" isn't realistic. > > > > -rtk > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Tuesday, March 08, 2005 9:39 PM > To: [email protected] > Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators > > > > You can't. Period. > > > > Solution: Don't give these people who are untrustworthy administrator or any > native group access and don't let them log on interactively to your DCs or > allow them to modify the file systems nor registry nor services. > > > > Summary: You can't. Period. > > > > joe > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Tuesday, March 08, 2005 7:01 PM > To: [email protected] > Subject: [ActiveDir] Problem: Limit Domain Admins and Administrators > > > Problem: > Need to lockdown Domain Admins and Administrators so that they can not add > additional users the Domain Admins and Administrators group. > > Possible Solution: > Remove the permission's from the Domain Admins and Administrators so that > only Enterprise Admins can change their membership. > > Anyone got a better idea or know if the solution will not work ? > > Thank You ! And have a nice day ! > > ************************************************************** > Mark Lunsford > KAISER PERMANENTE > Directory Services Identify Management (DSIM/NOS) > Email: [EMAIL PROTECTED] > Outside Phone: 925-926-5898 > Tie Line Phone: 8-473-5898 > C ell: 925-200-0047 > Remedy Group: NOPS SCRTY DSIM NOS > ************************************************************** > > ============================================================================== > This message is for the sole use of the intended recipient. If you received > this message in error please delete it and notify us. If this message was > misdirected, CSFB does not waive any confidentiality or privilege. CSFB > retains and monitors electronic communications sent through its network. > Instructions transmitted over this system are not binding on CSFB until they > are confirmed by us. Message transmission is not guaranteed to be secure. > ============================================================================== List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
