views:

319

answers:

1

I am working on a WCF service (not externally available) that will authenticate users against Active Directory in two domains for users of our .NET 2.0 WinForm application. The authentication portion is mostly working, but I'm having some problems modifying Active Directory. Here are the basics on the situation and the requirements.

  1. Some external users of our application will log in to a Citrix server on a different domain within our DMZ. That has to be the only time they have to enter their credentials. So, an authenticated user in that domain has to be accepted as already authenticated, and application rights are loaded based on the user ID.
  2. There is a one-way trust relationship set up between the DMZ domain and our internal domain.
  3. Most external users install the application on their computers. We use .NET remoting to connect to our servers from the app. Authentication is user ID/password via remoting against information stored in SQL Server on our domain.
  4. Internal users, while in our domain, will be in a similar situation. They will launch the app and not need to enter any credentials, assuming they are logged in.
  5. All users - Active Directory or not - are still set up in our tables, which is where our rights management information is stored. There is a flag on the user table indicating whether the user is AD or not and fields indicating their domain and AD user ID (if different than their original one).
  6. If users are set up in Active Directory, either in the external domain or the internal domain, if they run the application installed on a computer not currently on the domain (i.e., from a laptop on the road), they would be authenticated against Active Directory. The remoted objects that handle authentication in #2 connect to the WCF service to get authentication.
  7. The same applies to users of our Web site (which uses the same credentials). If they are marked as Active Directory users, they are authenticated against it, not against our normal system.
  8. Some internal users that have the correct rights need to be able to set up users in Active Directory, modify them, unlock them and enable/disable them - in the external domain only.

The main questions I have are:

  1. What domain should that WCF service be in: External or Internal?
  2. What user should that service be running under to be able to accomplish all of the above, i.e., External\SVC-ADAuthentication, Internal\SVC-ADAuthentication, something else?

From my testing:

  1. When I run the service on External as External\SVC-ADAuthentication, I can modify AD information and authenticate against the External domain. Authentication against the Internal domain fails with "A referral was returned from the server"
  2. External as Internal\SVC-ADAuthentication: I can authenticate against both domains, but I cannot modify users on the External domain.
  3. Internal as Internal\SVC-ADAuthentication: I can authenticate against the internal domain only.
  4. Internal as External\SVC-ADAuthentication: Won't run (I'm assuming because of the one-way trust relationship).
A: 

If you look at the problem from a principles view point.

  • You do not want the external domain to be able to access the internal domain.
  • It is OK for the internal domain to access the external domain.

Therefore, you need to create a one way trust between the internal and external domain.

Place all services that can be accessed by external users on the external domain.

Shiraz Bhaiji
That's basically what I have. We do have a one-way trust set up between the internal and external domains. I have had the most success running the service in the external domain. However,1) If I run the service under an external domain account in the external domain, I cannot authenticate against the internal domain2) If I run the service under an internal domain account in the external domain, I cannot modify Active Directory in the external domain
Brian Kavanaugh