| Groups | Blog | Home |
iis security : 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
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... [quoted text, click to view] "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@discussions.microsoft.com> 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 > >
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 [quoted text, click to view] "GrITMan" <GrITMan@discussions.microsoft.com> 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
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 [quoted text, click to view] "GrITMan" <GrITMan@discussions.microsoft.com> 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
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 [quoted text, click to view] "GrITMan" <GrITMan@discussions.microsoft.com> 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" <GrITMan@discussions.microsoft.com> 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 >> >> >>
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 [quoted text, click to view] "GrITMan" <GrITMan@discussions.microsoft.com> 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
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 [quoted text, click to view] "GrITMan" <GrITMan@discussions.microsoft.com> 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
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! [quoted text, click to view] "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" <GrITMan@discussions.microsoft.com> 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 > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |