How easy is it to store DB connection strings in ActiveDirectory instead of web.config

[Naraendirakumar R.R.]

I have a client in the healthcare industry who would prefer to store the
connection string in a centralized location in their Active Directory
repository.

Has anybody done this? What has your experience been?

Are there any stock components in ASP.NET or 3rd party that would make this
easy?

Thank you for the info.

Cheers,
-Naraen

 

[Mark Rae [MVP]]

I have a client in the healthcare industry who would prefer to store the
connection string in a centralized location in their Active Directory
repository.

Has anybody done this?

Not personally, but there is theoretically no reason why not...

Having said that, I can't think of any valid reason for doing so...

Are there any stock components in ASP.NET or 3rd party that would make
this easy?

ActiveDirectory connectivity is built directly into the .NET Framework:
http://www.google.co.uk/search?sour...UTF-8&rlz=1T4GZEZ_en-GBGB252GB252&q=.NET+ADSI

 

[John Timney \(MVP\)]

I have to agree - I can't either think of any valid reason, especially when
the string could simply be encrypted in web.config. The overhead of
querying AD would certainly put it at the back of the suggestion list.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Joe Kaplan]

You could do this. You'd probably still want to encrypt any private data
that you don't want to be available to the general public, but it is
possible to store this data in AD and retrieve it via LDAP.

The trick is where you would put the data. The default schema doesn't have
a natural place to store these types of things. Does the client know where
they would like this data stored in the AD?

Joe K.

 

[Naraendirakumar R.R.]

Mark, John:
Thank you for your response.

As you have probably guessed the reasons the client is asking for this are
part technical but part compliance specific. From a HIPAA and SOX point of
view they would like to portray a clear seperation of responsibilities to
their auditors. They can "prove" to their auditors that nobody but a
limited group of people has access to the db password and hence only a
limited group of people can see the personally identifiable data.

Currently developers and other operators have access to the "production" web
server for all kinds of maintenance reasons. So, they can't make a
reasonable argument that encryption feature offered by ASP.NET is
sufficient. Sandboxing and isolating is not something they can do
immediately.

In the interim, I was hoping I could provide a solution that would address
their compliance concerns. They are already doing something similar on the
Java side using LDAP and JNDI to store connection strings as well as
connection objects.

Being able to do the same thing using Active Directory for ASP.NET would be
well aligned to their current SOP.

Appreciate any further comments you might have.

Cheers,
-Naraen

I have to agree - I can't either think of any valid reason, especially when
the string could simply be encrypted in web.config. The overhead of
querying AD would certainly put it at the back of the suggestion list.

Regards

John Timney (MVP)
http://www.johntimney.com
http://www.johntimney.com/blog

 

[Naraendirakumar R.R.]

Joe:
Thank you for the response.

Yes. The current thinking is that we would create a seperate OU to contain
all application specific settings. They do something similar using JNDI
over LDAP at this point. So, this is an attempt to mimic that practice on
the .NET stack.

Yes the plan is to encrypt data.

I was hoping there would be a way to map the .NET config classes to use LDAP
as the backing store for config info. Or atleast somebody else might be
aware of a partial solution.

I haven't stayed current on the AD technology. I remember from some 2001
work we did, that we decided to have stored proc references in AD as a way
of advertising services to the enterprise. Our team picked up this
technique from one of the SQL Pass sessions we attended. I haven't been
able to find a reference on the web now.

I appreciate insights or comments you might have.

Cheers,
-Naraen

 

[Mark Rae [MVP]]

Currently developers and other operators have access to the "production"
web server for all kinds of maintenance reasons. So, they can't make a
reasonable argument that encryption feature offered by ASP.NET is
sufficient. Sandboxing and isolating is not something they can do
immediately.
OK.

In the interim, I was hoping I could provide a solution that would address
their compliance concerns.

Have you looked at ASPNET_SETREG? That would allow you to store the
connection string encrypted in the webserver's Registry. Even if someone
were to find the key, they'd not be able to decrypt it (at least, not very
easily or quickly):
http://support.microsoft.com/kb/329290

Being able to do the same thing using Active Directory for ASP.NET would
be well aligned to their current SOP.

Joe K has already highlighted the main problem with this, namely where you
will actually store it since there's nothing built-in to AD...

 

[Naraendirakumar R.R.]

Mark: Yes we did consider storing it in the registry. It is one of the
fallback options if we can't figure out way to leverage AD for this
information.

Thanks for the followup.

Cheers,
-Naraen

 

[Mark Rae [MVP]]

Yes we did consider storing it in the registry. It is one of the fallback
options if we can't figure out a way to use AD for this information.

OK.

 

[Guest]

Mark, John:
Thank you for your response.

As you have probably guessed the reasons the client is asking for this are
part technical but part compliance specific.  From a HIPAA and SOX point of
view they would like to portray a clear seperation of responsibilities to
their auditors.  They can "prove" to their auditors that nobody but a
limited group of people has access to the db password and hence only a
limited group of people can see the personally identifiable data.

Naraen,

if IIS and SQL in the same or in trusted domains, I think you can use
integrated security to make a trusted connection with SQL Server. This
would eliminate the need for storing a password in the connection
string.

 

[Joe Kaplan]

Well, from my perspective there isn't really too much to this. Assuming
that the client already has the schema worked out for the objects and
attributes they want to use for storage of this data, you just need some
LDAP code to read and write it (maybe only read within the applications
themselves) and decrypt it.

You've got a couple of options for programming LDAP in .NET 2+:
System.DirectoryServices (based on ADSI) and
System.DirectoryServices.Protocols (using direct LDAP API calls). Either
should work for this.

If you want to get up to speed on .NET LDAP programming, my book (see link
in sig) is a good way to go and is also just about the only thing out there.


Joe K.

 

[Naraendirakumar R.R.]

Alexy:
Thank you for the response.

These folks use Oracle and some other database technologies (which can be
accessed via OleDB) from the early 80's that I haven't heard of so far.

I have heard that it is possible to use trusted connection with Oracle but
haven't tested it. The other legacy database is the barrier to this
approach.

. I am starting to have a sinking feeling in the pit of my stomach.

Appreciate any additional suggestions.
-Naraen

Mark, John:
Thank you for your response.

As you have probably guessed the reasons the client is asking for this are
part technical but part compliance specific. From a HIPAA and SOX point of
view they would like to portray a clear seperation of responsibilities to
their auditors. They can "prove" to their auditors that nobody but a
limited group of people has access to the db password and hence only a
limited group of people can see the personally identifiable data.

Naraen,

if IIS and SQL in the same or in trusted domains, I think you can use
integrated security to make a trusted connection with SQL Server. This
would eliminate the need for storing a password in the connection
string.

 

[Naraendirakumar R.R.]

. Thanks Joe. I will check it out.

If that is the last resort, I am considering implementing a
System.ConfigurationSection provider that queries the ADSI store, for this
information. Haven't figured out all the details yet. But it seems like a
feasible approach.

Appreciate any additional comments.

Cheers,
-Naraen

 

[Joe Kaplan]

Feel free to follow up if you have specific questions about how to do the
LDAP queries or anything having to do with the directory schema that is
being used to store this information. Start a new thread though.

Joe K.

 

[Guest]

Alexy:
Thank you for the response.

These folks use Oracle and some other database technologies (which can be
accessed via OleDB) from the early 80's that I haven't heard of so far.

What version do you have? 10g has a feature called External Password
Store to store all passwords in the special secure client-side wallet.