Hi!
I have a late requirement from de Security Department.
This is the situation: the apps must connect to SQL Server 2000 through OLE
DB using a generic user, but the developers will not know its credentials
(at least the password)
Unfortunatelly, like I said, this is a late requirement because there are
many apps already working, obviously knowing the credentials.
I spent so much time thinking a way to solve this problem without
codification, finally I arrived to this idea, but I don't know if it's
achievable.
- Create a new user in SQL Server and grant the right permissions on the
addecuate DBs
- Deny permissions to the old user
- Leave the apps just how they are now
- When an app attempt to open a connection, SQL Server must modify the old
credentials with the new ones...
Is this possible?
And obviously...how?
Otherwise, do you know another solution (without reprogramming)?
Thanks in advance,
Promenade
PS: I apologize my english
Consider using an application role. They can login as themselves and then
set the application role. The role stays in effect until logout. You may
have issues with connection pooling, however.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
"Promenade" <promenade@.no.com> wrote in message
news:OwhJb2pwFHA.2656@.TK2MSFTNGP09.phx.gbl...
> Hi!
> I have a late requirement from de Security Department.
> This is the situation: the apps must connect to SQL Server 2000 through
> OLE
> DB using a generic user, but the developers will not know its credentials
> (at least the password)
> Unfortunatelly, like I said, this is a late requirement because there are
> many apps already working, obviously knowing the credentials.
> I spent so much time thinking a way to solve this problem without
> codification, finally I arrived to this idea, but I don't know if it's
> achievable.
> - Create a new user in SQL Server and grant the right permissions on the
> addecuate DBs
> - Deny permissions to the old user
> - Leave the apps just how they are now
> - When an app attempt to open a connection, SQL Server must modify the old
> credentials with the new ones...
> Is this possible?
> And obviously...how?
> Otherwise, do you know another solution (without reprogramming)?
> Thanks in advance,
> Promenade
> PS: I apologize my english
>
|||Thank you very much, Tom...
I don't know anything about application roles, so maybe you can help me...
When you said "They can login as themselves and then set the application
role"...the process of setting the application role has to be made in every
application code or this task can be made in SQL Server?
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:#tiGw8pwFHA.2132@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Consider using an application role. They can login as themselves and then
> set the application role. The role stays in effect until logout. You may
> have issues with connection pooling, however.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> "Promenade" <promenade@.no.com> wrote in message
> news:OwhJb2pwFHA.2656@.TK2MSFTNGP09.phx.gbl...
credentials[vbcol=seagreen]
are[vbcol=seagreen]
old
>
|||The application need to set the application role using sp_setapprole.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Promenade" <promenade@.no.com> wrote in message news:u3nPbjqwFHA.596@.TK2MSFTNGP12.phx.gbl...
> Thank you very much, Tom...
> I don't know anything about application roles, so maybe you can help me...
> When you said "They can login as themselves and then set the application
> role"...the process of setting the application role has to be made in every
> application code or this task can be made in SQL Server?
>
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:#tiGw8pwFHA.2132@.TK2MSFTNGP15.phx.gbl...
> credentials
> are
> old
>
|||The problem is that the Client makes the connection; so, there is no way to
intervene at the server to modify this.
Thus, that is why using Windows Authentication is a best practice. Unless
you log on as that user, you can't gain access. Also, with WA, no passwords
are ever transmitted over the network.
Another best practice, DEVELOPERS NEVER DO THE PRODUCTION INSTALLATION:
that's what Server Administrators are for. Thus, the Operations team has
the credentials (locked away in a vault somewhere) but the developer/end
users can use the product.
Basically, you are not going to get away with correcting bad practices
without recoding/redesigning the bad apps is some manner.
There's a saying, which may be a little harsh, but is applicable in this
situation: "There is no patch [nor hotfix] for stupidity."
Sincerely,
Anthony Thomas
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:O4guKXrwFHA.2960@.tk2msftngp13.phx.gbl...
The application need to set the application role using sp_setapprole.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Promenade" <promenade@.no.com> wrote in message
news:u3nPbjqwFHA.596@.TK2MSFTNGP12.phx.gbl...
> Thank you very much, Tom...
> I don't know anything about application roles, so maybe you can help me...
> When you said "They can login as themselves and then set the application
> role"...the process of setting the application role has to be made in
every[vbcol=seagreen]
> application code or this task can be made in SQL Server?
>
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:#tiGw8pwFHA.2132@.TK2MSFTNGP15.phx.gbl...
then[vbcol=seagreen]
may[vbcol=seagreen]
> credentials
> are
the
> old
>
Friday, February 10, 2012
Changing credentials on-the-fly
Labels:
apps,
changing,
connect,
credentials,
database,
department,
hii,
microsoft,
mysql,
oledb,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment