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]

You said "I've givin the "Domain Users" group full control of the database"

then

"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

http://www.connectionstrings.com

Jeff

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

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.

[Cor Ligthert [MVP]]

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

[Göran Andersson]

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]]

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

[sflynn]

Thanks for the replies guys. I'll clarify my issue a little more.
All users in my domain are members of the "Domain Users", I've even
tried adding the specific user I'm testing with as db_owner of the
database, still nothing happens. When a non-admin user gets to the
line where I declare the SQLConnection, it just seems to stop, and then
the program starts eating up memory (using Task Manager) like crazy. I
let it run once until it used up over 200mb, normally the program only
uses 20mb. The program doesn't error out at all, and I've got that
line encased in a "Try, Catch" statement.

[sflynn]

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]

Also, it works fine for any user on a Windows XP and 2000 workstation,
but not for a regular user on a Windows 2000 Terminal Server.

[Jeff Dillon]

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]

What do you mean "not a database security problem"? Of course it is!

I'm surprised you aren't reading what you are writing. Did you see my first
reply? You've set up the admins as users in the database. That means NO ONE
ELSE can access it!

And that is exactly what you are seeing.

And did you even try my suggestion? Don't use Windows Security. Create a
single SQL user account, and put that in the (single) connection string. I
used to work in the SQL Server group at Microsoft, and wrote a book about
it. Trust me.

If you really need Windows Security, follow these steps:

* Ideally, put all the users you need to have access into a company global
domain group. You might have to ask your IT dept for this.

* Otherwise, create a local group on the SQL box. Then add your users to
this group.

* Then create a SQL login for this group, and give access to the appropriate
database.

However, if you don't need this much security, create a single SQL account
(not a Windows account), and use that single account, and pass the username
and password on the connection string. You may need to go through SQL Server
setup to tell it to use BOTH SQL and Windows authentication

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.