Tomotoe :)
I wonder about that statistic and how relevant it really is as anything more
than a scare tactic. I still go back to the macro and figure that you need to
understand the value of the resource and then methodically plan how you'll
protect it - regardless of the technology or
Well stated, Al.
To re-emphasize a general principle you appear to be making: If one is
not going to choose the most secure path possible, then at least try
to keep it simple. Adding complexity without increasing security (as
in options 2 or 3), is more of a drawback for those who have to
Good luck, Jason. :)
-ASB
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
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
ADAM... I hadn't thought of that. I
remember reading a bit about it a while ago. I suppose I will have to take
a look at it. I wasn't jazzed about having to maintain an additional AD
infrastructure simply for extranet users.
For the ISA server, will it handle a lot of the
load for the
I tend to doubt sharepoint will use that since it has to be a member server
of the forest the users are in. Theres no LDAP binding options
Thanks,
Brian
Desmond
[EMAIL PROTECTED]
c -
312.731.3132
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Jason
No problem Al :)
My take on DMZ's are that although some people now feel they are no longer needed (or never were) I don't agree. The folks who feel that way have a valid point, but when I sit down to look at it I think: where is my time best invested in making my environment more secure? Or, in
Last time I checked, you needed about 12-14 ports open to authenticate
against a domain.
It would make significantly more sense to put a proxy outside your firewall
and keep sharepoint inside.
Roger Seielstad
E-mail Geek
-Original Message-
From: [EMAIL PROTECTED]
Again to clarify,
the ISA server often (but not always) resides in the semi-trusted network while
the SharePoint server should always reside on a fully-trusted network.
Actually - you really should look at that differently. It should
read:
ISA
server should reside in the semi-trusted
I say tomato Is there really such a
thing as a trusted network? We should all probably be thinking no since
such a large number of malicious attacks come from within.
Regardless, the more layers you have in
place the harder it is err- should be to penetrate the internal
network.
I've done it as well under W2K. I'm not a fan for the same reasons that Aric
pointed out about riding the tunnel to the trusted network. To take it a step
further, if somebody overran your DMZ sharepoint host, you may as well hand
them the keys and the checkbook as well. They now own and have
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
Option #1
Procure and deploy ISA as an application publishing device. Note: investigate
the appliance versions - Way cool.
Pros: recommended method for publishing trusted network resources to
non-trusted or semi-trusted networks; only requires one easily monitored
network port to allow
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.
What kind of load are you looking at putting on this sharepoint server? A
Single server setup as you mentioned is not a very high powered setup...
What are you doing about the SQL? Sharepoint uses integrated auth for
connecting between servers.
Thanks,
Brian Desmond
[EMAIL PROTECTED]
c -
The SP server is a dual proc Xeon 3GHz w/4GB
RAM. That should be able to handle FAR more load than we -er, they
-plan to have on it.
For SQL, we'll have to create a trust for
now. While it would be better to have another SQL server in the new domain
and just replicate/silo the DB's between
That should suffice for a good while for hardware.
Thanks,
Brian
Desmond
[EMAIL PROTECTED]
c -
312.731.3132
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason B
Sent: Thursday, September 08, 2005
7:35 PM
To: ActiveDir@mail.activedir.org
Subject:
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
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: ActiveDir@mail.activedir.org
Sent: Wednesday, September
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
Disclaimer what you're doing is a horribly bad idea from a security
perspective /Disclaimer
You might have better luck setting up an IPSec tunnel from the DMZ host to the
internal domain controllers, DNS servers (if different) and the SQL machine.
You'd be even better off if you made it
I appreciate the replies... IPSec might be the way to go.
The problem with self-containing all the services is that the SQL server
that sharepoint needs to use is a DB that is also used internally - we need
to share this DB and some of the files with clients. I think a better
approach might
Agreed.
In any case, you'll want to add to that list of ports 3268 for Global
Catalog, your DCOM range, and if you have a CA deployed, 636 and 3269 for
SSL LDAP and GC.
Thanks,
Brian Desmond
[EMAIL PROTECTED]
c - 312.731.3132
-Original Message-
From: [EMAIL PROTECTED]
One other variation to consider, would be to replicate data from internal to
external. Depending on how much interaction you intend to have, you may also
want a two way model for data, but..
Last thought: you may want to give Microsoft a call about that. They have the
same software available
~
Regardless, that decision has already been made and I don't have any
input into it.
~
I think you should make an attempt to point out the precarious
location of this server, since security appears to be a concern.
You'll have more
If
you absolutely HAVE to then I would prefer to look at using IPSec for
communication between the Sharepoint box and your
DC's
IPSec would be good, but it isn't supported between member
servers and DCs.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q254949
Tony
From: [EMAIL
Did I miss something in that article? I don't see where it says client DC via IPSec is not supported; just that you can't encrypt Kerberos traffic.
Phil
On 9/7/05, Tony Murray [EMAIL PROTECTED] wrote:
If you absolutely HAVE to then I would prefer to look at using IPSec for communication
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:
Keep
you Sharepoint server behind the firewall, yet make it accessible to external
clients as if
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
Hi Phil
Here's the text I was referring to:
Currently, we do not support using IPSec to encrypt network traffic from
a domain member server to a domain controller when you apply the IPSec policies
by using Group Policy or when you use the Kerberos authentication method.
The goal with
I should make sure I was clear in no
way did I encourage the placement of ISA AND the SharePoint server onto the
semi-trusted (DMZ) network. Again to clarify, the ISA server often (but not
always) resides in the semi-trusted network while the SharePoint server should
always reside on a
That was the way that I understood that paragraph as well.
And to give a little more information about Aric's point on not being able to monitor the traffic between the DMZ host and the DC's; that is why it is important to have an Intrusion Detection/Intrusion Prevention system in place. Even in
Using certificates to allow IPSec
betweenclients/member servers and DCs sounds good. Has anyone
actually done this? I'd be interested, as I'm surprised the KB article
didn't mention this as an alternative. I've also heard (more than once)
some statements from MS people to the effect that
Yes, in fact I have implemented this
(under Windows 2000).
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
Sent: Wednesday, September 07,
2005 7:44 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Which
ports to open in the DMZ to
34 matches
Mail list logo
