Recently, I was prompted to change my domain password. Changed service
account for SQL and RS (2000 both) and reports and datasource credentials.
Reports run fine. However, getting the infamous "An internal error occurred
on the report server. See the error log for more details." error on all
subscriptions when nothing else changed. Went in and ran rsconfig to update
with the latest pwd but no joy. I know I'm missing something obvious but am
still futzing with this.
Any thoughts as to what I should be checking/correcting?Just a guess, but if your subscriptions store the report as a pdf in a
directory, could there be permissions problems there?
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
I support the Professional Association for SQL Server ( PASS) and it''s
community of SQL Professionals.
"kvanhulle" wrote:
> Recently, I was prompted to change my domain password. Changed service
> account for SQL and RS (2000 both) and reports and datasource credentials.
> Reports run fine. However, getting the infamous "An internal error occurred
> on the report server. See the error log for more details." error on all
> subscriptions when nothing else changed. Went in and ran rsconfig to update
> with the latest pwd but no joy. I know I'm missing something obvious but am
> still futzing with this.
> Any thoughts as to what I should be checking/correcting?
>
>
Showing posts with label credentials. Show all posts
Showing posts with label credentials. Show all posts
Tuesday, February 14, 2012
Friday, February 10, 2012
Changing credentials on-the-fly
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 englishConsider 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
>|||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
> 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
may
> credentials
> are
the
> old
>
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 englishConsider 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
>|||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
> 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
may
> credentials
> are
the
> old
>
Labels:
apps,
changing,
connect,
credentials,
database,
department,
hii,
microsoft,
mysql,
oledb,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Changing credentials on-the-fly
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 englishConsider 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...
> 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
> >
> >
>|||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...
>> 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
>> >
>> >
>>
>|||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
> 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...
>> 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
>> >
>> >
>>
>
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 englishConsider 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...
> 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
> >
> >
>|||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...
>> 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
>> >
>> >
>>
>|||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
> 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...
>> 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
>> >
>> >
>>
>
Labels:
apps,
changing,
connect,
credentials,
database,
department,
microsoft,
mysql,
ole,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Changing credentials on-the-fly
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 englishConsider 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...
> 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[vbcol=seagreen]
>|||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 eve
ry
> 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
> 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[vbcol=seagreen]
> old
>
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 englishConsider 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...
> 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[vbcol=seagreen]
>|||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 eve
ry
> 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
> 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[vbcol=seagreen]
> old
>
Labels:
apps,
changing,
connect,
credentials,
database,
department,
hii,
microsoft,
mysql,
oledb,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Changing credentials on-the-fly
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
>
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
>
Labels:
apps,
changing,
connect,
credentials,
database,
department,
hii,
microsoft,
mysql,
oledb,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Changing credentials on-the-fly
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
>
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
>
Labels:
apps,
changing,
connect,
credentials,
database,
department,
hii,
microsoft,
mysql,
oledb,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Changing credentials on-the-fly
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
>
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
>
Labels:
apps,
changing,
connect,
credentials,
database,
department,
hii,
microsoft,
mysql,
oledb,
on-the-fly,
oracle,
requirement,
security,
server,
situation,
sql
Changing Credentials for Subscriptions ?
Trying to get e-mail subscriptions working. Suspect problem due to User
being "Network Service" and not having sufficient rights. Not sure how to
change. Both the ReportServer -service-, and the Application Pool I have
setup in IIS (6.0) are running under "Network Service". If I change
credentials on the service to an AD account, nothing bad apparently happens,
but subscriptions still not working. Changing the Identity on the App Pool
causes the site to crash with error "The report server cannot decrypt the
symmetric key used to access sensitive or encrypted data in a report server
database." ... etc. Restoring the original Network Service credentials
restores functionality.
So how do I make changes such that subscriptions will run under a new
account? And is there -any- way to -display- whatever current credentials RS
has in use in various areas? (UserID would suffice - not looking for
password or a security hole here).
Going bananas in Kansas,
JNWhen you change the windows service user you are most likely getting the
same error you see when you change the iis users, only the error only shows
in the service log file. To get around this issue, first use rskeymgmt to
export the symmetric key. Change the user of the windows service and then
user rskeymgmt to import the symmetric key. This will get you running as
the new user. Monitor the ReportServerService<timestamp>.log file to see if
there are any errors reported by the service.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"J Noble" <JNoble@.discussions.microsoft.com> wrote in message
news:D46A1BED-9E9A-4F61-80C6-828C6623E27F@.microsoft.com...
> Trying to get e-mail subscriptions working. Suspect problem due to User
> being "Network Service" and not having sufficient rights. Not sure how to
> change. Both the ReportServer -service-, and the Application Pool I have
> setup in IIS (6.0) are running under "Network Service". If I change
> credentials on the service to an AD account, nothing bad apparently
> happens,
> but subscriptions still not working. Changing the Identity on the App
> Pool
> causes the site to crash with error "The report server cannot decrypt the
> symmetric key used to access sensitive or encrypted data in a report
> server
> database." ... etc. Restoring the original Network Service credentials
> restores functionality.
> So how do I make changes such that subscriptions will run under a new
> account? And is there -any- way to -display- whatever current credentials
> RS
> has in use in various areas? (UserID would suffice - not looking for
> password or a security hole here).
> Going bananas in Kansas,
> JN
>|||Thanks very much, Daniel. That did the trick.
"Daniel Reib [MSFT]" wrote:
> When you change the windows service user you are most likely getting the
> same error you see when you change the iis users, only the error only shows
> in the service log file. To get around this issue, first use rskeymgmt to
> export the symmetric key. Change the user of the windows service and then
> user rskeymgmt to import the symmetric key. This will get you running as
> the new user. Monitor the ReportServerService<timestamp>.log file to see if
> there are any errors reported by the service.
> --
> -Daniel
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "J Noble" <JNoble@.discussions.microsoft.com> wrote in message
> news:D46A1BED-9E9A-4F61-80C6-828C6623E27F@.microsoft.com...
> > Trying to get e-mail subscriptions working. Suspect problem due to User
> > being "Network Service" and not having sufficient rights. Not sure how to
> > change. Both the ReportServer -service-, and the Application Pool I have
> > setup in IIS (6.0) are running under "Network Service". If I change
> > credentials on the service to an AD account, nothing bad apparently
> > happens,
> > but subscriptions still not working. Changing the Identity on the App
> > Pool
> > causes the site to crash with error "The report server cannot decrypt the
> > symmetric key used to access sensitive or encrypted data in a report
> > server
> > database." ... etc. Restoring the original Network Service credentials
> > restores functionality.
> >
> > So how do I make changes such that subscriptions will run under a new
> > account? And is there -any- way to -display- whatever current credentials
> > RS
> > has in use in various areas? (UserID would suffice - not looking for
> > password or a security hole here).
> >
> > Going bananas in Kansas,
> > JN
> >
>
>
being "Network Service" and not having sufficient rights. Not sure how to
change. Both the ReportServer -service-, and the Application Pool I have
setup in IIS (6.0) are running under "Network Service". If I change
credentials on the service to an AD account, nothing bad apparently happens,
but subscriptions still not working. Changing the Identity on the App Pool
causes the site to crash with error "The report server cannot decrypt the
symmetric key used to access sensitive or encrypted data in a report server
database." ... etc. Restoring the original Network Service credentials
restores functionality.
So how do I make changes such that subscriptions will run under a new
account? And is there -any- way to -display- whatever current credentials RS
has in use in various areas? (UserID would suffice - not looking for
password or a security hole here).
Going bananas in Kansas,
JNWhen you change the windows service user you are most likely getting the
same error you see when you change the iis users, only the error only shows
in the service log file. To get around this issue, first use rskeymgmt to
export the symmetric key. Change the user of the windows service and then
user rskeymgmt to import the symmetric key. This will get you running as
the new user. Monitor the ReportServerService<timestamp>.log file to see if
there are any errors reported by the service.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"J Noble" <JNoble@.discussions.microsoft.com> wrote in message
news:D46A1BED-9E9A-4F61-80C6-828C6623E27F@.microsoft.com...
> Trying to get e-mail subscriptions working. Suspect problem due to User
> being "Network Service" and not having sufficient rights. Not sure how to
> change. Both the ReportServer -service-, and the Application Pool I have
> setup in IIS (6.0) are running under "Network Service". If I change
> credentials on the service to an AD account, nothing bad apparently
> happens,
> but subscriptions still not working. Changing the Identity on the App
> Pool
> causes the site to crash with error "The report server cannot decrypt the
> symmetric key used to access sensitive or encrypted data in a report
> server
> database." ... etc. Restoring the original Network Service credentials
> restores functionality.
> So how do I make changes such that subscriptions will run under a new
> account? And is there -any- way to -display- whatever current credentials
> RS
> has in use in various areas? (UserID would suffice - not looking for
> password or a security hole here).
> Going bananas in Kansas,
> JN
>|||Thanks very much, Daniel. That did the trick.
"Daniel Reib [MSFT]" wrote:
> When you change the windows service user you are most likely getting the
> same error you see when you change the iis users, only the error only shows
> in the service log file. To get around this issue, first use rskeymgmt to
> export the symmetric key. Change the user of the windows service and then
> user rskeymgmt to import the symmetric key. This will get you running as
> the new user. Monitor the ReportServerService<timestamp>.log file to see if
> there are any errors reported by the service.
> --
> -Daniel
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "J Noble" <JNoble@.discussions.microsoft.com> wrote in message
> news:D46A1BED-9E9A-4F61-80C6-828C6623E27F@.microsoft.com...
> > Trying to get e-mail subscriptions working. Suspect problem due to User
> > being "Network Service" and not having sufficient rights. Not sure how to
> > change. Both the ReportServer -service-, and the Application Pool I have
> > setup in IIS (6.0) are running under "Network Service". If I change
> > credentials on the service to an AD account, nothing bad apparently
> > happens,
> > but subscriptions still not working. Changing the Identity on the App
> > Pool
> > causes the site to crash with error "The report server cannot decrypt the
> > symmetric key used to access sensitive or encrypted data in a report
> > server
> > database." ... etc. Restoring the original Network Service credentials
> > restores functionality.
> >
> > So how do I make changes such that subscriptions will run under a new
> > account? And is there -any- way to -display- whatever current credentials
> > RS
> > has in use in various areas? (UserID would suffice - not looking for
> > password or a security hole here).
> >
> > Going bananas in Kansas,
> > JN
> >
>
>
Subscribe to:
Posts (Atom)