Not to beat a dead horse, but I'm insanely and incurably curious. I think it's safe to say that the decisions and solution were decided before the technical stakeholders made the scene. That leaves Jason in a bad spot as he now has to a) be the bad guy and b) clean up other people's messes and c) do so without a budget. To be successful, somebody has to get their feelings hurt and it's likely a manager somewhere who shot first and aimed later if at all. As if that situation would ever happen, right? <G> But what I'm really curious about was your comment about the DMZ vs. the internet vs. the trusted network. I tend to agree with you Phil, however it's worth noting that there are MANY schools of thought when it comes to security strategy. One such theory holds that there is no need for a DMZ any longer. The reasons given range, but basically boil down to the part about it really only taking one network port to gain access to your entire network. As I understand a DMZ topology, the idea is to have a semi-trusted network that acts as a go-between for trusted and non-trusted communications where the non-trusted entity talks to the DMZ host (semi-trusted entity), who then relays that communication to the internal host and then reverses the conversation. To be effective, it usually doesn't do for the DMZ host to be able to have write access or unrestricted access to the internal network therefore a firewall is used to control the traffic as desired, historically based on traffic type and destination but recently based more on intent (layer-7). The reason folks don't think a DMZ is needed any longer is because the only thing standing between a successful attack and your night's rest is that DMZ host OS in many cases. If that host is compromised, you run the risk that somebody will now have access to internal resources. The practical difference between that DMZ host and allowing access to the internal network directly is that if somebody compromised your internal host, they'd typically have a lot fewer restrictions on where they could go on the wire vs. having a firewall that *could* be used to restrict access. Here's the thing: in order for the DMZ firewalls to be effective, something needs to trigger the lockdown. What would that be in this scenario? The final solution will likely use SSL or some other form of encryption for the transmission. At that point, your firewall is useless unless you are manually tipped off there's a problem or you have some sort of SSL bridging technology and some IDS plugged into the conversation that's properly tuned etc. If you don't (think ISA as your SSL bridging device in this case) then there's really about 5 minutes difference between the DMZ host scenario and the allowing untrusted traffic to the internal host scenario in the event of a compromise. This is the type of thinking behind the concept of protecting your resources regardless of location FWIW. For my money, it's all about risk vs. reward. You should not allow any host to have access to your valuables if you can't afford to lose them or if the reward is less than the cost of protecting that resource sufficiently regardless of network location [1]. Some crazy people think you should have an inventory of your resources and a stated security evaluation plan in place prior to architecting anything. Crazy people. Phil, what're your thoughts on the DMZ scenario given some of the other schools of thought? Do you agree, disagree, ? Any reasons? <I really do value your opinion Phil so please don't feel like I'm picking or trying to start an argument.> [1] Like I was saying above, this is where people come up with the idea that many attacks come from internal resources etc. Figuring out the risk/reward/value is a large part of the security process that is often overlooked in architecture discussions IMHO [2]. [2] I'm not a security expert, but I sometimes play one on the internet :)
________________________________ From: [EMAIL PROTECTED] on behalf of Phil Renouf Sent: Fri 9/9/2005 1:44 AM To: [email protected] Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate with AD & SQL... Al really gave you a good post about the pros and cons of each option, but I just wanted to emphasize something to be sure it comes across: It is not "just" a DMZ. A DMZ is a semi-trusted network and to me that means it is only slightly better than the internet itself. I do everything I can to mitigate any intrusions to DMZ boxes since they are internet facing and I can't trust the internet. Yes there is another firewall in front of the DMZ, but a good security admin knows that a firewall only protects you to a point. Also, the last option of having the server on the internal network and just providing access through the firewalls direct to it is a non-starter in my view. You have moved the perimeter of your network from the edge/DMZ into your internal network and that is not a risk I am willing to take. Much like joe's advice in another thread, I would explain the risks until I am blue in the face, then ask for a get out of jail free card for the inevitable intrusion. On another note; you mention loading the SP box as a DC in another forest. I would prefer to look at loading an ADAM instance to handle the external users instead of having a whole other AD infrastructure. ADAM is a lot easier to manage and is intended for situations exactly like what you're looking at. Phil On 9/8/05, Jason B <[EMAIL PROTECTED]> wrote: Al, Brian and others - thanks! I wasn't involved in the original plan for setting this extranet up, but overheard talk about it and didn't like the plans everyone else was making for my AD infrastructure. So I jumped into the fray after all the decisions had been made and hardware/software purchased, but better late than never. Originally, they wanted it set up with the SP server in the DMZ and ports opened to the LAN to "make it work" talking to SQL and AD. The plan had them putting extranet users and clients in our internal AD domain and giving non-technical employees the ability to add/remove clients from an OU. Bad mojo. I was able to convince them to allow me to set up the SP server as a DC in a new forest so as to avoid putting the extranet users in our AD domain. That was the "easy" part. Another SQL license is definitely not in the budget, so that was an easy decision. Now, I am going to try to convince them to move the SP server into the LAN side, close the ports from the DMZ to LAN and throw ISA server in the DMZ to serve up the extranet clients. I think I can get them to go for it with some doom and gloom scenarios. Again, thanks for the suggestions and advice. --Jason ----- Original Message ----- From: "Brian Desmond" <[EMAIL PROTECTED]> To: <[email protected] > Sent: Thursday, September 08, 2005 3:14 PM Subject: RE: [ActiveDir] Which ports to open in the DMZ to communicate with AD & SQL... >I am, perhaps unfortunately, quite familiar with Sharepoint. > > Your sharepoint server like any other member server can be a member of one > domain. If your extranet users are in a domain trusted by the server's > domain or another domain in the forest, you can just service them with > multiple portals. You can have up to I think its 50 portals per frontend. > Of > course, I don't really recommend having your extranet accounts in your > corp > forest... > > I used to have my sharepoint environment sitting in a "DMZ" subnet. It was > hell dealing with the spaghetti mess of ports on the checkpoints. Now we > have this special subnet that the WAN people call the AD Load Balanced > subnet. It's a class C that sits on the Cisco CSM and SSM modules in a > couple of 6509s. The subnet hangs off a PIX FWSM vlan interface, and they > have all the ports for domain joined machines open from that subnet to the > DCs. It's actually pretty easy. The Windows folks gave the WAN folks a > comprehensive list of ports that need to be open for AD, a/v, mgmt, etc, > and > they made PIX and Checkpoint rules for that subnet. Now when we need to > load > balance anything domain joined, the servers just go in this subnet, they > setup the CSMs, and then the firewall people just have to add additional > special rules (like connecting to SQL, for example). > > > Thanks, > Brian Desmond > [EMAIL PROTECTED] > > c - 312.731.3132 > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jason B > Sent: Thursday, September 08, 2005 4:37 PM > To: [email protected] > Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate > with > AD & SQL... > > This has been a GREAT discussion and I have received a lot of useful info. > I really appreciate the replies, suggestions, slams and help. I think I > am > going to revisit trying to have the sharepoint server moved to the LAN and > see if I can't convince the powers that be to apportion an ISA license and > hardware appropriate for running ISA to put on the DMZ. We already have a > sharepoint server on the LAN... I am not too familiar with sharepoint, > but > I wonder if the existing sharepoint server can handle both the internal > and > external users... That's a question for another group, I guess. > > Anyway, I gathered quite a bit from the posts and discussion, but what are > the main specific and concrete points that I am going to want to bring up > to > > dissuade them from having the sharepoint server on the DMZ? My expertiese > isn't in the hardware/networking aspect of configuration, but I know > enough > that I am not comfortable opening all the ports for AD auth from the DMZ > to > the LAN. Our network admin didn't think that it was a big deal to open > the > ports since it was "only on the DMZ" and he could control the traffic that > was allowed to the DMZ. > > > ----- Original Message ----- > From: "Al Mulnick" <[EMAIL PROTECTED]> > To: < [email protected] <mailto:[email protected]> > > Sent: Wednesday, September 07, 2005 5:04 PM > Subject: RE: [ActiveDir] Which ports to open in the DMZ to communicate > with > AD & SQL... > > > Looks like we have plenty of ideas and opinions ;) > > ISA is a great way to deal with this, but I believe the decision was made > to > > put the SP machine in the DMZ regardless of the technical merit or > viability. And whether or not it is a good idea. That said, ISA doesn't > offer much if you put it AND this machine in a semi-trusted network (for > whatever that means these days.) > > Shame there's no leeway though. The downside to using IPSec is that as > others have pointed out, it won't work on member server <->DC for W2K > servers (limitation of the OS) but will for 2K3 member servers but that > still leaves you with a secure channel from the DMZ host to your internal > network. That means you can't monitor the traffic from the DMZ to your > internal network because it's encrypted (sounds like a broken record, I > know.) > > Too bad you can't sway the decision makers to do this differently. But > hopefully you've received a lot of ideas to pick from. > > Best of luck, > Al > > > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Bernard, Aric > Sent: Wed 9/7/2005 7:40 PM > To: [email protected] > Subject: RE: [ActiveDir] Which ports to open in the DMZ to communicate > with > AD & SQL... > > > > I agree with Phil - I think using an ISA (or other reverse proxy solution) > is the best way to go given your constraints. > > > > Using a reverse proxy solution allows you the following: > > 1. Keep you Sharepoint server behind the firewall, yet make it accessible > to > > external clients as if it was in the DMZ. > 2. Restrict your [additional] holes through the firewall to only that > needed > > by the reverse proxy solution to interact with the Sharepoint server (port > 80). > > > > BTW - this scenario is becoming extremely common. The next common > addition > you will see to this will likely be the use of ADFS to provide an identity > trust bridge between the internal forest and a partner forest (or other > identity system). > > > > Regards, > > > > Aric Bernard > > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Phil Renouf > Sent: Wednesday, September 07, 2005 9:20 AM > To: [email protected] > Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate > with > AD & SQL... > > > > I would look at putting the Sharepoint server on the internal network and > deploy an ISA server in the DMZ and use Web Publishing or Server > Publishing > to get your external clients access to the site. If you want to open > access > from the DMZ to your AD Forest your firewall will be swiss cheese from all > the ports than need to be open. > > > > If you absolutely HAVE to then I would prefer to look at using IPSec for > communication between the Sharepoint box and your DC's. That leaves you > only > > needing the IPSec port open and not the very large number of ports to > support AD communication. > > > > http://support.microsoft.com/kb/q179442/ > > > Phil > > > On 9/7/05, Jason B < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: > > Because this will be a sharepoint server for clients. Regardless, that > decision has already been made and I don't have any input into it. > Any info on the ports I'd need open? > > ----- Original Message ----- > From: "ASB" <[EMAIL PROTECTED]> > To: < [email protected] <mailto:[email protected]> > > Sent: Wednesday, September 07, 2005 8:45 AM > Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate > with > AD & SQL... > > > Why did you decide to put it in the DMZ? > > -ASB > > On 9/7/05, Jason B <[EMAIL PROTECTED] > wrote: >> We are putting a MS sharepoint server in the DMZ and need to have it on >> the >> domain and communicating with a SQL server on the domain. Because of >> these >> needs, we only want to open the minimum number of ports to get >> functionality. We have LDAP (389) opened and SQL (1433) opened. What >> other >> ports will we need to open to be able to log in on the sharepoint server >> with a domain account? Currently, with only these two ports opened, a >> domain account can't log on to the sharepoint server in the DMZ. > 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/ > > > > 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/ > 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/
<<winmail.dat>>
