Showing posts with label logging. Show all posts
Showing posts with label logging. Show all posts

Monday, March 26, 2012

Long blocked transaction logging

Is there anyone know any feature in SQL server which can detect/log the transaction which has been blocked unusually long? My idea is:

If a transaction has run for over 30 minutes, then log the following information in SQL server log:

1. State of the transaction : Blocked, Running, Sleeping

2. Time happeing

3. Duration

4. Last SQL it run

5. Blocked by which thread and info of the thread : the last SQL it run, the state of the thread.

Possibly it would be run in SQL server agent or SQL profiler has such feature, I am not sure about it. Can anyone suggest? Thanks.

If you are using SQL 2005, refer to the usage of the dynamic management view sys.dm_tran_active_transactions in Books Online.

For SQL 2000, this article may help:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q271509

|||

Thanks Arnie, I am using 2005 and this link is helpful:

http://msdn2.microsoft.com/en-us/library/ms191168.aspx

It provides the infomation of the Blocked Process Report Event Class object

Long blocked transaction logging

Is there anyone know any feature in SQL server which can detect/log the transaction which has been blocked unusually long? My idea is:

If a transaction has run for over 30 minutes, then log the following information in SQL server log:

1. State of the transaction : Blocked, Running, Sleeping

2. Time happeing

3. Duration

4. Last SQL it run

5. Blocked by which thread and info of the thread : the last SQL it run, the state of the thread.

Possibly it would be run in SQL server agent or SQL profiler has such feature, I am not sure about it. Can anyone suggest? Thanks.

If you are using SQL 2005, refer to the usage of the dynamic management view sys.dm_tran_active_transactions in Books Online.

For SQL 2000, this article may help:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q271509

|||

Thanks Arnie, I am using 2005 and this link is helpful:

http://msdn2.microsoft.com/en-us/library/ms191168.aspx

It provides the infomation of the Blocked Process Report Event Class object

Monday, March 19, 2012

Logon prompts twice

Any idea why the logon prompts again when clicking on a report after
succesfully logging into the reporting services the first time? The report
opens with no problem. I am using Windows Server 2003, SQL Server 2000
Standard Edition, and IIS 6. Thanks.
FabianStill looking for a solution to this problem with no luck so far. Here is
some additional information that might help pinpoint the problem.
The title of the first logon window is "Connect to www.mywebsite.com" while
the title of the second logon window is "Connect to ServerName"
Any suggestions on how to fix this?
"Fabian Cevallos" <fcevallos@.bellsouth.net> wrote in message
news:ufXbp1w3EHA.2788@.TK2MSFTNGP15.phx.gbl...
> Any idea why the logon prompts again when clicking on a report after
> succesfully logging into the reporting services the first time? The report
> opens with no problem. I am using Windows Server 2003, SQL Server 2000
> Standard Edition, and IIS 6. Thanks.
> Fabian
>|||You need to change the server name in your *.config files (search through
your RS installation folders) to a fully qualified domain name (FQDN). The
authentication cookies aren't crossing domain names.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Fabian Cevallos" <fcevallos@.bellsouth.net> wrote in message
news:OgClS%2373EHA.1260@.TK2MSFTNGP12.phx.gbl...
> Still looking for a solution to this problem with no luck so far. Here is
> some additional information that might help pinpoint the problem.
>
> The title of the first logon window is "Connect to www.mywebsite.com"
> while the title of the second logon window is "Connect to ServerName"
>
> Any suggestions on how to fix this?
>
> "Fabian Cevallos" <fcevallos@.bellsouth.net> wrote in message
> news:ufXbp1w3EHA.2788@.TK2MSFTNGP15.phx.gbl...
>> Any idea why the logon prompts again when clicking on a report after
>> succesfully logging into the reporting services the first time? The
>> report opens with no problem. I am using Windows Server 2003, SQL Server
>> 2000 Standard Edition, and IIS 6. Thanks.
>> Fabian
>|||Thanks Jeff.
It is fixed!
I modified the RSWebApplication.config located at: C:\Program
Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer
From: <ReportServerUrl>Server/ReportServer</ReportServerUrl>
To:
<ReportServerUrl>http://www.mywebsite.com/ReportServer</ReportServerUrl>
Fabian Cevallos
"Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
news:%235GqrOU4EHA.2192@.TK2MSFTNGP14.phx.gbl...
> You need to change the server name in your *.config files (search through
> your RS installation folders) to a fully qualified domain name (FQDN).
> The authentication cookies aren't crossing domain names.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "Fabian Cevallos" <fcevallos@.bellsouth.net> wrote in message
> news:OgClS%2373EHA.1260@.TK2MSFTNGP12.phx.gbl...
>> Still looking for a solution to this problem with no luck so far. Here
>> is some additional information that might help pinpoint the problem.
>>
>> The title of the first logon window is "Connect to www.mywebsite.com"
>> while the title of the second logon window is "Connect to ServerName"
>>
>> Any suggestions on how to fix this?
>>
>> "Fabian Cevallos" <fcevallos@.bellsouth.net> wrote in message
>> news:ufXbp1w3EHA.2788@.TK2MSFTNGP15.phx.gbl...
>> Any idea why the logon prompts again when clicking on a report after
>> succesfully logging into the reporting services the first time? The
>> report opens with no problem. I am using Windows Server 2003, SQL
>> Server 2000 Standard Edition, and IIS 6. Thanks.
>> Fabian
>>
>

Wednesday, March 7, 2012

Login user name

Hi,
can it be a problem for SQL if I have 41 users using the same logging name ?
tx
hi
No as far it is not a admin account.
from
DOller
|||Technically it should work. In reality you've lost all control. What
happens if you decide to disable one user account? You will disable all 41
users. What if you want 5 users to have access to a new database, but not
the other users? You're giving an all-or-none proposition here. Or if
someone logs into your database when they're not supposed to, or does
something verboten while in there? Well, you can narrow the problem down to
41 people. How do you handle that? Fire them all?
It's better to give each user his/her own login. Look into Windows
Authenticated security in BOL.
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:ufUia5MuFHA.2540@.TK2MSFTNGP09.phx.gbl...
> Hi,
>
> can it be a problem for SQL if I have 41 users using the same logging name
> ?
> tx
>
|||To add to Michael's reply:
Using a Windows Group would be the best case scenario here for account
managment, minimizing the number of total logins and the ability to
determine the Windows User name for the user in the Windows Group using
SUSER_SNAME().
HTH
Jerry
"Michael C#" <xyz@.abcdef.com> wrote in message
news:%OLVe.372$gE7.314@.fe08.lga...
> Technically it should work. In reality you've lost all control. What
> happens if you decide to disable one user account? You will disable all
> 41 users. What if you want 5 users to have access to a new database, but
> not the other users? You're giving an all-or-none proposition here. Or
> if someone logs into your database when they're not supposed to, or does
> something verboten while in there? Well, you can narrow the problem down
> to 41 people. How do you handle that? Fire them all?
> It's better to give each user his/her own login. Look into Windows
> Authenticated security in BOL.
> "ms" <nowayyyy@.nospammmm.fr> wrote in message
> news:ufUia5MuFHA.2540@.TK2MSFTNGP09.phx.gbl...
>
|||The only reason why they are using their computers is to use the same
database and do exactly the same job (surveyer, only for 2 months). So if
its not a problem for SQL Server, I dont see any reason to create 41 user
names.
tx all
(they already have their own user name in the survey application that
connect to my SQL Server btw, they only use the same logging name for
Windows XP.)
|||It's always your choice, but when management wants to know who did what in
your database; or wants a certain user locked out, what are you going to
tell them? "I have it narrowed down to one of 41 people?" Or "I can't lock
one person out without locking them all out".
As always, how you manage - or mis-manage - your SQL Server is completely up
to you.
Best of luck
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:O13cSvXuFHA.3500@.TK2MSFTNGP09.phx.gbl...
> The only reason why they are using their computers is to use the same
> database and do exactly the same job (surveyer, only for 2 months). So if
> its not a problem for SQL Server, I dont see any reason to create 41 user
> names.
> tx all
> (they already have their own user name in the survey application that
> connect to my SQL Server btw, they only use the same logging name for
> Windows XP.)
>
|||"Michael C#" <xyz@.abcdef.com> a crit dans le message de
news:Fi2Xe.7570$IC3.7538@.fe12.lga...
> It's always your choice, but when management wants to know who did what in
> your database; or wants a certain user locked out, what are you going to
> tell them? "I have it narrowed down to one of 41 people?" Or "I can't
lock
> one person out without locking them all out".
why I would lock someone ? If I dont want him to use the database, its
because he is not working for me anymore. And like I said, the application
connecting to my db is already using 41 different surveyer names.
tx for your infos anyway !
|||No problem. Those were just a couple of examples. As long as you're aware
that situations do pop up now and then where the granularity of your
security can be very important.
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:ePNZpjJvFHA.2008@.TK2MSFTNGP10.phx.gbl...
> "Michael C#" <xyz@.abcdef.com> a crit dans le message de
> news:Fi2Xe.7570$IC3.7538@.fe12.lga...
> lock
> why I would lock someone ? If I dont want him to use the database, its
> because he is not working for me anymore. And like I said, the application
> connecting to my db is already using 41 different surveyer names.
> tx for your infos anyway !
>

Login user name

Hi,
can it be a problem for SQL if I have 41 users using the same logging name ?
txhi
No as far it is not a admin account.
from
DOller|||Technically it should work. In reality you've lost all control. What
happens if you decide to disable one user account? You will disable all 41
users. What if you want 5 users to have access to a new database, but not
the other users? You're giving an all-or-none proposition here. Or if
someone logs into your database when they're not supposed to, or does
something verboten while in there? Well, you can narrow the problem down to
41 people. How do you handle that? Fire them all?
It's better to give each user his/her own login. Look into Windows
Authenticated security in BOL.
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:ufUia5MuFHA.2540@.TK2MSFTNGP09.phx.gbl...
> Hi,
>
> can it be a problem for SQL if I have 41 users using the same logging name
> ?
> tx
>|||To add to Michael's reply:
Using a Windows Group would be the best case scenario here for account
managment, minimizing the number of total logins and the ability to
determine the Windows User name for the user in the Windows Group using
SUSER_SNAME().
HTH
Jerry
"Michael C#" <xyz@.abcdef.com> wrote in message
news:%OLVe.372$gE7.314@.fe08.lga...
> Technically it should work. In reality you've lost all control. What
> happens if you decide to disable one user account? You will disable all
> 41 users. What if you want 5 users to have access to a new database, but
> not the other users? You're giving an all-or-none proposition here. Or
> if someone logs into your database when they're not supposed to, or does
> something verboten while in there? Well, you can narrow the problem down
> to 41 people. How do you handle that? Fire them all?
> It's better to give each user his/her own login. Look into Windows
> Authenticated security in BOL.
> "ms" <nowayyyy@.nospammmm.fr> wrote in message
> news:ufUia5MuFHA.2540@.TK2MSFTNGP09.phx.gbl...
>> Hi,
>>
>> can it be a problem for SQL if I have 41 users using the same logging
>> name ?
>> tx
>>
>|||The only reason why they are using their computers is to use the same
database and do exactly the same job (surveyer, only for 2 months). So if
its not a problem for SQL Server, I dont see any reason to create 41 user
names.
tx all
(they already have their own user name in the survey application that
connect to my SQL Server btw, they only use the same logging name for
Windows XP.)|||It's always your choice, but when management wants to know who did what in
your database; or wants a certain user locked out, what are you going to
tell them? "I have it narrowed down to one of 41 people?" Or "I can't lock
one person out without locking them all out".
As always, how you manage - or mis-manage - your SQL Server is completely up
to you.
Best of luck
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:O13cSvXuFHA.3500@.TK2MSFTNGP09.phx.gbl...
> The only reason why they are using their computers is to use the same
> database and do exactly the same job (surveyer, only for 2 months). So if
> its not a problem for SQL Server, I dont see any reason to create 41 user
> names.
> tx all
> (they already have their own user name in the survey application that
> connect to my SQL Server btw, they only use the same logging name for
> Windows XP.)
>|||"Michael C#" <xyz@.abcdef.com> a écrit dans le message de
news:Fi2Xe.7570$IC3.7538@.fe12.lga...
> It's always your choice, but when management wants to know who did what in
> your database; or wants a certain user locked out, what are you going to
> tell them? "I have it narrowed down to one of 41 people?" Or "I can't
lock
> one person out without locking them all out".
why I would lock someone ? If I dont want him to use the database, its
because he is not working for me anymore. And like I said, the application
connecting to my db is already using 41 different surveyer names.
tx for your infos anyway !|||No problem. Those were just a couple of examples. As long as you're aware
that situations do pop up now and then where the granularity of your
security can be very important.
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:ePNZpjJvFHA.2008@.TK2MSFTNGP10.phx.gbl...
> "Michael C#" <xyz@.abcdef.com> a écrit dans le message de
> news:Fi2Xe.7570$IC3.7538@.fe12.lga...
>> It's always your choice, but when management wants to know who did what
>> in
>> your database; or wants a certain user locked out, what are you going to
>> tell them? "I have it narrowed down to one of 41 people?" Or "I can't
> lock
>> one person out without locking them all out".
> why I would lock someone ? If I dont want him to use the database, its
> because he is not working for me anymore. And like I said, the application
> connecting to my db is already using 41 different surveyer names.
> tx for your infos anyway !
>

Login user name

Hi,
can it be a problem for SQL if I have 41 users using the same logging name ?
txhi
No as far it is not a admin account.
from
DOller|||Technically it should work. In reality you've lost all control. What
happens if you decide to disable one user account? You will disable all 41
users. What if you want 5 users to have access to a new database, but not
the other users? You're giving an all-or-none proposition here. Or if
someone logs into your database when they're not supposed to, or does
something verboten while in there? Well, you can narrow the problem down to
41 people. How do you handle that? Fire them all?
It's better to give each user his/her own login. Look into Windows
Authenticated security in BOL.
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:ufUia5MuFHA.2540@.TK2MSFTNGP09.phx.gbl...
> Hi,
>
> can it be a problem for SQL if I have 41 users using the same logging name
> ?
> tx
>|||To add to Michael's reply:
Using a Windows Group would be the best case scenario here for account
managment, minimizing the number of total logins and the ability to
determine the Windows User name for the user in the Windows Group using
SUSER_SNAME().
HTH
Jerry
"Michael C#" <xyz@.abcdef.com> wrote in message
news:%OLVe.372$gE7.314@.fe08.lga...
> Technically it should work. In reality you've lost all control. What
> happens if you decide to disable one user account? You will disable all
> 41 users. What if you want 5 users to have access to a new database, but
> not the other users? You're giving an all-or-none proposition here. Or
> if someone logs into your database when they're not supposed to, or does
> something verboten while in there? Well, you can narrow the problem down
> to 41 people. How do you handle that? Fire them all?
> It's better to give each user his/her own login. Look into Windows
> Authenticated security in BOL.
> "ms" <nowayyyy@.nospammmm.fr> wrote in message
> news:ufUia5MuFHA.2540@.TK2MSFTNGP09.phx.gbl...
>|||The only reason why they are using their computers is to use the same
database and do exactly the same job (surveyer, only for 2 months). So if
its not a problem for SQL Server, I dont see any reason to create 41 user
names.
tx all
(they already have their own user name in the survey application that
connect to my SQL Server btw, they only use the same logging name for
Windows XP.)|||It's always your choice, but when management wants to know who did what in
your database; or wants a certain user locked out, what are you going to
tell them? "I have it narrowed down to one of 41 people?" Or "I can't lock
one person out without locking them all out".
As always, how you manage - or mis-manage - your SQL Server is completely up
to you.
Best of luck
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:O13cSvXuFHA.3500@.TK2MSFTNGP09.phx.gbl...
> The only reason why they are using their computers is to use the same
> database and do exactly the same job (surveyer, only for 2 months). So if
> its not a problem for SQL Server, I dont see any reason to create 41 user
> names.
> tx all
> (they already have their own user name in the survey application that
> connect to my SQL Server btw, they only use the same logging name for
> Windows XP.)
>|||"Michael C#" <xyz@.abcdef.com> a crit dans le message de
news:Fi2Xe.7570$IC3.7538@.fe12.lga...
> It's always your choice, but when management wants to know who did what in
> your database; or wants a certain user locked out, what are you going to
> tell them? "I have it narrowed down to one of 41 people?" Or "I can't
lock
> one person out without locking them all out".
why I would lock someone ? If I dont want him to use the database, its
because he is not working for me anymore. And like I said, the application
connecting to my db is already using 41 different surveyer names.
tx for your infos anyway !|||No problem. Those were just a couple of examples. As long as you're aware
that situations do pop up now and then where the granularity of your
security can be very important.
"ms" <nowayyyy@.nospammmm.fr> wrote in message
news:ePNZpjJvFHA.2008@.TK2MSFTNGP10.phx.gbl...
> "Michael C#" <xyz@.abcdef.com> a crit dans le message de
> news:Fi2Xe.7570$IC3.7538@.fe12.lga...
> lock
> why I would lock someone ? If I dont want him to use the database, its
> because he is not working for me anymore. And like I said, the application
> connecting to my db is already using 41 different surveyer names.
> tx for your infos anyway !
>

Login to MSDE on Win 98

Hi all,

I have the the problem with logging to MSDE using SQL-DMO interface. On the
W2K with LoginSecure=TRUE everything is OK (connect is made without any
parameters)

But when LoginSecure=FALSE (on Win 98)

connect( 'instance_name', 'sa', 'sa_password' )

then it returns error message :

Login failed for user 'sa'. Reason : Not associated with a trusted SQL

I install MSDE on Win 98 with parameters :

INSTANCENAME='instance_name'
SECURITYMODE=SQL
SAPWD='sa_password'

Server runs with given instance name.

Who knows why I can not login to MSDE ?

TIA,

Marek Powichrowski"Marek Powichrowski" <marekp@.telbank.pl> wrote in message
news:bv81ss$hnp$1@.korweta.task.gda.pl...
> Hi all,
> I have the the problem with logging to MSDE using SQL-DMO interface. On
the
> W2K with LoginSecure=TRUE everything is OK (connect is made without any
> parameters)
> But when LoginSecure=FALSE (on Win 98)
> connect( 'instance_name', 'sa', 'sa_password' )
> then it returns error message :
> Login failed for user 'sa'. Reason : Not associated with a trusted SQL
> I install MSDE on Win 98 with parameters :
> INSTANCENAME='instance_name'
> SECURITYMODE=SQL
> SAPWD='sa_password'
> Server runs with given instance name.
> Who knows why I can not login to MSDE ?
> TIA,
> Marek Powichrowski

The error is slightly strange, since it suggests MSDE is running in Windows
authentication mode, however that isn't supported on Windows 98. Can you
connect to the MSDE instance locally using osql, for example?

osql -S instance_name -U sa -P sa_password

If you can connect like this, then the issue is probably somewhere in your
SQLDMO code, and perhaps you could post the part which makes the connection.
If this doesn't work, then could you post the error message? And did you
install the latest MSDE version, ie. SP3a?

Simon|||>
> The error is slightly strange, since it suggests MSDE is running in
Windows
> authentication mode, however that isn't supported on Windows 98. Can you
> connect to the MSDE instance locally using osql, for example?
> osql -S instance_name -U sa -P sa_password
> If you can connect like this, then the issue is probably somewhere in your
> SQLDMO code, and perhaps you could post the part which makes the
connection.
> If this doesn't work, then could you post the error message? And did you
> install the latest MSDE version, ie. SP3a?

Cause of error was setting LoginSecure to TRUE for the connection made on
the Win 98. When I change LoginSecure to FALSE then connection ends
succesfully (for proper server name user name and password) . So I can
create database using script generated by Enterprise Manager from my
computer and can atatch existing database to MSDE without Enterprise Manager
in the easy way (few lines of code).

Thanks for your support.

Marek Powichrowski

Login to MSDE

Hi all,
I have the the problem with logging to MSDE using SQL-DMO interface. On the
W2K with LoginSecure=TRUE everything is OK (connect is made without any
parameters)
But when LoginSecure=FALSE
connect( 'instance_name', 'sa', 'sa_password' )
it returns error message :
Login failed for user 'sa'. Reason : Not associated with a trusted SQL
I install MSDE Win 98 with parameters :
INSTANCENAME='instance_name'
SECURITYMODE=SQL
SAPWD='sa_password'
Server runs with given instance name.
Who knows why I can not login to MSDE ?
TIA,
Marek PowichrowskiCheck out article 319930, especially the section entitled:
Enable Mixed Mode Authentication After Installation
to verify that MSDE is in fact running in mixed mode.
Rand
This posting is provided "as is" with no warranties and confers no rights.|||Uytkownik "Rand Boyd [MSFT]" <rboyd@.onlinemicrosoft.com> napisa w
wiadomoci news:KWta2ad5DHA.824@.cpmsftngxa07.phx.gbl...
quote:

> Check out article 319930, especially the section entitled:
> Enable Mixed Mode Authentication After Installation
> to verify that MSDE is in fact running in mixed mode.
> Rand
> This posting is provided "as is" with no warranties and confers no rights.
>

Thanks for your support.
Marek Powichrowski

Login to a SQL Server 2000 database keeps failing

Hello,
On my system (XP professional),I have no problem logging to all of my
databases (SQL Server 2000) using "sa" or any of the other logins that I had
created and gave them database access.
However, on this other system (XP professional and SQL Server 2000) I keep
getting the following error:
Java.sql.SQLException: []Login failed for user â'saâ'. Reason: Not associatied
with a trusted SQL Server connection.
I will get the same error if I create and use new logins that were given
access to the databases. I had never seen this particular error message.
Please help!
Thanks,
--
MitraPerhaps this SQL Server is configured to allow only Windows authentication.
To connect with SQL logins, you need to change the server's authentication
mode to SQL Server and Windows and restart SQL Server. You can do this from
the Security tab under Enterprise Manager server properties.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"mitra" <mitra@.discussions.microsoft.com> wrote in message
news:42CDF6EC-8DCD-46BE-96A3-CEE02C498284@.microsoft.com...
> Hello,
> On my system (XP professional),I have no problem logging to all of my
> databases (SQL Server 2000) using "sa" or any of the other logins that I
> had
> created and gave them database access.
> However, on this other system (XP professional and SQL Server 2000) I keep
> getting the following error:
> Java.sql.SQLException: []Login failed for user 'sa'. Reason: Not
> associatied
> with a trusted SQL Server connection.
> I will get the same error if I create and use new logins that were given
> access to the databases. I had never seen this particular error message.
> Please help!
> Thanks,
> --
> Mitra|||Mitra,
How are you logging into your DBs -- it looks like from an application? Have
you tried creating a DSN entry using the same credentials? My guess is that
your application is trying to logon sa as a domain account not as a SQL
native account.
Tea C.
"mitra" wrote:
> Hello,
> On my system (XP professional),I have no problem logging to all of my
> databases (SQL Server 2000) using "sa" or any of the other logins that I had
> created and gave them database access.
> However, on this other system (XP professional and SQL Server 2000) I keep
> getting the following error:
> Java.sql.SQLException: []Login failed for user â'saâ'. Reason: Not associatied
> with a trusted SQL Server connection.
> I will get the same error if I create and use new logins that were given
> access to the databases. I had never seen this particular error message.
> Please help!
> Thanks,
> --
> Mitra

Login to a SQL Server 2000 database keeps failing

Hello,
On my system (XP professional),I have no problem logging to all of my
databases (SQL Server 2000) using "sa" or any of the other logins that I had
created and gave them database access.
However, on this other system (XP professional and SQL Server 2000) I keep
getting the following error:
Java.sql.SQLException: []Login failed for user ‘sa’. Reason: Not associatied
with a trusted SQL Server connection.
I will get the same error if I create and use new logins that were given
access to the databases. I had never seen this particular error message.
Please help!
Thanks,
Mitra
Perhaps this SQL Server is configured to allow only Windows authentication.
To connect with SQL logins, you need to change the server's authentication
mode to SQL Server and Windows and restart SQL Server. You can do this from
the Security tab under Enterprise Manager server properties.
Hope this helps.
Dan Guzman
SQL Server MVP
"mitra" <mitra@.discussions.microsoft.com> wrote in message
news:42CDF6EC-8DCD-46BE-96A3-CEE02C498284@.microsoft.com...
> Hello,
> On my system (XP professional),I have no problem logging to all of my
> databases (SQL Server 2000) using "sa" or any of the other logins that I
> had
> created and gave them database access.
> However, on this other system (XP professional and SQL Server 2000) I keep
> getting the following error:
> Java.sql.SQLException: []Login failed for user 'sa'. Reason: Not
> associatied
> with a trusted SQL Server connection.
> I will get the same error if I create and use new logins that were given
> access to the databases. I had never seen this particular error message.
> Please help!
> Thanks,
> --
> Mitra
|||Mitra,
How are you logging into your DBs -- it looks like from an application? Have
you tried creating a DSN entry using the same credentials? My guess is that
your application is trying to logon sa as a domain account not as a SQL
native account.
Tea C.
"mitra" wrote:

> Hello,
> On my system (XP professional),I have no problem logging to all of my
> databases (SQL Server 2000) using "sa" or any of the other logins that I had
> created and gave them database access.
> However, on this other system (XP professional and SQL Server 2000) I keep
> getting the following error:
> Java.sql.SQLException: []Login failed for user ‘sa’. Reason: Not associatied
> with a trusted SQL Server connection.
> I will get the same error if I create and use new logins that were given
> access to the databases. I had never seen this particular error message.
> Please help!
> Thanks,
> --
> Mitra

Login to a SQL Server 2000 database keeps failing

Hello,
On my system (XP professional),I have no problem logging to all of my
databases (SQL Server 2000) using "sa" or any of the other logins that I had
created and gave them database access.
However, on this other system (XP professional and SQL Server 2000) I keep
getting the following error:
Java.sql.SQLException: []Login failed for user ‘sa’. Reason: Not XXX
ociatied
with a trusted SQL Server connection.
I will get the same error if I create and use new logins that were given
access to the databases. I had never seen this particular error message.
Please help!
Thanks,
--
MitraPerhaps this SQL Server is configured to allow only Windows authentication.
To connect with SQL logins, you need to change the server's authentication
mode to SQL Server and Windows and restart SQL Server. You can do this from
the Security tab under Enterprise Manager server properties.
Hope this helps.
Dan Guzman
SQL Server MVP
"mitra" <mitra@.discussions.microsoft.com> wrote in message
news:42CDF6EC-8DCD-46BE-96A3-CEE02C498284@.microsoft.com...
> Hello,
> On my system (XP professional),I have no problem logging to all of my
> databases (SQL Server 2000) using "sa" or any of the other logins that I
> had
> created and gave them database access.
> However, on this other system (XP professional and SQL Server 2000) I keep
> getting the following error:
> Java.sql.SQLException: []Login failed for user 'sa'. Reason: Not
> associatied
> with a trusted SQL Server connection.
> I will get the same error if I create and use new logins that were given
> access to the databases. I had never seen this particular error message.
> Please help!
> Thanks,
> --
> Mitra|||Mitra,
How are you logging into your DBs -- it looks like from an application? Have
you tried creating a DSN entry using the same credentials? My guess is that
your application is trying to logon sa as a domain account not as a SQL
native account.
Tea C.
"mitra" wrote:

> Hello,
> On my system (XP professional),I have no problem logging to all of my
> databases (SQL Server 2000) using "sa" or any of the other logins that I h
ad
> created and gave them database access.
> However, on this other system (XP professional and SQL Server 2000) I keep
> getting the following error:
> Java.sql.SQLException: []Login failed for user ‘sa’. Reason: Not a
ssociatied
> with a trusted SQL Server connection.
> I will get the same error if I create and use new logins that were given
> access to the databases. I had never seen this particular error message.
> Please help!
> Thanks,
> --
> Mitra

Friday, February 24, 2012

login security question

Hi,
I have an application which connects to the SQL server. We have several users logging into this application. All of their user-id, passwords are validated and converted to an owner profile, which is then used throughout the application.
My problem is, this owner profile should be prevented from accessing the database directly using Enterprise Manager or Query Analyser. The database should be accessible only from the application for this owner/global profile.
How do I go about achieving this. The application was set up like this by a person long time back who is not with us anymore. Also, I do not know SQL Server Administration. So, please detail out what information I have to look up and what steps I will hav
e to follow.
Thank you in advance.
Sunny
Look into SQL Server Books online for "application roles" topic. This
explains about how to create and activate an application role within your
program and use it. This may require some code changes.
HTH
Prasad Koukuntla
"Sunanda" <Sunny@.discussions.microsoft.com> wrote in message
news:87CB3205-C041-4F23-AC6E-7BF23E7AB2C6@.microsoft.com...
> Hi,
> I have an application which connects to the SQL server. We have several
users logging into this application. All of their user-id, passwords are
validated and converted to an owner profile, which is then used throughout
the application.
> My problem is, this owner profile should be prevented from accessing the
database directly using Enterprise Manager or Query Analyser. The database
should be accessible only from the application for this owner/global
profile.
> How do I go about achieving this. The application was set up like this by
a person long time back who is not with us anymore. Also, I do not know SQL
Server Administration. So, please detail out what information I have to look
up and what steps I will have to follow.
> Thank you in advance.
> Sunny
|||In my opinion, that does not seem possible. SQL doesn't know what CLIENT TOOL is touching it. If the "connection" from the client application comes in through a username/password, then that username/password has access to SELECT, UPDATE, DELETE, etc fro
m tables.
That is why we do all our database access through STORED PROCEDURES - so actual table access is not possible. Granted, the users can still call STORED PROCEDURES from the EM and QA tools, but that is less likely to happen.
Can you hide the "connection" username/password from the users?
"Sunanda" wrote:

> Hi,
> I have an application which connects to the SQL server. We have several users logging into this application. All of their user-id, passwords are validated and converted to an owner profile, which is then used throughout the application.
> My problem is, this owner profile should be prevented from accessing the database directly using Enterprise Manager or Query Analyser. The database should be accessible only from the application for this owner/global profile.
> How do I go about achieving this. The application was set up like this by a person long time back who is not with us anymore. Also, I do not know SQL Server Administration. So, please detail out what information I have to look up and what steps I will h
ave to follow.
> Thank you in advance.
> Sunny
|||Steve,
No the connection profile is alreay know to the users, that is why we would like to prevent users from using that in the enterprise manager to make changes.
Please let me know if there are any options.
Thanks a lot.
Sunny
"Steve Z" wrote:

> In my opinion, that does not seem possible. SQL doesn't know what CLIENT TOOL is touching it. If the "connection" from the client application comes in through a username/password, then that username/password has access to SELECT, UPDATE, DELETE, etc f
rom tables.[vbcol=seagreen]
> That is why we do all our database access through STORED PROCEDURES - so actual table access is not possible. Granted, the users can still call STORED PROCEDURES from the EM and QA tools, but that is less likely to happen.
> Can you hide the "connection" username/password from the users?
> "Sunanda" wrote:
have to follow.[vbcol=seagreen]
|||"Sunanda" <Sunny@.discussions.microsoft.com> wrote in message
news:87CB3205-C041-4F23-AC6E-7BF23E7AB2C6@.microsoft.com...
> Hi,
> I have an application which connects to the SQL server. We have several
users logging into this application. All of their user-id, passwords are
validated and converted to an owner profile, which is then used throughout
the application.
> My problem is, this owner profile should be prevented from accessing the
database directly using Enterprise Manager or Query Analyser. The database
should be accessible only from the application for this owner/global
profile.
> How do I go about achieving this. The application was set up like this by
a person long time back who is not with us anymore. Also, I do not know SQL
Server Administration. So, please detail out what information I have to look
up and what steps I will have to follow.
If you can alter the code in the client application, you can use application
roles.
1) Use Enterprise Manager to access the database / roles. New Role. click
the Application Role radio button and give it a nice secure, obscure
password.
2) Give the Application Role the appropriate permissions.
3) Revoke the users' permissions
4) in the code of the application, put in a call to a stored procedure
called (I think, from memory) sp_setAppRole (F1 for application role to see
what the stored proc is called) using the secret password for the App Role
(which you don't share with the end users).
Now your users will have the appropriate permissions when using your app,
but not when using QA or any other app.
On an entirely different tack, you can try Group Policies. Use a GP to tie
down their desktop so that they are not allowed to run Quey Analyzer or
Enterprise Manager.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.711 / Virus Database: 467 - Release Date: 25/06/2004
|||Bob,
Thanks for your reply. I kinda understand this Application Role approach. Could you please explain the following:
1. Say the password for the Application role is found, can a user access the database through the Query Analyser or Enterprise Manager using the application rolde/password.
2. At present the application tracks the user who makes the changes to the database through the application. The application passes the userid to the stored procedures. But if I put in a Applciation role in between, will I still have the actual userid to
track who actually did the inserts and updates through the front-end.
Thanks in advance,
Sunanda.
"Bob Simms" wrote:

> "Sunanda" <Sunny@.discussions.microsoft.com> wrote in message
> news:87CB3205-C041-4F23-AC6E-7BF23E7AB2C6@.microsoft.com...
> users logging into this application. All of their user-id, passwords are
> validated and converted to an owner profile, which is then used throughout
> the application.
> database directly using Enterprise Manager or Query Analyser. The database
> should be accessible only from the application for this owner/global
> profile.
> a person long time back who is not with us anymore. Also, I do not know SQL
> Server Administration. So, please detail out what information I have to look
> up and what steps I will have to follow.
> If you can alter the code in the client application, you can use application
> roles.
> 1) Use Enterprise Manager to access the database / roles. New Role. click
> the Application Role radio button and give it a nice secure, obscure
> password.
> 2) Give the Application Role the appropriate permissions.
> 3) Revoke the users' permissions
> 4) in the code of the application, put in a call to a stored procedure
> called (I think, from memory) sp_setAppRole (F1 for application role to see
> what the stored proc is called) using the secret password for the App Role
> (which you don't share with the end users).
> Now your users will have the appropriate permissions when using your app,
> but not when using QA or any other app.
> On an entirely different tack, you can try Group Policies. Use a GP to tie
> down their desktop so that they are not allowed to run Quey Analyzer or
> Enterprise Manager.
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.711 / Virus Database: 467 - Release Date: 25/06/2004
>
>
|||<<1. Say the password for the Application role is found, can a user access the database through the
Query Analyser or Enterprise Manager using the application rolde/password.>>
Yes.
<<2. At present the application tracks the user who makes the changes to the database through the
application. The application passes the userid to the stored procedures. But if I put in a
Applciation role in between, will I still have the actual userid to track who actually did the
inserts and updates through the front-end.>>
Yes. You can see the login id for the users, and you can use the SYSTEM_USER function in, for
example, a trigger to get the login name. The user name, however, will be the app role name.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sunanda" <Sunanda@.discussions.microsoft.com> wrote in message
news:00D6F5D5-0BC3-43A4-A313-649B5E2E215C@.microsoft.com...
> Bob,
> Thanks for your reply. I kinda understand this Application Role approach. Could you please explain
the following:
> 1. Say the password for the Application role is found, can a user access the database through the
Query Analyser or Enterprise Manager using the application rolde/password.
> 2. At present the application tracks the user who makes the changes to the database through the
application. The application passes the userid to the stored procedures. But if I put in a
Applciation role in between, will I still have the actual userid to track who actually did the
inserts and updates through the front-end.[vbcol=seagreen]
> Thanks in advance,
> Sunanda.
>
> "Bob Simms" wrote:
|||Thanks for your reply.
But can't the application role be restricted from using the QA/EM? This is not a completely secure method. Is there any alternative.
Thanks,
sunanda.
"Tibor Karaszi" wrote:

> <<1. Say the password for the Application role is found, can a user access the database through the
> Query Analyser or Enterprise Manager using the application rolde/password.>>
> Yes.
>
> <<2. At present the application tracks the user who makes the changes to the database through the
> application. The application passes the userid to the stored procedures. But if I put in a
> Applciation role in between, will I still have the actual userid to track who actually did the
> inserts and updates through the front-end.>>
> Yes. You can see the login id for the users, and you can use the SYSTEM_USER function in, for
> example, a trigger to get the login name. The user name, however, will be the app role name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Sunanda" <Sunanda@.discussions.microsoft.com> wrote in message
> news:00D6F5D5-0BC3-43A4-A313-649B5E2E215C@.microsoft.com...
> the following:
> Query Analyser or Enterprise Manager using the application rolde/password.
> application. The application passes the userid to the stored procedures. But if I put in a
> Applciation role in between, will I still have the actual userid to track who actually did the
> inserts and updates through the front-end.
>
>
|||> But can't the application role be restricted from using the QA/EM?
No, that is not the way it work. You need to protect the password. Why do you say it is not a secure method?
Are you afraid of network sniffing? There's an encryption option in sp_setapprole.

> Is there any alternative.
I don't know what your requirements are, as I haven't read the full thread. App roles is a nice feature for
what it is performing. Other options includes app logins using a special password (but all users will use the
same logins), app uses stored procedures and views to access data...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sunanda" <Sunanda@.discussions.microsoft.com> wrote in message
news:CA998A64-A51E-42B4-9B8D-E06C37624B65@.microsoft.com...
> Thanks for your reply.
> But can't the application role be restricted from using the QA/EM? This is not a completely secure method.
Is there any alternative.[vbcol=seagreen]
> Thanks,
> sunanda.
>
> "Tibor Karaszi" wrote:

login security question

Hi,
I have an application which connects to the SQL server. We have several user
s logging into this application. All of their user-id, passwords are validat
ed and converted to an owner profile, which is then used throughout the appl
ication.
My problem is, this owner profile should be prevented from accessing the dat
abase directly using Enterprise Manager or Query Analyser. The database shou
ld be accessible only from the application for this owner/global profile.
How do I go about achieving this. The application was set up like this by a
person long time back who is not with us anymore. Also, I do not know SQL Se
rver Administration. So, please detail out what information I have to look u
p and what steps I will hav
e to follow.
Thank you in advance.
SunnyLook into SQL Server Books online for "application roles" topic. This
explains about how to create and activate an application role within your
program and use it. This may require some code changes.
HTH
Prasad Koukuntla
"Sunanda" <Sunny@.discussions.microsoft.com> wrote in message
news:87CB3205-C041-4F23-AC6E-7BF23E7AB2C6@.microsoft.com...
> Hi,
> I have an application which connects to the SQL server. We have several
users logging into this application. All of their user-id, passwords are
validated and converted to an owner profile, which is then used throughout
the application.
> My problem is, this owner profile should be prevented from accessing the
database directly using Enterprise Manager or Query Analyser. The database
should be accessible only from the application for this owner/global
profile.
> How do I go about achieving this. The application was set up like this by
a person long time back who is not with us anymore. Also, I do not know SQL
Server Administration. So, please detail out what information I have to look
up and what steps I will have to follow.
> Thank you in advance.
> Sunny|||In my opinion, that does not seem possible. SQL doesn't know what CLIENT TO
OL is touching it. If the "connection" from the client application comes in
through a username/password, then that username/password has access to SELE
CT, UPDATE, DELETE, etc fro
m tables.
That is why we do all our database access through STORED PROCEDURES - so act
ual table access is not possible. Granted, the users can still call STORED
PROCEDURES from the EM and QA tools, but that is less likely to happen.
Can you hide the "connection" username/password from the users?
"Sunanda" wrote:

> Hi,
> I have an application which connects to the SQL server. We have several us
ers logging into this application. All of their user-id, passwords are valid
ated and converted to an owner profile, which is then used throughout the ap
plication.
> My problem is, this owner profile should be prevented from accessing the d
atabase directly using Enterprise Manager or Query Analyser. The database sh
ould be accessible only from the application for this owner/global profile.
> How do I go about achieving this. The application was set up like this by a person
long time back who is not with us anymore. Also, I do not know SQL Server Administr
ation. So, please detail out what information I have to look up and what steps I wil
l h
ave to follow.
> Thank you in advance.
> Sunny|||Steve,
No the connection profile is alreay know to the users, that is why we would
like to prevent users from using that in the enterprise manager to make chan
ges.
Please let me know if there are any options.
Thanks a lot.
Sunny
"Steve Z" wrote:

> In my opinion, that does not seem possible. SQL doesn't know what CLIENT TOOL is
touching it. If the "connection" from the client application comes in through a use
rname/password, then that username/password has access to SELECT, UPDATE, DELETE, et
c f
rom tables.[vbcol=seagreen]
> That is why we do all our database access through STORED PROCEDURES - so a
ctual table access is not possible. Granted, the users can still call STORE
D PROCEDURES from the EM and QA tools, but that is less likely to happen.
> Can you hide the "connection" username/password from the users?
> "Sunanda" wrote:
>
have to follow.[vbcol=seagreen]|||"Sunanda" <Sunny@.discussions.microsoft.com> wrote in message
news:87CB3205-C041-4F23-AC6E-7BF23E7AB2C6@.microsoft.com...
> Hi,
> I have an application which connects to the SQL server. We have several
users logging into this application. All of their user-id, passwords are
validated and converted to an owner profile, which is then used throughout
the application.
> My problem is, this owner profile should be prevented from accessing the
database directly using Enterprise Manager or Query Analyser. The database
should be accessible only from the application for this owner/global
profile.
> How do I go about achieving this. The application was set up like this by
a person long time back who is not with us anymore. Also, I do not know SQL
Server Administration. So, please detail out what information I have to look
up and what steps I will have to follow.
If you can alter the code in the client application, you can use application
roles.
1) Use Enterprise Manager to access the database / roles. New Role. click
the Application Role radio button and give it a nice secure, obscure
password.
2) Give the Application Role the appropriate permissions.
3) Revoke the users' permissions
4) in the code of the application, put in a call to a stored procedure
called (I think, from memory) sp_setAppRole (F1 for application role to see
what the stored proc is called) using the secret password for the App Role
(which you don't share with the end users).
Now your users will have the appropriate permissions when using your app,
but not when using QA or any other app.
On an entirely different tack, you can try Group Policies. Use a GP to tie
down their desktop so that they are not allowed to run Quey Analyzer or
Enterprise Manager.
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.711 / Virus Database: 467 - Release Date: 25/06/2004|||Bob,
Thanks for your reply. I kinda understand this Application Role approach. Co
uld you please explain the following:
1. Say the password for the Application role is found, can a user access the
database through the Query Analyser or Enterprise Manager using the applica
tion rolde/password.
2. At present the application tracks the user who makes the changes to the d
atabase through the application. The application passes the userid to the st
ored procedures. But if I put in a Applciation role in between, will I still
have the actual userid to
track who actually did the inserts and updates through the front-end.
Thanks in advance,
Sunanda.
"Bob Simms" wrote:

> "Sunanda" <Sunny@.discussions.microsoft.com> wrote in message
> news:87CB3205-C041-4F23-AC6E-7BF23E7AB2C6@.microsoft.com...
> users logging into this application. All of their user-id, passwords are
> validated and converted to an owner profile, which is then used throughout
> the application.
> database directly using Enterprise Manager or Query Analyser. The database
> should be accessible only from the application for this owner/global
> profile.
> a person long time back who is not with us anymore. Also, I do not know SQ
L
> Server Administration. So, please detail out what information I have to lo
ok
> up and what steps I will have to follow.
> If you can alter the code in the client application, you can use applicati
on
> roles.
> 1) Use Enterprise Manager to access the database / roles. New Role. clic
k
> the Application Role radio button and give it a nice secure, obscure
> password.
> 2) Give the Application Role the appropriate permissions.
> 3) Revoke the users' permissions
> 4) in the code of the application, put in a call to a stored procedure
> called (I think, from memory) sp_setAppRole (F1 for application role to s
ee
> what the stored proc is called) using the secret password for the App Role
> (which you don't share with the end users).
> Now your users will have the appropriate permissions when using your app,
> but not when using QA or any other app.
> On an entirely different tack, you can try Group Policies. Use a GP to ti
e
> down their desktop so that they are not allowed to run Quey Analyzer or
> Enterprise Manager.
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.711 / Virus Database: 467 - Release Date: 25/06/2004
>
>|||<<1. Say the password for the Application role is found, can a user access t
he database through the
Query Analyser or Enterprise Manager using the application rolde/password.>>
Yes.
<<2. At present the application tracks the user who makes the changes to the
database through the
application. The application passes the userid to the stored procedures. But
if I put in a
Applciation role in between, will I still have the actual userid to track wh
o actually did the
inserts and updates through the front-end.>>
Yes. You can see the login id for the users, and you can use the SYSTEM_USER
function in, for
example, a trigger to get the login name. The user name, however, will be th
e app role name.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sunanda" <Sunanda@.discussions.microsoft.com> wrote in message
news:00D6F5D5-0BC3-43A4-A313-649B5E2E215C@.microsoft.com...
> Bob,
> Thanks for your reply. I kinda understand this Application Role approach. Could yo
u please explain
the following:
> 1. Say the password for the Application role is found, can a user access the datab
ase through the
Query Analyser or Enterprise Manager using the application rolde/password.
> 2. At present the application tracks the user who makes the changes to the databas
e through the
application. The application passes the userid to the stored procedures. But
if I put in a
Applciation role in between, will I still have the actual userid to track wh
o actually did the
inserts and updates through the front-end.[vbcol=seagreen]
> Thanks in advance,
> Sunanda.
>
> "Bob Simms" wrote:
>|||Thanks for your reply.
But can't the application role be restricted from using the QA/EM? This is n
ot a completely secure method. Is there any alternative.
Thanks,
sunanda.
"Tibor Karaszi" wrote:

> <<1. Say the password for the Application role is found, can a user access
the database through the
> Query Analyser or Enterprise Manager using the application rolde/password.
>>
> Yes.
>
> <<2. At present the application tracks the user who makes the changes to t
he database through the
> application. The application passes the userid to the stored procedures. B
ut if I put in a
> Applciation role in between, will I still have the actual userid to track
who actually did the
> inserts and updates through the front-end.>>
> Yes. You can see the login id for the users, and you can use the SYSTEM_US
ER function in, for
> example, a trigger to get the login name. The user name, however, will be
the app role name.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Sunanda" <Sunanda@.discussions.microsoft.com> wrote in message
> news:00D6F5D5-0BC3-43A4-A313-649B5E2E215C@.microsoft.com...
> the following:
> Query Analyser or Enterprise Manager using the application rolde/password.
> application. The application passes the userid to the stored procedures. B
ut if I put in a
> Applciation role in between, will I still have the actual userid to track
who actually did the
> inserts and updates through the front-end.
>
>|||> But can't the application role be restricted from using the QA/EM?
No, that is not the way it work. You need to protect the password. Why do yo
u say it is not a secure method?
Are you afraid of network sniffing? There's an encryption option in sp_setap
prole.

> Is there any alternative.
I don't know what your requirements are, as I haven't read the full thread.
App roles is a nice feature for
what it is performing. Other options includes app logins using a special pas
sword (but all users will use the
same logins), app uses stored procedures and views to access data...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Sunanda" <Sunanda@.discussions.microsoft.com> wrote in message
news:CA998A64-A51E-42B4-9B8D-E06C37624B65@.microsoft.com...
> Thanks for your reply.
> But can't the application role be restricted from using the QA/EM? This is not a c
ompletely secure method.
Is there any alternative.[vbcol=seagreen]
> Thanks,
> sunanda.
>
> "Tibor Karaszi" wrote:
>

Login Properties: Deny, Disable, Lock Out? Which do I use?

Hey again!

I have a SQL login, and I want to prevent the login from logging into SQL Server.

From SSMS, I connect to the Database Engine, expand Security, Logins.
I right-click the login in question and select Properties. I select the Status page.

So I see I can deny, disable and lock out this login.
What is the difference between these three options?

Also, shouldn't the checkbox "Login is locked out" be checkable?
Currently, it's unchecked/disabled and I cannot alter this value.

I performed a cross-reference of the possible combinations:

SQL Logins:

FQ Login ID Password Status Enabled? Lock? @.@.ERROR
-- -- --
UserName (valid) Grant Enabled No 0
UserName (valid) Grant Enabled Yes 18486
UserName (valid) Grant Disabled No 18470
UserName (valid) Grant Disabled Yes 18470
UserName (valid) Deny Enabled No 18456
UserName (valid) Deny Enabled Yes 18486
UserName (valid) Deny Disabled No 18470
UserName (valid) Deny Disabled Yes 18470
UserName (garbage) Grant Enabled No 18456
UserName (garbage) Grant Enabled Yes 18456
UserName (garbage) Grant Disabled No 18456
UserName (garbage) Grant Disabled Yes 18456
UserName (garbage) Deny Enabled No 18456
UserName (garbage) Deny Enabled Yes 18456
UserName (garbage) Deny Disabled No 18456
UserName (garbage) Deny Disabled Yes 18456
(garbage) (garbage) Either Either No 18456

NT-Logins:

FQ Login ID Password Status Enabled? Lock? @.@.ERROR
-- -- --
DOMAIN\UserName N/A Grant Enabled N/A 0
DOMAIN\UserName N/A Deny Enabled N/A 18456
DOMAIN\UserName N/A Grant Disabled N/A 18470
DOMAIN\UserName N/A Deny Disabled N/A 18470

where @.@.ERROR
0 = Connects
18456 = Login failed for user 'UserName'.
18470 = Login failed for user 'UserName'. Reason: The account is disabled.
18486 = Login failed for user 'UserName' because the account is currently locked out. The system administrator can unlock it.

(Upon third garbage-password, the SQL-account is locked.)

|||

A plain 18456 "login failed" message could mean
- the user is using an incorrect username
- the user is using an incorrect password
- the user isn't defined to the datasource
- the user is denied access.

Based on these findings, I like the "disabled" setting over "denied." If a user calls me with an 18470 message, I have some confidence in that the user connecting with a valid username and password.