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
"Naraendirakumar R.R."
news:Od%23ajt9TIHA.4656@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?sourceid=navclient&aq=t&hl=en -GB&ie=UTF-8&rlz=1T4GZEZ_en-GBGB252GB252&q=%2eNET+ADSI
--
Mark Rae
ASP.NET MVP
http://www.markrae.net
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]"
news:e1EJ569TIHA.4440@TK2MSFTNGP06.phx.gbl...
> "Naraendirakumar R.R."
> news:Od%23ajt9TIHA.4656@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?sourceid=navclient&aq=t&hl=en -GB&ie=UTF-8&rlz=1T4GZEZ_en-GBGB252GB252&q=%2eNET+ADSI
>
>
> --
> Mark Rae
> ASP.NET MVP
> http://www.markrae.net
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."
news:Od%23ajt9TIHA.4656@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
>
>
>
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)"
news:of-dnXgql4SlZ-LaRVnyigA@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]"
> news:e1EJ569TIHA.4440@TK2MSFTNGP06.phx.gbl...
>> "Naraendirakumar R.R."
>> news:Od%23ajt9TIHA.4656@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?sourceid=navclient&aq=t&hl=en -GB&ie=UTF-8&rlz=1T4GZEZ_en-GBGB252GB252&q=%2eNET+ADSI
>>
>>
>> --
>> Mark Rae
>> ASP.NET MVP
>> http://www.markrae.net
>
>
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"
news:%23wEHJTbUIHA.1212@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."
> news:Od%23ajt9TIHA.4656@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
>>
>>
>>
>
>
"Naraendirakumar R.R."
news:OTDVYkcUIHA.5264@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
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]"
news:eEOL4tcUIHA.4684@TK2MSFTNGP06.phx.gbl...
> "Naraendirakumar R.R."
> news:OTDVYkcUIHA.5264@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
"Naraendirakumar R.R."
news:eCePFxdUIHA.5288@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
On Jan 8, 8:28=A0am, "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. =A0From a HIPAA and SOX point=
of
> view they would like to portray a clear seperation of responsibilities to
> their auditors. =A0They 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.
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."
news:OGZaYkcUIHA.5264@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
>
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"
news:c3e420ea-b0b3-4718-897c-543bac2a8bea@i7g2000prf.googleg roups.com...
On Jan 8, 8:28 am, "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.
>
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.
:-). 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"
news:OqErF%23gUIHA.5508@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."
> news:OGZaYkcUIHA.5264@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
>>
>
>
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."
news:uu7KYllUIHA.3676@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"
> news:OqErF%23gUIHA.5508@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."
>> news:OGZaYkcUIHA.5264@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
>>>
>>
>>
>
>
On Jan 9, 1:44=A0am, "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.
>
What version do you have? 10g has a feature called External Password
Store to store all passwords in the special secure client-side wallet.