I agree with Idan.... Test test test test if you have to do it. As a general going in rule I am of the opinion "No agents" on DCs.
Then if someone wants it bad enough they will either A. Argue with me B. Take it to management A is the best if they have a good story. Generally, the story isn't good. B is good if you know you are wrong and think you can go high enough to get to someone I can't convince of the dangers to order me to do it. And then you still get to deal with me trumping bad ideas (not giving out proprietary secrets here...) because I would rather stop you than let you do something to hurt me if I feel you will and barring that, find a new company that understands basic security than put up with bad security. Note these are comments from operational perspective, not a consultant or vendor supporting someone else's environment. I have to say that or Deji is going to jump on me about how this that or the other customer won't let XYZ person from the outside make that decision, I concede that point, there are a lot of stupid people in companies that will pay folks a lot of money to come in and tell them what they are doing wrong and then completely ignore what they are told. This is strictly internal ops running their own stuff. Anything you load on a DC is a possible agent of evil.... a.k.a. attack vector. What specifically is the agent for and how does it work specifically. It is that last that most people can't answer because most people don't do a lot of integration testing and the vendors aren't willing to share details. AV is, IMO, a great thing not to run on a DC. Servers in general don't need it for the protection of the server in most cases unless you have less experienced (see I can be PC...) admins than you would like. The servers need it if you let people on them that don't know better or you store files on them that you allow people who don't know better to write to and read from. You can scan your DCs remotely once in a while if you are really fearful. I have seen some spectacular failures resulting from AV agents downloading versions of signature files or binary updates that blue screen out tens or hundreds of servers. Far more of those than DCs not running AV that have been infected with something. It is a bad day when 60%,70%,80% of the servers in your datacenter all crash within an hour time frame... So to go along with the idea that DCs should pretty much just be DCs and you should have highly skilled folks running them who don't web surf from them or run email on them or just plain run untrusted code, you shouldn't often need AV on DCs. The questionable items that come in are monitoring/management/inventory agents. Everyone has a reason they need to be on but in many companies, which is good in general, you have a single group for each of those items controlling the agents. As much as you may or may not like it, depending on the security context those agents want to run in (usually Domain Admin or LocalSystem) you have increased the number of Domain Admins / Enterprise Admins in your forest to include everyone who has any control of the agent(s). You have also opened up at least 2 new attack vectors per agent... The agent with its communication protocol and the "console" controlling the agents. Say you have 5 domain admins because you are trying to be good. You install all three of the agents above and since no one considers them all that dangerous you have teams of 10 people for handling each. Your DA count has gone from 3 to 33. It just doesn't directly seem that way. I once had someone ask me for some info on some DCs I managed, I said no, you don't need that info. That person went to the folks running the inventory agent software, those folks put together an ad hoc script and ran it on my DCs even though the first person had no authority to ask. The inventory folks made the decision that what was asked for wasn't dangerous... I shut off all of those agents the second I found out and put in a Domain Controllers policy to never run them again. The person who did it was chastised but you could see where he came from, he was asked for some simple info that normally wouldn't be such a big issue, but he didn't understand anything of our security. Basically everyone on his team was in a position to trump us, the domain admins, anytime they wanted. Most monitoring/management/inventory packages now a days allow ad hoc scripting and there is nothing the owners of the box can do to stop it. But then, the owners of the box don't really own the box now do they if they have installed someone else's software at a high security context, that is a basic security concept. MOM, SMS, you name it, if it is on a DC, it should be controlled by Domain Admins for the DCs. And delegating the control from those applications to DA's for just the DCs isn't good enough. You need completely separate installations and then you forward whatever info the others need and that is about it. Password filter agents in general scare me as well especially since they insert hooks into very sensitive bits of the system. As one of my good MSFT friends said, he hasn't yet seen a well written password filter. They may exist, I won't even say mine that I have written qualify. There is huge potential for issue with them as I have discussed on this list in the past, but if you feel you understand your risks and you don't have another answer, that is something you decide to do on your own. No one else can make that decision for you. Yes these may be near perfect world dreams, but even if I don't think I can attain it, I push for perfect world. When I do ops, things tend to run well and when they don't I tend to have a good idea of what could be wrong because I make sure there are few who can cause problems and I try hard to understand the weaknesses in the environments I run/support. Once you start opening up who can dork with your systems without your input you never know where you get bit from, you just get to react. A react based environment around DCs is not the proper way to handle them. But joe... How do you monitor? You can't monitor a system without putting agents on. Yes you can. Certainly some aspects are easier with agents but it doesn't mean it can't be done without them. Plus I have seen systems where the agents seem to think things are fine yet the services that the box serves aren't working for the people trying to use them. I am a strong proponent of outside monitoring or user service testing. When I run environments, I always have a couple of machines running monitoring that test the actual services themselves from outside of the box to make sure they are running and performing properly. BTW, this goes for Cert servers as well as any server doing high level security functions for more than itself. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, August 26, 2006 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Agents on Domain Controllers I think we're all circling around the idea that while it's not wrong by definition, it's certainly a sensitive part of the infrastructure, so "handle with care." A good approach is to ask yourself: "do I need this particular piece of software on a DC at all?" AV was raised as an example. If none of the infection vectors is present (shared filesystems, executing code that came from another box, running Office or Outlook, etc.), then perhaps you don't need an AV package on the DC at all? Conversely, the software might be doing something that is specific to the function of the DC (e.g., a password filter DLL to intercept password changes, and trigger PW policy enforcement or PW synchronization). In a case like that, placing the software on the DC is inevitable, so the response should be to 'test, test, test.' :-) -- Idan Shoham Chief Technology Officer M-Tech Information Technology, Inc. [EMAIL PROTECTED] http://mtechIT.com On Fri, 25 Aug 2006, Akomolafe, Deji wrote: > Depends on what the agent is supposed to be doing, whether or not it's been proven stable or crappy, and whether or not your administrative/security philosophy allows such agent to be deployed on DCs. > > AFAIK, there is no credible reason to mandate a blanket no-agent-on-DC security or operational posture. > > > Sincerely, > _____ > (, / | /) /) /) > /---| (/_ ______ ___// _ // _ > ) / |_/(__(_) // (_(_)(/_(_(_/(__(/_ > (_/ /) > (/ > Microsoft MVP - Directory Services > www.akomolafe.com - we know IT > -5.75, -3.23 > Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon > > > > From: [EMAIL PROTECTED] > Sent: Fri 8/25/2006 10:55 AM > To: ActiveDir@mail.activedir.org > Subject: [ActiveDir] Agents on Domain Controllers > > > Is it just me or does it seem like everyone wants to put an agent or 5 on > Domain Controllers these days. Anyone know of any agents to steer clear of > (besides all of them)? > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
