Re: Authentication filter
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 10/09/04
- Next message: David Wang [Msft]: "Re: Cant't download "exe" file because of IIS version"
- Previous message: David Wang [Msft]: "Re: IIS error with ISAPI and virtual directory to remote svr .. 40"
- In reply to: doc pisapati: "Re: Authentication filter"
- Next in thread: mardacay: "RE: Authentication filter"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 8 Oct 2004 18:45:53 -0700
Then remove the trust between extranet and internal users. Once again, what
are you actually trying to do?
You've stated that you only want extranet users to see the external portal.
Makes sense. And they can't see the internal portal because you've
segmented the network between them so they can't get to the internal portal.
You've also stated that you want internal users to only use the internal
portal. Makes sense. All you do is remove the external portal's IP from
the internal machines so that users can't get to them.
What is not clear are these two scenarios:
1. An extranet user who happens to be running on one of your internal
machines. Their credentials cannot access the internal portal, and their
machine cannot see the external portal
2. An internal user who happens to be running on a machine outside of your
network. They can only see the external portal... but should they be
allowed access? This user can also VPN in, but this external machine now
knows both about the internal portal (via VPN) and external portal.
In any case, the eventual solution won't be found with IIS configuration
because it is not possible to figure out the identity of a user before
authenticating the user. Either your particular security guideline is
wrong/cannot be implemented, or you need to look at some other segmentation
scheme.
Personally, it may be easier for you to allow the user to authenticate to
the internal/external portal, no matter where they come from, and then write
an authentication piece in IIS to accept/reject the user based on policy.
You cannot implement a flexible policy without first determining identity --
which is what you are trying to do.
-- //David IIS This posting is provided "AS IS" with no warranties, and confers no rights. // "doc pisapati" <docpisapati@discussions.microsoft.com> wrote in message news:AAAE305F-67FD-47DD-B795-CA1D1C6BDD03@microsoft.com... But, it does not prevent internal userids from extranet-site site as 'trust' allows the authentication to the internal domain. "David Wang [Msft]" wrote: > > Is there a simple way to configure IIS 6.0? > > What about authentication firewall that is available on the > > external trust in windows 2003 domains? How do I > > configure IIS to take advantage of the authentication firewall? > > The fundamental conflict is that IIS has no way to determine whether an > authentication attempt is made by an internal or external user until AFTER > authentication is complete, but your security guidelines state that this > authentication attempt must be restricted -- i.e. internal user must go > through internal portal and not external portal. > > Thus, it seems that you need to make it impossible for internal users to see > the external WSS portal. Period. This assures you that internal users can > only use the internal WSS portal because they cannot even see (much less > authenticate against) the external portal. > > I suggest IP Security Policy to either block internal clients from seeing > the IP of the external WSS portal, or have the external WSS portal block all > internal IPs (or IPs from the proxy server). > > -- > //David > IIS > This posting is provided "AS IS" with no warranties, and confers no rights. > // > "doc pisapati" <docpisapati@discussions.microsoft.com> wrote in message > news:52667544-6D15-43A8-9FAE-9DA9F692D980@microsoft.com... > oops.. I mean that > ....All internal users have to access internal virtual server via VPN or > intranet. > sorry about that. > > "doc pisapati" wrote: > > > Hello David, > > I have two WSS virtual servers (one for external and one > > for internal). I have a dedicated domain for the external users > > authentication that trusts internal users domain. Both virtual servers > access > > same content database. However, from our security guidelines, I want to > > restrict the authentication (not just access rights) of internal users on > > external virtual server. All internal users have to come via internal > virtual > > server (that is opened to VPN or internet). > > > > Is there a simple way to configure IIS 6.0? What about authentication > > firewall that is available on the external trust in windows 2003 domains? > How > > do I configure IIS to take advantage of the authentication firewall? > > > > Thanks in advance, > > doc > > > > "David Wang [Msft]" wrote: > > > > > Based on your description, it is not possible. > > > > > > How do you plan to determine the user's identity and domain/forest > > > membership BEFORE IIS authenticates and obtains a user identity? > > > > > > What are you actually trying to do? > > > > > > -- > > > //David > > > IIS > > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > // > > > "doc pisapati" <doc pisapati@discussions.microsoft.com> wrote in message > > > news:F8D8C293-D215-4C6C-AAB2-63FB034E1DEC@microsoft.com... > > > I think that we can write an ISAPI filter to do some filtering before > IIS > > > authenticates. I want to restrict a particular domain users in a forest > > > trust. I would appreciate if someone can point me to the right ISAPI > filter > > > code. > > > > > > Thanks > > > doc > > > > > > > > > > > >
- Next message: David Wang [Msft]: "Re: Cant't download "exe" file because of IIS version"
- Previous message: David Wang [Msft]: "Re: IIS error with ISAPI and virtual directory to remote svr .. 40"
- In reply to: doc pisapati: "Re: Authentication filter"
- Next in thread: mardacay: "RE: Authentication filter"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
