Re: Access denied on network share in an other domain



Hi Anthony,

My clients will transfer live on the DMZ. I've talk to the programmers of
the portal and they agreed to modified their codes to have a storage zone in
the DMZ. That zone will be a temporary zone and another zone will be
dedicated to applications files. My programmers will access them through FTP.
As for the client files, a mecanish will be put in place to transfert the
files back in the Internal network by either FTP or HTTPS. No port will be
open on the DMZ through my internal network, only FTP and / or HTTPS for the
internal to the DMZ. I guess I'll have a pretty tight DMZ from there.

Thanks for the advice,

Fred

Your advice
"Anthony [MVP]" wrote:

Fred,
I understand the bit about using an https portal for clients to upload files
to you.
I'm not sure I fully understand the rest.
Are the clients transferring files straight into the live service on the
DMZ; or are they transferring them to you to do something with?
Either way, I don't see any reason for your internal network to trust the
DMZ
Anthony
http://www.airdesk.com

"r14edge" <r14edge@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:BDC390A7-89AA-49D9-9938-4BF9D70C390C@xxxxxxxxxxxxxxxx
Hello Anthony,

My clients will use a portal programmed in html, to drop documents for us.
A
HTTPS connection will be use to transfered the documents. We decided to
build
that portal because past experience with FTP and sFTP has proven to us to
be
painful. Our clients are not too tech savvy and the use of any FTP clients
fall ultimately on our desk. So, it was decided to simplified the process.
Clients will log on a portal where they will be able to get or to drop
documents.

That being said, and with the previous input you gave me, a file storage
will be needed in the DMZ. That storage area will store web applications
and
will store files for / from clients. It seems the only way to ensure a
more
secure DMZ. Applications files will be transfered when needed and clients
files will be process through some sort of mecanism where files dropped by
the client will be retransfered in the internal network and files coming
from
the internal network should have a expiration date on it.

Is this a good plan?

thnaks


"Anthony [MVP]" wrote:

Fred,
That's a good question about data in the DMZ. But if you figure your DMZ
is
compromised so they have access to the data, then how secure would the
data
be on the LAN that you have given the DMZ access to?
A lot of this is theoretical. If you follow good practice then the data
on
the DMZ should be reasonably safe. People put databases on the DMZ. They
just don't allow access into the LAN.
The thing about Radius and LDAP authentication is that they have a simple
yes/no authentication protocol so they don't require extensive access to
the
LAN. RPC (the normal windows mechanism) is LAN based and assumes open
access.
Can you explain what you mean by "our client will use to transfer files
by
HTTPS". I suspect there is an easier answer in there somewhere,
Anthony,
http:/www.airdesk.co.uk



"r14edge" <r14edge@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1FD7D541-D041-43B8-862C-97AC492FD3F9@xxxxxxxxxxxxxxxx
The main reason why I wish to use a share on my internal network is
coming
from what my programmers wish to do. They are building a website that
our
client will use to transfer files by HTTPS. I figure that since a DMZ
is a
insecure place, no data should reside in it. I'm puzzled. How will I
store
those files without having them in the DMZ?

I'm starting to look at the possibility to use RADIUS. I saw one of
your
(I'm assuming since a Anthony from airdesk.co.uk at the time)
previously
answer about the matter. So far, I understand that I will need a RADIUS
server in my internal domain and a RADIUS proxy in my DMZ. But I'm
still
skeptical about this because I see another flaw in my DMZ.

What a headache ...

Thank you for your answer,

"Anthony [MVP]" wrote:

r14,
I don't think that's really what you would want to do.

Leaving aside the idea of the Trust for a moment, the idea is that
hosts
in
the DMZ (which could be compromised) should have no or limited access
to
the
LAN. Limited access would means specified ports to specified hosts.
For
example LDAP or Radius or SecurID.

For the DMZ to get be able to a Share on the internal network is
probably
not desirable.

It sounds as though what you would do is to copy out your data from
the
internal network to the DMZ. This requires no inbound traffic to be
allowed.
You could use FTP or Robocopy to do this. The copy needs to use
credentials
that the DMZ recognises, e.g a local account on the DMZ server, or
else
you
can use a one way trust where DMZ servers trust internal server.
Hope that helps,
Anthony
http://www.airdesk.com




"r14edge" <r14edge@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E7D9C5ED-97A9-4323-A9F5-0073BDF124F7@xxxxxxxxxxxxxxxx
thanks for the reply Anthony. As for now, I'm able to log in my
internal
domain using dmz domain credential. This prove me that my trust
work,
but
for
some reason, my web servers in my DMZ are unable to get on a share
in
my
internal network. I'm starting to believe I got this concept of
trust
all
wrong. Furthermore, how can the concept of pass-through
authentification
worked without a trust between two domains?

What I'm trying to achieve with my DMZ is to be able to have web in
a
DMZ
using a single storage area located in a internal network. Is there
other
way
to do this?

thanks


"Anthony [MVP]" wrote:

Fred,
If the DMZ domain trusts the internal domain you can Push files out
to
it.
If the internal domain trusts the DMZ domain (not what you want),
the
dmz
can Pull files out from it.
Ideally you would want the DMZ to have no inbound access to the
LAN,
so
you
would want to push files out to the DMZ.
Anthony,
http://www.airdesk.com




"r14edge" <r14edge@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A7DD8E40-843A-4BFB-8057-58658DC9742F@xxxxxxxxxxxxxxxx
Hello,

I'm setting up a DMZ for my company and I'm facing a big problem.
I
planned my DMZ on using a remote file storage located in my
internal
network
to host my web files. I've build my DMZ in a new domain and I
have
setup a
trust relationship between my internal domain and my DMZ domain.
The
trust
is
one-way where the incoming trust is my internal domain and my
outgoing
trust
is my DMZ domain. On my remote file server, I'm able to see the
account
of
my
DMZ domain. I've set up the ACL on my share to be use by a
specific
account
in the DMZ without any problem.

Now, from any server in my DMZ, I'm able to get on the root
(\\10.0.0.0)
of
my share but when I click on the share itself, I got a access
denied
message.
I notice in the security log of the remote server that any DMZ
servers
that
tries to go on the remote file server, are logged under NT
AUTHORITY\ANONYMOUS LOGON.

What am I missing here? I believe that computers in my DMZ should
log
under
their name in the logs files, right? When I switch the trust
relationship,
it's working like a charm, but I'm exposing my internal Domain to
my
DMZ
and
I don't want that.

What can I do to solve this problem?

Thank you for your replies,

Fred


.



Relevant Pages

  • Re: DNS in DMZ
    ... the design chosen for this release is multiple forests ... server.company.dmz and is forwarded to a AD/DNS server in the DMZ. ... one way trust would work well if needed. ...
    (microsoft.public.windows.server.dns)
  • Re: frontend/backend question
    ... I have this exact configuration....your outlook clients on ... I have a frontEnd server ... in its own dmz for my owa users and it also routes all ...
    (microsoft.public.exchange.admin)
  • Re: Access denied on network share in an other domain
    ... Leaving aside the idea of the Trust for a moment, the idea is that hosts in the DMZ should have no or limited access to the LAN. ... It sounds as though what you would do is to copy out your data from the internal network to the DMZ. ... The copy needs to use credentials that the DMZ recognises, e.g a local account on the DMZ server, or else you can use a one way trust where DMZ servers trust internal server. ...
    (microsoft.public.windows.server.security)
  • Re: RRAS verhindert LAN-Verbindungen
    ... Funktioniert der Internetzugang für die Clients bzw. den Server? ... Ich tippe einmal, das der Print-Server in der DMZ steht (wenn ja, ... ISA-Firewall blockiert wird. ...
    (microsoft.public.de.german.backoffice.smallbiz)
  • Re: SBS2000 and a DMZ
    ... appropriate registry entries on the clients, ... Perhaps you could publish SUS to the DMZ segment. ... > but could not get CDDB(an internet service that is used to identify music ... > The W2K3 server is a recent addition and wanted it for storage of the boys ...
    (microsoft.public.backoffice.smallbiz2000)

Quantcast