Is it possible to store database connection string information in Active Directory?

Question

Let's say you have many applications in your environment all of which store their connection strings to SQL Server in a web config. Is it possible to have the application retrieve those connection strings from Active Directory?

We're moving some database servers around and would like a way to have them read from a central location. Active Directory was suggested as one possibility, but we didn't know if it was possible.

This would, in theory, allow us to gradually change our applications to use AD to read the connection strings, then as we move our database servers, make one change in AD to update all the applications.

Is this possible? Maybe you have a better suggestion. Thanks!

Answer 1

Technically speaking, you can't store the information in LDAP since it is a protocol, not a storage mechanism. However, there is no reason (that I know of) that you couldn't store the information in Active Directory or other directory services type engine, and retrieve them with a query from the application. You would just need to come up with some organizational scheme and I would suggest some common code in a library or something that allows you to access the information.

I'm not saying that storing it in Active Directory is the best option, but I believe you should be able to do it without a problem.

Answer 2

We had a design to do that. Our architecture allowed multiple servers, each with multiple databases. We were using Active Directory to manage attributes about the users, including which databases they had access to.

It seemed logical design at the time, since we either had to do that or have a "master" database to direct. Using Active Directory, we no longer had a single point of failure.

Have no idea how it turned out, I left that company.

Answer 3

You could create a non-person user and have the connection string be an attribute in the user, but, that would be misusing the LDAP, IMO.

What may be better is to use dependency injection and just have common information such as a connection string, be in one file and just have it either read in when the application starts, or have it be injected in when recompiling.

For example, you could use Spring or Spring.NET, but there are a myriad of DI frameworks that would work.

UPDATE: You could also just create a database table that has this information, and all the applications could read from the database to get all their configuration information.

An LDAP should be used for directory-related issues, I believe, as well as, now, user-management and account information.

Answer 4

You can store the connectionstrings about anywhere you want. You could even do them as TXT records on your DSN servers. But you would have to build the resolution framework yourself. Also keep in mind that the connection strings make contain secure information. (such as passwords). If you store these in LDAP (I am speaking genericly for any ldap based server) you will want to make sure the attribute is not public. The upside is LDAP proxy accounts (anonymous connections) would not be able to see the information. The downside is you will have to do an LDAP bind before you can get the information back out of the system. As long as you cache a connection string on the client/server that is going to be making the database calls, you shouldn't see any real performace issues. But if you had to query an LDAP server before each database call you might have problems.

a custom object or even an extension attribute for an exsisting object may be best.

Extend AD Schema

Answer 5

"The LDAP should be for directory information"

What does that mean? Configuration information is a perfect candidate for being stored in the Dit - it is read intensive, secure, replicated, and easy to access. Most of what is stored in Active Directory is "configuration information".