Developing for a Domain Environment

Internal applications commonly utilize Active Directory to manage their user-base.  With this approach organizations can define the users and roles in one central location, and have that information available to many applications.

For intranet websites, this is accomplished by using Integrated Windows Authentication.  But what happens when you are developing on a machine that does not have the same accounts as the target environment?  Case in point:  say you have some Active Directory domain groups that define who the “readers” of an appliciation are and who the “editors” are.  The simple solution is to make these groups configurable through the web.config, and you can have something like this for development:

<add key=”adminRole” value=”Administrators” />

<add key=”adminRole” value=”DOMAIN\ApplicationAdmins” />

This gives us the benefit of using a local machine account for debugging the different roles, and allows for Integrated Windows Authentication to work properly.

Here’s another concern.  What if your code accesses a secure resource like a database or web service that requires valid Windows credentials and authorization?  A test database can easily be configured to accept SQL Authentication provided via connection string, but a Web Service that requires integrated Windows authentication?  Would you really want to mock a complex external dependency like this (Especially if it is a read-only dependency) ??  If you do you end up spending a large portion of your time just setting up the environment to develop in. 

I was dealing with a scenario just like this and I wanted to do use the web.config’s impersonate=”true” feature where I can supply a username & password to run as (You can even configure it to encrypt this data and store it in the registry using aspnet_setreg.exe… see here).  The problem here is that if I give it a valid domain account to impersonate, my local machine cannot authenticate me unless I join the computer to a domain.  For a lot of scenarios this is way too much to ask, and may not even be an option.

I could end up just constructing a NetworkCredentials object with the credentials I need to access the secure web service, but I don’t like that approach either.  It requires me to specify an account in plain text (either in code or in web.config… both of which are bad ideas.

Any thoughts on this?