"sflynn" <ssfl***@gmail.com> wrote in message
news:1146684074.839301.304280@u72g2000cwu.googlegroups.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.SqlClient.SqlConnection = New SqlConnection("Data
> Source=spdb01;Initial Catalog=SToP;Integrated 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,
>
> 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" <gu***@guffa.com> schreef in bericht
news:uT1M8O1bGHA.5116@TK2MSFTNGP02.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]" <notmyfirstn***@planet.nl> wrote in message
news:uKfmni1bGHA.3824@TK2MSFTNGP02.phx.gbl...
> And you have to make for every user his own connectionstring
>
> Cor
>
> "Göran Andersson" <gu***@guffa.com> schreef in bericht
> news:uT1M8O1bGHA.5116@TK2MSFTNGP02.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" <jeffdil***@hotmail.com> schreef in bericht
news:eNpKB$4bGHA.3824@TK2MSFTNGP02.phx.gbl...
> No, just one connection string! Everyone logs under the same SQL account
>
> Jeff
>
> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
> news:uKfmni1bGHA.3824@TK2MSFTNGP02.phx.gbl...
>> And you have to make for every user his own connectionstring
>>
>> Cor
>>
>> "Göran Andersson" <gu***@guffa.com> schreef in bericht
>> news:uT1M8O1bGHA.5116@TK2MSFTNGP02.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]" <notmyfirstn***@planet.nl> wrote in message
news:%23HpDqG6bGHA.4900@TK2MSFTNGP02.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" <jeffdil***@hotmail.com> schreef in bericht
> news:eNpKB$4bGHA.3824@TK2MSFTNGP02.phx.gbl...
>> No, just one connection string! Everyone logs under the same SQL account
>>
>> Jeff
>>
>> "Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
>> news:uKfmni1bGHA.3824@TK2MSFTNGP02.phx.gbl...
>>> And you have to make for every user his own connectionstring
>>>
>>> Cor
>>>
>>> "Göran Andersson" <gu***@guffa.com> schreef in bericht
>>> news:uT1M8O1bGHA.5116@TK2MSFTNGP02.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]" <notmyfirstn***@planet.nl> wrote in message
news:eW0$FdAcGHA.636@TK2MSFTNGP05.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
>