Re: AD & ADAM together in harmony
- From: "Anthony" <anthony.spam@xxxxxxxxxxxxxx>
- Date: Tue, 11 Jul 2006 23:15:31 +0100
You can use a separate OU in the AD for external users. If you have x'000
users it doesn't really matter which AD they are in, they still need to be
administered.
You are not really exposing the AD to the outside world. You are exposing it
to the web host. So if the web host is compromised, it potentially has
access to the DC. It is exposed to the web host whether one or a thousand
people authenticate. Your protections is one of these:
- Secure the external access before they get to the web host, so the web
host is as safe as if it were on the intranet. You can do this with VPN, SSL
VPN, Reverse Proxy etc.
- Secure the DC from the web host. You can do that with LDAPS or LOGIN
authentication, either way you do not allow RPC between them.
- The most complete way is a separate AD or ADAM, but then of course your
internal users have to have a different password. If you enable a trust then
you have opened the firewall again. Federation Services deals with this, but
now we are getting very elaborate.
Anthony
"GrITMan" <GrITMan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E929D606-EE1A-4287-8F7B-7C4A7E295539@xxxxxxxxxxxxxxxx
Makes sense, but I think the main idea behind us wanting to keep the two
separate is mainly one of admin - the external ADAM could potentially host
an
infinite number of users, especially if we start allowing for payroll
members
to connect and view stuff like payslips etc.
We don't want to expose the whole of AD to the outside world just so they
can access an ASP page - there are other security mechanisms in SQL that
will
handle application level security such as access to payroll data and so
on.
The problem is really of initial entry-point authentication.
We've already decided on a reverse-proxied ISA SSL publication of the
internal web server - this will handle encryption and host verification.
Please bear in mind I'm new to the ADAM concept and have never implemented
it, so I may be basing assumptions on preconceptions that don't apply.
I wanted to keep this away from our internal AD to ensure its integrity
and
keep internal AD administration to typically "daily admin stuff" - not a
24x7
user accounts management nightmare which could theoretically happen with
ADAM.
We've thought about the other alternative with another domain but the
admin
overhead would rival managing a single AD with all users.
Again, perhaps I need to reconsider the entire design architecture, I'm
basing this on assumptions...
"Anthony" wrote:
This is a really interesting problem, how to authenticate users on an
extranet application. I don't have a fix for you, but a few thoughts.
If you are authenticating internal users to the AD, then you are exposing
the AD to that host. Once you have done that, you may as well give
external
users an acount on your AD as well. I can't see the point of having a
separate user database for external connections to an internal host.
If you are worried about exposing the AD to the host, then you can use
LDAPS
to limit the risk. Using LOGIN authentication would achieve the same
thing.
You can also use authentication on the firewall or SSL VPN to
authenticate
external users safely before they get to the application.
The most elaborate method is to have a separate domain for the DMZ, using
Federation Services to keep the usernames and passwords in sync, but this
is
excessively complex.
Anthony
"GrITMan" <GrITMan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@xxxxxxxxxxxxxxxx
We are planning on building an Intranet/Extranet for our payroll
application.
The idea is to use AD integrated IIS security for internal users to
automatically identify and authenticate them on IE access, and use ADAM
for
clients.
The architecture will involve an internally hosted web server that will
be
available to internal users, plus we will publish these pages via ISA
reverse
proxy and SSL externally to the outside world.
The problem we have is figuring out how we go about switching from AD
to
ADAM during the authentication process? If, for example, the user does
not
authenticate automatically, how do we get it to check ADAM instead of
popping
up a username and password dialogue for AD?
We have been told to use Forms authentication instead of IIS, but no
indication of actually how this would work or how to develop it.
The second option I have suggested to the dev team is to split the
authentication physically into two separate pages, one for internal,
one
for
external access. Thus we authenticate at the point of entry and then
converge on single site content keeping that authentication in the
session.
Again though, if we enable windows integrated security for the site, it
applies to the whole site, so even if we authenticate external users up
front
with ADAM, further down the the line they will hit AD security
somewhere
and
we're back to square one (even this is a guess, we're not sure how this
will
pan out)
What I want to know is a) are we going about this the right way? and b)
if
we are, how do we do this?
Any suggestions or advice will be welcome
Thanks
GrITMan
.
- References:
- Re: AD & ADAM together in harmony
- From: Anthony
- Re: AD & ADAM together in harmony
- From: GrITMan
- Re: AD & ADAM together in harmony
- Prev by Date: Re: AD & ADAM together in harmony
- Next by Date: Re: AD & ADAM together in harmony
- Previous by thread: Re: AD & ADAM together in harmony
- Next by thread: Re: AD & ADAM together in harmony
- Index(es):
Relevant Pages
|
