User permission problems. sqlconnection

[sflynn]

I've just created a new program in Visual Studio 2005, Visual Basic.
I can publish, install, and run the program just fine as long as the
user is a member of the "Domain Admins" group. My problem is when a
non-admin using tries to run the program. The program gets hung up on
the following line

Dim cn As System.Data.Sql Client.SqlConne ction = New SqlConnection(" Data
Source=spdb01;I nitial Catalog=SToP;In tegrated Security=True;" )

How can I fix this, or what is the problem. I've been pulling my hair
out over this. I'm sure it's not the permissions on the SQL server,
I've givin the "Domain Users" group full control of the database.

[Jeff Dillon]

Also, just run Query Analyer. Have a non-admin user log onto your
workstation, and have them start up Query Analyzer, and try to connect to
the database. They won't be able to. So it's not in your app, it's in SQL
security.

Jeff

"sflynn" <ss*****@gmail. com> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com.. .

I also just tried passing a username and password to the database. The
admin users are still working, but the others are not. It seems that
the non-admin users don't have permissions to run "Sqlconnection" , it
doesn't seem to be a database security problem, but a system security
problem somewhere.

[sflynn]

I've tried using the non integrated SQL security, and passing the
username and password. On Windows XP/ 2000 workstatiosn it works fine
as both an admin and regular user using integrated and SQL security.
But when a user tries to log in from a Windows 2000 Terminal Server, it
doesn't work. When I make that user a member of the local
Administrators group on the terminal server (not domain admin) it also
works.

[Cor Ligthert [MVP]]

Jeff,

But that is much more dangerous than permitting the domainusers in SQL
server the use of a table in the databaseserver and than to use integrated
security.

Whit what you suppose everybody can use the database. (Which can be in some
circumstances withouth problem ). However here the OP talks about his domain
users.

Cor

"Jeff Dillon" <je********@hot mail.com> schreef in bericht
news:eN******** ******@TK2MSFTN GP02.phx.gbl...

No, just one connection string! Everyone logs under the same SQL account

Jeff

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:uK******** ******@TK2MSFTN GP02.phx.gbl...

And you have to make for every user his own connectionstrin g

Cor

"Göran Andersson" <gu***@guffa.co m> schreef in bericht
news:uT******** ******@TK2MSFTN GP02.phx.gbl...

I believe that Jeff means that a database user account would be easier to
handle than a trusted connection. Just add the user in the datbase and
supply the credentials in the connection string. Then you don't have to
grant access for a lot of windows user accounts to the database.

That also makes it easier to tighten the security. The user account can
be given permission to a single database, and only permission to execute
stored procedures. That would make the connection totally safe against
SQL injections (unless of course a stored procedure creates SQL
dynamically).

Cor Ligthert [MVP] wrote:
Jeff,

In my idea is your first solution enough, if the user has no
permissions, than adding the username/password in the connection string
has as well not sense.

> "My problem is when a non-admin using tries to run the program. "
>
> Ding ding? Non-admin users can't connect to the database, obviously.
> Add them.
>
> Any reason you need Integrated Security on SQL? You could pass a
> username/password in the connection string instead
>

Cor

[Jeff Dillon]

No, actually NOBODY can use the database, except the single logon user

But yes, EVERYBODY who uses the app, can access the database, under that
same account.

But I didn't read carefully enough, he has problems with Terminal Server
users.

Jeff
"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

Jeff,

But that is much more dangerous than permitting the domainusers in SQL
server the use of a table in the databaseserver and than to use integrated
security.

Whit what you suppose everybody can use the database. (Which can be in
some circumstances withouth problem ). However here the OP talks about his
domain users.

Cor

"Jeff Dillon" <je********@hot mail.com> schreef in bericht
news:eN******** ******@TK2MSFTN GP02.phx.gbl...

No, just one connection string! Everyone logs under the same SQL account

Jeff

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:uK******** ******@TK2MSFTN GP02.phx.gbl...

And you have to make for every user his own connectionstrin g

Cor

"Göran Andersson" <gu***@guffa.co m> schreef in bericht
news:uT******** ******@TK2MSFTN GP02.phx.gbl...
I believe that Jeff means that a database user account would be easier
to handle than a trusted connection. Just add the user in the datbase
and supply the credentials in the connection string. Then you don't have
to grant access for a lot of windows user accounts to the database.

That also makes it easier to tighten the security. The user account can
be given permission to a single database, and only permission to
execute stored procedures. That would make the connection totally safe
against SQL injections (unless of course a stored procedure creates SQL
dynamically).

Cor Ligthert [MVP] wrote:
> Jeff,
>
> In my idea is your first solution enough, if the user has no
> permissions, than adding the username/password in the connection
> string has as well not sense.
>
>> "My problem is when a non-admin using tries to run the program. "
>>
>> Ding ding? Non-admin users can't connect to the database, obviously.
>> Add them.
>>
>> Any reason you need Integrated Security on SQL? You could pass a
>> username/password in the connection string instead
>>
>
> Cor
>

[Cor Ligthert [MVP]]

Jeff,

But I didn't read carefully enough, he has problems with Terminal Server
users.

Where, just at his latest replies while this is probably the most relevant
information.

Cor

[Jeff Dillon]

Your point? Don't waste my time

"Cor Ligthert [MVP]" <no************ @planet.nl> wrote in message
news:eW******** *****@TK2MSFTNG P05.phx.gbl...

Jeff,

But I didn't read carefully enough, he has problems with Terminal Server
users.

Where, just at his latest replies while this is probably the most relevant
information.

Cor