Can you elaborate on what types of things SCW can break for a "custom web app" or a "multitier app" (as opposed to any other type of app?)
Obviously if you start removing extension mappings, or you disable NTLM, then certain pieces of IIS functionality no longer work. But that's reasonably obvious. What other types of gotchas as there? Cheers Ken > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Wayne S. Anderson > Sent: Saturday, 10 May 2008 8:24 AM > To: 'Devin Ganger'; 'Steve Friedl'; 'Christian Koerner' > Cc: [email protected] > Subject: RE: Binding Windows Services to Specific Addresses Only > > The only thing with using SCW in such a way is that if you are doing > multi-tier web applications, SCW can break things. Even more so if you > are > doing anything with non-default configurations. > > My list was looking more towards principles rather than focusing on the > technical accomplishment of those points. > > SCW is an excellent starting point for default services however I would > advise being careful applying it after a custom web application and > also > MAKE SURE you have a lab environment or developer test with the SCW > configuration after it is applied. Build in time in your project > schedule, > if applicable, for someone with appropriate experience to troubleshoot. > > -W > > Wayne S. Anderson > > -----Original Message----- > From: Devin Ganger [mailto:[EMAIL PROTECTED] > Sent: Friday, May 09, 2008 11:43 AM > To: [EMAIL PROTECTED]; 'Steve Friedl'; 'Christian Koerner' > Cc: [email protected] > Subject: RE: Binding Windows Services to Specific Addresses Only > > This is a great list, Wayne! > > However, I've got one addition for you. > > Wayne S. Anderson wrote: > > > 3) Immediately review the service configuration and default > > accounts. If you don't need them, disable them, or in the > > case of services at least set them to manual so they do not > > run by default. With Windows default accounts, make sure that > > the steps that you can take, you have. > > <snip> > > > With the services, take the most restrictive approach possible. > > Remember, if something doesn't start, we can always restart > > whatever was stopped so its ok if something now fails to start. > > We just make the necessary adjustments and restart it and we > > know not to stop that particular service again ;) You ARE > > building the security for this server while it is in a build > > or pre-production stage..... right? You should be able to risk > > causing other service failures while you determine what services > > are necessary. > > Don't forget that with Windows Server 2003 SP1 and later, the OS > includes a > great tool for automating a lot of this work for you -- the Security > Configuration Wizard. You'll need to go into Add/Remove Programs, > Add/Remove > Windows Components to ensure that it's installed on the system, but > once you > do -- it's a great tool that allows you to define and manage security > policy > for multiple systems.
