When does server maintenance affect implementation descriptions?

Question

Here is my situation ...

I am writing a .Net / C # security system (authorization and authentication) for a large collection of web applications that require a single registration process. I use Active Directory as a data warehouse and have written a very good prototype that interacts with AD through LDAP. This component retrieves information about a registered user that I saved in AD, which I then use to set their security roles in .NET authentication.

1) All is well.

Not being a system administrator or network engineer, I was not familiar with the amount of system administration involved in setting up an AD instance. I did not know that for each domain I needed a separate server and domain controller. As it turned out, there are 9 different domains that my team needs to configure for all the different environments that we will access AD ...

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

... So now I have put on some administrative headache because I will have to support all these machines (or virtual machines), which I'm not necessarily sure what I want to do.

2) Everything is bad.

The prototype is really strong, and AD creates a very good database for the solution, but now I am wondering if I should give up the code and write the SQL Server data provider instead (I know that .Net already provides one, but this does not fit my business -authorization requirements).

In any case, I am trying to think over this problem from a high level point of view. In general, I continue to argue that I would choose a really good solution just because of some server maintenance? I am wondering if someone here has experienced such a scenario and what exactly you decide to do.

It is not necessary to be specific to AD, it is just a situation where you had to evaluate a good software solution and limitations on server maintenance.

Answer 1

In general, the usability of a product is what makes people choose between it and similar products. If a product has poor usability, users do not care how good its code is - all that matters to them is how easy and efficient it is to use and how it meets their needs.

Maintenance can be seen as one aspect of usability. I would set myself paramount in order to have an easily repairable product. Ultimately, this will save many hours of work for administrators.

One way to think about this is to first develop what will be the most convenient solution to use from the point of view of the end user / administrator, and then make an intelligent call to implement this optimal solution. This will probably require more effort from the programmer, but the end result will be better.

For example, ZFS is one product that takes care of the service well (although I haven’t used it personally). When this was developed, much effort was made to simplify file system administration using ZFS command-line tools, and these design decisions affect all levels of ZFS (for example, storage pools).

As another example, I recently planned how to perform maintenance on my future project - a distributed database and application server. Thinking about how typical administrative tasks will be performed (installing / updating applications, adding / removing servers in a cluster, fixing a hardware failure, etc.), it helped me to understand some design decisions. Some of them penetrate quite deeply into the system architecture (for example, how applications and extensions are loaded at runtime, and how servers find other servers in the cluster).

Answer 2

When setting up a single character in a system for a Windows system, I really like to use AD. As the sys admin. I try to follow a single data source policy. AD already contains most of the Windows user / security data. I would prefer that everything was there, not the second system.

When setting up dev / test / prod environments, I try to ensure that they closely match Prod, especially in the area in which I worked (where development efforts are made, etc.). Therefore, if you are setting up a system to develop an interface with AD, I will probably have several AD servers.

What options can simplify administration?

Can you have 1 master server that you support in a standard way and use something like a VMware copy process to support all or most of the others? Instead of doing something on 9 servers, keep the remaining 8 as copies of this mirror in the main, except for the changes made to dev / test support?

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

Can you script the action?

Can you reduce the number of media, especially at the higher end of the test? For example. provide multiple development environments and roles up in one test?

Answer 3

Why not just use OU instead of individual domains for testing? That is, to have one domain, but indicate that users for certain versions should be found in a specific unit within this domain. What would you do is in your search functions to search for users, you must specify a specific OU as the search root instead of the domain root. In each department, you can have identifiers that include the environment in order to keep them unique, for example, user_env1_dev , user_env2_dev , user_env1_qa , ...

I use AD for my applications and never configure separate domains for development / testing.

Answer 4

Use a provider template and abstract your calls with a data source.

You can then 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");