When should server maintenance affect implementation descisions?

Question

Here's my situation...

I'm writing a .Net/C# security system (authorization and authentication) for a large collection of web applications that require a single sign-on process. I'm using Active Directory as a data store and have written a very nice prototype that communicates with AD through LDAP. This component retrieves information about the logged in user that I have stored in AD which I then use to set their security roles in .Net forms authentication.

1) All is good.

Not being a System Admin, or Network Engineer, I wasn't familiar with the amount of system administration involved with setting up an AD instance. I wasn't aware that for each domain, I needed a separate server and domain controller. As it turns out, there are like 9 different domains that my team requires to be set up for all of the different environments that we're going to be accessing AD...

• env1.dev.mycompany.com
• env1.qa.mycompany.com
• env1.stage.mycompany.com
• env2.dev.mycompany.com
• etc

...So now I have placed on upon myself somewhat of an administrative headache because I'm going to have to maintain all of these machines (or VM's), which is something that I'm not necessarily sure I want to do.

2) All is not good.

The prototype is really solid, and AD makes for a very good database for the solution, but now I'm wondering if I should scrap the code and write a SQL Server data provider instead (I know .Net already provides one, but it doesn't alone fit my business requirements for authorization).

Anyway, so I'm trying to think through this problem from a high level perspective. In general, I keep tripping over the fact that I would be throwing a really good solution just because of some server maintenance? I'm wondering if anyone here has experienced a scenario like this and what exactly you decided to do.

Doesn't have to be specific to AD either, just a situation where you had to evaluate between a good software solution and it's server maintenance constraints.

Answer 1

If setting up a single sign on system for a Windows system I be very likly to use AD. As a sys admin. I try to follow a single-source-of-data policy. AD is already holding much of my Windows user/security data. I would prefer to have all in there rather than a second system.

When setting up dev/test/prod environments I try to ensure that the closely match the Prod one, most especially in the area being worked on (where development efforts are being put, etc). So if setting up system to develop an interface with AD I would likely have multiple AD servers.

What options could simplify the admin?

Can you have 1 master server that you maintain in the standard manner and use something like a VMware copy process to maintain all or most of the others? Rather than doing something to 9 servers, keep the other 8 as copies of that mirror the master except for changes made to support dev/test?

Can you run multiple Dev or Test domains from 1 AD server?

Can you script action?

Can you reduce the number of environments, especially at the higher end of test? E.g. provide multiple dev environments and role up releases into a single Test one?

Answer 2

Why not simply use OUs instead of separate domains when testing? That is, have a single domain, but specify that users for particular versions must be found in a particular OU inside that domain. What you would do is in your search functions for looking up users, you'd specify the particular OU as the search root instead of the root of the domain. In each OU you could have ids that incorporate the environment to keep them unique, e.g., user_env1_dev, user_env2_dev, user_env1_qa, ...

I use AD a lot for my apps and never set up separate domains for development/testing.

Answer 3

In general, the usability of a product is what makes people to choose between it and similar products. If the product has bad usability, the users won't care how high quality its code is - all that matters to them is how easy and effective it is to use and how well it fills their needs.

Maintenance can be thought as one aspect of usability. I would make it top priority to have an easily maintainable product. In the long run that will save many hours of work from the administrators.

One way to think about it, is first designing what would be the most usable solution from the end user's/administrator's viewpoint, and then making it an intellectual challenge to actually implement that optimal solution. It will probably require more effort from the programmer, but the end result will be better.

For example ZFS is one product where maintenance has been taken care of well (although I have not used it personally). When it was designed, much effort was put into making it easy to administer the file system with ZFS's command line tools - and those design decisions affect all levels of ZFS (for example storage pools).

As another example, I've been recently planning how do maintenance in a future project of mine - a distributed database and application server. Thinking about how typical administration tasks will happen (installing/upgrading applications, adding/removing servers in the cluster, resolving hardware failure etc.), has helped me to sort out some design decisions. Some of them go quite deep into the architecture of the system (for example how applications and extensions are loaded at runtime, and how the servers find other servers in the cluster).

Answer 4

Use a provider pattern and abstract your datasource calls.

Then you can configure it to use AD or SQL on the fly.

public abstract SSODataProvider {
     public bool AuthenticateUser(string u, string p);
}

public ADSSODataProvider : SSODataProvider {
    public override AutheticateUser(string u, string p) {
       //do auth here
    }
}

public SQLSSODataProvider : SSODataProvider {
    public override AuthenticateUser(String u, string p) {
      //call DB
    }
}

public static SSODataProvider dataProvider;

if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
   dataProvider = new SQLSSODataProvider();
else
   dataProvider = new ADSSODataProvider();

....

dataProvider.AuthenticateUser("sss","sss");