How do I authenticate against Active Directory from ASP.NET web service code?

Question

I have a few websites for work that live outside of the corporate LAN -- and, therefore, out of direct-communication range of Active Directory (A/D) -- but for which I would like to be able to authenticate users against the corporate A/D servers as well as a secondary repository of users/roles***. The pseudo code for this activity is this:

1. User enters username/password into the login form of the external website.
2. External website calls a webservice inside the LAN that can talk to A/D.
3. The webservice checks to see if username/password can be authenticated mapped to a user in A/D. If so, return the list of A/D roles of which the user is a member.
4. If the username/password cannot be found/authenticated against A/D, check a database/service that is the secondary repository of user/role information. Return all roles the use is in if they authenticate against the secondary auth server.
5. Return the a list of roles the user is in to the calling website.

*** The idea is that we don't want to put dozens -- potentially hundreds -- of contractors and affiliates into Active Directory when all they will only be logging into our external web servers. Hence the secondary auth scheme.

Answer 1

I think there are a couple of layers here, each one its own question:

How can I get to a web service inside my LAN from the DMZ?
This is a tough one as it really breaks the concept of a DMZ/LAN seperation. Generally connections between LAN and DMZ are only allowed (and on a limited basis) from the LAN side - this way a comprimised DMZ can't initiate contact with the LAN, and is extremely restricted in what it can do (it's can't issue arbitrary requests, only respond to requests from the LAN).

How can I use a service on another computer to authenticate a username/password?
Again this is a sticky problem - you are passing passwords over a network - is it possible for them to be intercepted. With AD this is solved with kerberos - a system of challenge/response that ensure the password is never actually transmitted. Of course kerberos and similar protocals are quite complex - you should never try to roll your own as it will likely be less secure then using something existing - for example your webservice could operate on https, so that at least the passwords are only plaintext on the two servers, and not the communications link inbetween. Certificates can also be used to prevent traffic intended for your LAN webservice from being rerouted to a comprimised DMZ machine (the comprimised DMZ machine won't be able to fake the certificate, and so your system can determine it is connected to a fake server before sending details for authentication)

In my own experience these issues result in AD outside the LAN just not being done. Companies opt to either get outside people on the LAN using VPN authenticated with RSA keys (those little keychains that show a constantly changing set of numbers), or they use an entirely seperate set of logins for the DMZ area services.