AD & ADAM together in harmony

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

Re: AD & ADAM together in harmony

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" wrote in message
news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
> 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

Re: AD & ADAM together in harmony

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" wrote in message
> news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
> > 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
>
>
>

Re: AD & ADAM together in harmony

well, you could setup a new domain in the extranet and enable a cross forest
trust. you cannot pass credentials thru the firewall, so you would need to
use basic authentication for site acces from the extranet


"GrITMan" wrote in message
news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
> 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

Re: AD & ADAM together in harmony

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" wrote in message
news:E929D606-EE1A-4287-8F7B-7C4A7E295539@microsoft.com...
> 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" wrote in message
>> news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
>> > 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
>>
>>
>>

Re: AD & ADAM together in harmony

I think you have a few options.

If you want to use ADAM (and there are reasons for this - keeping your
production AD forest away from external access is a very valid
consideration!), then you could use Forms Auth + standard LDAP/ADSI queries
in your pages. To facilitate this you probably want to configure two
separate websites in IIS, but point them to the same content. One would have
IWA enabled, the other (for external access) would permit anonymous access.
Your security module in your app would work out whether to present a login
form or not.

If you ever need to synch data between ADAM and AD (for whatever reason) you
can use a Directory Synchronisation tool like MIIS (though that is quite
expensive).

Whilst Anthony is correct in stating that you can use your production AD
infrastructure, I would be give this careful consideration. Giving externals
users valid accounts in your production AD does give them access to your
domain (by default). If there's some way that a malicious user could
leverage your web app to access other resources and/or elevate their
privileges, they could potentially own your entire AD.

Cheers
Ken


"GrITMan" wrote in message
news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
> 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

Re: AD & ADAM together in harmony

You might want to look into ADFS for this. It supports using both AD and
ADAM as the source for authentication and can provide both windows
impersonation tokens for those users as well as role based information. The
role information is limited to .NET 2.X applications but if you are building
new this may not be an issue.

-Robert
"GrITMan" wrote in message
news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
> 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

Re: AD & ADAM together in harmony

I think this is the way we're heading.
Looking back, my initial interest in ADAM was essentially having an
externally functional AD that was separate from my domain. It all started
with fateful words from business and development "We want to", closely
followed by what can be loosely translated as "fiddle in your AD", at which
point I started seeing red and hyperventilating.

I'm trying to keep the admin on external user access to applications
separate from infrastructural administration - I don't want the support desk
having to deal with thousands of 'application password' queries they have no
access to address, or domain admins getting a thousand users to add to AD
whenever a new client comes on board. This needs to be managed separately,
away from my domain, and we can safely let dev fiddle as much as they like
with ADAM OU's without worrying about the integrity of our AD. Well, this is
the theory based on a few days worth of reading anyway.

The web server will be published via reverse proxy to ISA, and we are
registering an SSL for the site with a public cert auth, so the first mile
between user and web-access point will be secured against watchful eyes.
Well, as secure as SSL supposedly is anyway.

My only other concern, (which is a completely different issue to this
thread), is making sure the developers protect their code against injection.

Thanks for the feedback!

"Ken Schaefer" wrote:

> I think you have a few options.
>
> If you want to use ADAM (and there are reasons for this - keeping your
> production AD forest away from external access is a very valid
> consideration!), then you could use Forms Auth + standard LDAP/ADSI queries
> in your pages. To facilitate this you probably want to configure two
> separate websites in IIS, but point them to the same content. One would have
> IWA enabled, the other (for external access) would permit anonymous access.
> Your security module in your app would work out whether to present a login
> form or not.
>
> If you ever need to synch data between ADAM and AD (for whatever reason) you
> can use a Directory Synchronisation tool like MIIS (though that is quite
> expensive).
>
> Whilst Anthony is correct in stating that you can use your production AD
> infrastructure, I would be give this careful consideration. Giving externals
> users valid accounts in your production AD does give them access to your
> domain (by default). If there's some way that a malicious user could
> leverage your web app to access other resources and/or elevate their
> privileges, they could potentially own your entire AD.
>
> Cheers
> Ken
>
>
> "GrITMan" wrote in message
> news:0654A1BF-CA02-4D21-B929-BEE67E005CCE@microsoft.com...
> > 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
>
>
>