Nope, not I. I was the one that stood up and started clapping a couple of years ago when Stuart announced that Longhorn would have Server Core (at the time Server Foundation) DCs as an available sku with no GUI. I would like to see more services be able to run on that core, it makes no sense to me that ASP.NET servers and other items can't run on it because they offer enhanced user experiences; sounds like a lack in the capability versus a feature. Why should the ability to run a GUI locally impact what a user sees remotely in a web browser, it isn't like the web browser is shadowing the console.
Anyways, I don't use applications on servers that are well known for being attack vectors. Email/Web Browsers/etc... Honestly, DCs are your auth point, why are you doing much interactive work on them at all? I mean sure, say you are in the datacenter and you want a little chicken and broccoli with brown sauce or a bit of tandoori chicken or some vindaloo dish, no one is going to fault you for pulling up a browser and ordering from Wok To Yu or Shingara Goochi Kitchen but other than that, are there any good reasons to be using those applications directly on a DC? Personally I like to wrap the updates into scripts that can be fired through rcmd or psexec, etc. I slowly fire them off to dog food and then ramp up as the need arises and can easily do from 1 to 400 with little change in effort and with full control and no concern that something went off and did something I didn't expect. Wrapping updates into scripts usually doesn't take much work to do once you have a framework in place and it sort of assists you in looking closer at what is there when it gets released versus clicking a button and saying, yeah shoot that out there everywhere. I am very particular about updates on DCs though, I have massive trust issues in that realm. 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 Al Lilianstrom Sent: Tuesday, March 07, 2006 8:18 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] How Secure is a Domain Controller? Myrick, Todd (NIH/CC/DNA) [E] wrote: > Okay for you Susan, I will modify my statement... Add IPsec filter that only allows http traffic to update.microsoft.com. Also, in the future MS will probably bake in the spyware service into the product, so it will be there anyway. I think I helped flush out the KB article on AV way back. > Do folks really use Windows/Microsoft Update for patching DCs? I realize I'm a bit paranoid but you're still running a web browser on a DC. al > ________________________________ > > From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] > [mailto:[EMAIL PROTECTED] > Sent: Mon 3/6/2006 2:27 PM > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] How Secure is a Domain Controller? > > > > Question? > > On a DC ...why do you need anti spyware? > > If spyware enters via web browsing and email...and IE should never be > used/launched on a DC... why do you need it? If the enhanced IE > lockdown is still in place that shuts off scripting and what not..... > > Is it on my TS box and all workstations? Yup. On my DC. No. the only > site that that box surfs to is Microsoft Update (I mean I don't even > go to Joewear on that DC) > > Why introduce another "thing" that might introduce new code and new > false positives? > > (see Spybot that flagged Microsoft's remote desktop control for RWW as > spyware, see Microsoft's Antispyware that flagged Symantec as a > trojan) > > And if you do a/v ensure that the needed folders and files are > excluded (see prior posts in this forum about the KB articles > regarding how to set up a/v on a domain controller and Exchange > servers) > > Myrick, Todd (NIH/CC/DNA) [E] wrote: > >> To add my 2 cents. >> >> 1. Add Anti-virus and Anti-Spywear detection. >> 2. Configure and backup your event logs. At remote sites, I would >> recommend collecting the event logs on a faster rotation. >> 3. Add monitoring, You want to monitor account lockout events and >> have notification when excessive amounts of authentications are >> occurring. (Tips you off to possible brute force attacks, and >> up/down situations). >> 4. Use IPSEC Policies to not allow outside traffic to your DC's. (I >> haven't tried this, but the theory seems pretty solid) >> 5. Use GPO's to enforce group memberships for EA and Domain Admins. >> 6. When possible do not have child domains, allows you to use >> tighter security policies. >> 7. Enforce all registry changes using GPO's. Things like DNS record >> weight, fixed ports for NTDS and FRS replication, etc should be >> set this way to avoid mis-configuration. >> 8. At a minimum have a MFT backup of the AD system state done at a >> central site each night. If you should lose objects, etc. Having >> this will give you options for restore. Not having it you're doomed. >> 9. Make sure your account policies balance the need to thwart an >> attack but also consider the potential for brute force and >> denial of service. You don't want to come in on Monday to 40K of >> accounts locked out, and everyone waiting for you to unlock them. >> 10. TBD >> >> Todd Myrick >> >> --------------------------------------------------------------------- >> --- >> >> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> *Sent:* Monday, March 06, 2006 11:23 AM >> *To:* ActiveDir@mail.activedir.org >> *Subject:* RE: [ActiveDir] How Secure is a Domain Controller? >> >> >> I understand/stood what you were saying, just was hoping to bring out >> a clearer answer for some of the lurker/newbies on the list (of which >> there are many). And you provided exactly that clarification which >> was excellent. Thank you. >> **[Neil Ruston] You're welcome :)** >> >> I still personally believe in the statement that if I can touch your >> server, I own your server. There just is no good technical solution >> to a physical problem, and it's part of our job responsibility to >> make that clear to management. >> **[Neil Ruston] Sometimes we're forced to make compromises due to >> management and political pressure. Ulf has written an article which >> helps to secure the DC if it finds itself physically insecure. >> Ideally, the DC would not be deployed at all, but the world [of IT] >> is far from ideal... :)** >> >> --------------------------------------------------------------------- >> --- >> >> *From:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *On Behalf Of >> [EMAIL PROTECTED] >> *Sent:* Monday, March 06, 2006 9:52 AM >> *To:* ActiveDir@mail.activedir.org >> *Subject:* RE: [ActiveDir] How Secure is a Domain Controller? >> >> You mis-understand :) >> >> Ulf was suggesting that in order to protect the AD data on a poorly >> protected DC, that strong passwords should be used that are harder to >> crack. >> >> In the event that the disks were compromised, the hacker would not be >> able to crack a 20 char pw. He does not suggest the use of 20 char >> passwords to logon to the DC but instead, it is suggested as a way to >> further protect the AD data, in the event that physical protection is >> weak. >> >> hth, >> >> neil >> >> --------------------------------------------------------------------- >> --- >> >> *From:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *On Behalf Of *Tim Vander >> Kooi >> *Sent:* 06 March 2006 15:44 >> *To:* ActiveDir@mail.activedir.org >> *Subject:* RE: [ActiveDir] How Secure is a Domain Controller? >> >> Based on the subject of this discussion: if you have those regular >> users, who can't comprehend or remember a password over 7 characters, >> signing on to your domain controllers I would say that your domain >> controllers are VERY not secure. Secondly, if your domain >> administrators are so lazy as to be using 7 character passwords you >> are still very insecure. >> >> --------------------------------------------------------------------- >> --- >> >> *From:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *On Behalf Of >> [EMAIL PROTECTED] >> *Sent:* Monday, March 06, 2006 2:25 AM >> *To:* ActiveDir@mail.activedir.org >> *Subject:* RE: [ActiveDir] How Secure is a Domain Controller? >> >> The use of >20 char passwords caught my eye. >> >> In previous discussions with MS et al, it was suggested that the >> majority of users would simply repeat a (at most ( 7 char password n >> times, so as to meet the 20+ char pw policy requirement. >> >> As a result, I have heard it suggested that in reality (not theory) a >> pw policy of more than 7 chars is actually counter productive. [Any >> pw policy with a multiple of 7 chars being most counter productive.] >> >> Food for thought, >> >> neil >> >> --------------------------------------------------------------------- >> --- >> >> *From:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *On Behalf Of *Ulf B. >> Simon-Weidner >> *Sent:* 05 March 2006 08:35 >> *To:* ActiveDir@mail.activedir.org >> *Subject:* RE: [ActiveDir] How Secure is a Domain Controller? >> >> I've written down some related thoughts once: >> >> http://msmvps.com/blogs/ulfbsimonweidner/archive/2004/10/24/16568.asp >> x >> >> Gruesse - Sincerely, >> >> Ulf B. Simon-Weidner >> >> MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz >> Weblog: http://msmvps.org/UlfBSimonWeidner >> Website: http://www.windowsserverfaq.org >> <http://www.windowsserverfaq.org/> >> Profile: >> http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1 >> 214C811D >> >> >> >> --------------------------------------------------------------------- >> --- >> >> *From:* [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] *On Behalf Of *Edwin >> *Sent:* Sunday, March 05, 2006 4:17 AM >> *To:* ActiveDir@mail.activedir.org >> *Subject:* [ActiveDir] How Secure is a Domain Controller? >> >> How Secure is a Domain Controller that is fully patched on a >> default install of Windows 2003? When promoted the domain >> controller has the two default policies, both of which are >> recommended not to be modified. But there are things that could be >> done better for added security. For example, NTLMv2 refuse NTLM >> and LM. Is it common practice to add additional GPO's to the DC >> OU? Or is DC protected enough to where all that is needed to worry >> about are the member machines? >> >> If adding additional GPO's to the DC OU, is there anything that >> should definitely be avoided? >> >> Edwin >> >> PLEASE READ: The information contained in this email is confidential >> and >> >> intended for the named recipient(s) only. If you are not an intended >> >> recipient of this email please notify the sender immediately and >> delete your >> >> copy from your system. You must not copy, distribute or take any >> further >> >> action in reliance on it. Email is not a secure method of >> communication and >> >> Nomura International plc ('NIplc') will not, to the extent permitted >> by law, >> >> accept responsibility or liability for (a) the accuracy or >> completeness of, >> >> or (b) the presence of any virus, worm or similar malicious or >> disabling >> >> code in, this message or any attachment(s) to it. If verification of >> this >> >> email is sought then please request a hard copy. Unless otherwise >> stated >> >> this email: (1) is not, and should not be treated or relied upon as, >> >> investment research; (2) contains views or opinions that are solely >> those of >> >> the author and do not necessarily represent those of NIplc; (3) is >> intended >> >> for informational purposes only and is not a recommendation, >> solicitation or >> >> offer to buy or sell securities or related financial instruments. >> NIplc >> >> does not provide investment services to private customers. Authorised >> and >> >> regulated by the Financial Services Authority. Registered in England >> >> no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St >> Martin's-le-Grand, >> >> London, EC1A 4NP. A member of the Nomura group of companies. >> >> PLEASE READ: The information contained in this email is confidential >> and >> >> intended for the named recipient(s) only. If you are not an intended >> >> recipient of this email please notify the sender immediately and >> delete your >> >> copy from your system. You must not copy, distribute or take any >> further >> >> action in reliance on it. Email is not a secure method of >> communication and >> >> Nomura International plc ('NIplc') will not, to the extent permitted >> by law, >> >> accept responsibility or liability for (a) the accuracy or >> completeness of, >> >> or (b) the presence of any virus, worm or similar malicious or >> disabling >> >> code in, this message or any attachment(s) to it. If verification of >> this >> >> email is sought then please request a hard copy. Unless otherwise >> stated >> >> this email: (1) is not, and should not be treated or relied upon as, >> >> investment research; (2) contains views or opinions that are solely >> those of >> >> the author and do not necessarily represent those of NIplc; (3) is >> intended >> >> for informational purposes only and is not a recommendation, >> solicitation or >> >> offer to buy or sell securities or related financial instruments. >> NIplc >> >> does not provide investment services to private customers. Authorised >> and >> >> regulated by the Financial Services Authority. Registered in England >> >> no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St >> Martin's-le-Grand, >> >> London, EC1A 4NP. A member of the Nomura group of companies. >> >> PLEASE READ: The information contained in this email is confidential >> and >> >> intended for the named recipient(s) only. If you are not an intended >> >> recipient of this email please notify the sender immediately and >> delete your >> >> copy from your system. You must not copy, distribute or take any >> further >> >> action in reliance on it. Email is not a secure method of >> communication and >> >> Nomura International plc ('NIplc') will not, to the extent permitted >> by law, >> >> accept responsibility or liability for (a) the accuracy or >> completeness of, >> >> or (b) the presence of any virus, worm or similar malicious or >> disabling >> >> code in, this message or any attachment(s) to it. If verification of >> this >> >> email is sought then please request a hard copy. Unless otherwise >> stated >> >> this email: (1) is not, and should not be treated or relied upon as, >> >> investment research; (2) contains views or opinions that are solely >> those of >> >> the author and do not necessarily represent those of NIplc; (3) is >> intended >> >> for informational purposes only and is not a recommendation, >> solicitation or >> >> offer to buy or sell securities or related financial instruments. >> NIplc >> >> does not provide investment services to private customers. Authorised >> and >> >> regulated by the Financial Services Authority. Registered in England >> >> no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St >> Martin's-le-Grand, >> >> London, EC1A 4NP. A member of the Nomura group of companies. >> > > -- > Letting your vendors set your risk analysis these days? > http://www.threatcode.com > > 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/ > > > 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/ -- Al Lilianstrom CD/CSS/CSI [EMAIL PROTECTED] 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/ 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/
