By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,976 Members | 1,139 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,976 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Jan 5 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:Od****************@TK2MSFTNGP03.phx.gbl...
>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?sourc...&q=%2eNET+ADSI
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Jan 5 '08 #2

P: n/a
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
"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:e1**************@TK2MSFTNGP06.phx.gbl...
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:Od****************@TK2MSFTNGP03.phx.gbl...
>>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?sourc...&q=%2eNET+ADSI
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Jan 5 '08 #3

P: n/a
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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:Od****************@TK2MSFTNGP03.phx.gbl...
>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

Jan 8 '08 #4

P: n/a
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
"Joe Kaplan" <jo*************@removethis.accenture.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:Od****************@TK2MSFTNGP03.phx.gbl...
>>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


Jan 8 '08 #5

P: n/a
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
"John Timney (MVP)" <xy******@timney.eclipse.co.ukwrote in message
news:of*********************@eclipse.net.uk...
>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
"Mark Rae [MVP]" <ma**@markNOSPAMrae.netwrote in message
news:e1**************@TK2MSFTNGP06.phx.gbl...
>"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:Od****************@TK2MSFTNGP03.phx.gbl...
>>>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?sourc...&q=%2eNET+ADSI
--
Mark Rae
ASP.NET MVP
http://www.markrae.net


Jan 8 '08 #6

P: n/a
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:OT**************@TK2MSFTNGP02.phx.gbl...
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...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Jan 8 '08 #7

P: n/a
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]" <ma**@markNOSPAMrae.netwrote in message
news:eE**************@TK2MSFTNGP06.phx.gbl...
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:OT**************@TK2MSFTNGP02.phx.gbl...
>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...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Jan 8 '08 #8

P: n/a
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:eC**************@TK2MSFTNGP04.phx.gbl...
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.
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

Jan 8 '08 #9

P: n/a
On Jan 8, 8:28*am, "Naraendirakumar R.R." <nos...@nospam.comwrote:
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 pointof
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.
Jan 8 '08 #10

P: n/a
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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:OG**************@TK2MSFTNGP02.phx.gbl...
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

Jan 8 '08 #11

P: n/a
:-). 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" <jo*************@removethis.accenture.comwrote in message
news:Oq****************@TK2MSFTNGP04.phx.gbl...
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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:OG**************@TK2MSFTNGP02.phx.gbl...
>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


Jan 9 '08 #12

P: n/a
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

"Alexey Smirnov" <al************@gmail.comwrote in message
news:c3**********************************@i7g2000p rf.googlegroups.com...
On Jan 8, 8:28 am, "Naraendirakumar R.R." <nos...@nospam.comwrote:
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.
Jan 9 '08 #13

P: n/a
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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:uu**************@TK2MSFTNGP06.phx.gbl...
:-). 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" <jo*************@removethis.accenture.comwrote in message
news:Oq****************@TK2MSFTNGP04.phx.gbl...
>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.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Naraendirakumar R.R." <no****@nospam.comwrote in message
news:OG**************@TK2MSFTNGP02.phx.gbl...
>>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



Jan 9 '08 #14

P: n/a
On Jan 9, 1:44*am, "Naraendirakumar R.R." <nos...@nospam.comwrote:
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.
Jan 9 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.