Tuesday, March 20, 2012
can't drop trigger
I just created a tirgger. when I tried to drop it, it say "Cannot drop the
trigger 'trigger_name', because it does not exist in the system catalog." But
it shows when I query as:
SELECT *
FROM sysobjects o INNER JOIN syscomments c
ON o.id = c.id
WHERE o.type = 'TR' and o.name = 'trigger_name'
when I tried to create again, it failed "There is already an object named
'trigger_name' in the database.
what can I do? Thanks
Jen wrote:
> Hi,
> I just created a tirgger. when I tried to drop it, it say "Cannot drop the
> trigger 'trigger_name', because it does not exist in the system catalog." But
> it shows when I query as:
> SELECT *
> FROM sysobjects o INNER JOIN syscomments c
> ON o.id = c.id
> WHERE o.type = 'TR' and o.name = 'trigger_name'
> when I tried to create again, it failed "There is already an object named
> 'trigger_name' in the database.
> what can I do? Thanks
You should always used schema-qualified object names, i.e.
"dbo.MyTriggerName". Sounds like you're dealing with a schema-naming
issue, "dbo.MyTriggerName" vs. "userA.MyTriggerName".
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||I used "create trigger dbo.trigger_name on userA.table_name..."
I tried to user "sp_helptrigger userA.table_name" it says "Incorrect syntax
near '.'"
How can I drop the trigger? How can I view the trigger? Thanks
"Tracy McKibben" wrote:
> Jen wrote:
> You should always used schema-qualified object names, i.e.
> "dbo.MyTriggerName". Sounds like you're dealing with a schema-naming
> issue, "dbo.MyTriggerName" vs. "userA.MyTriggerName".
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>
|||is it in SQL 2000 or 2005
try specifying someting like
Drop Trigger <TriggerName>
ON <Database or ALL Server>
Maninder
MCDBA
On Jan 30, 1:54 pm, Tracy McKibben <t...@.realsqlguy.com> wrote:
> Jen wrote:
>
>
> You should always used schema-qualified object names, i.e.
> "dbo.MyTriggerName". Sounds like you're dealing with a schema-naming
> issue, "dbo.MyTriggerName" vs. "userA.MyTriggerName".
> --
> Tracy McKibben
> MCDBAhttp://www.realsqlguy.com- Hide quoted text -
> - Show quoted text -
|||It's sql2000. I got "Incorrect syntax near the keyword 'on'".
"Maninder" wrote:
> is it in SQL 2000 or 2005
> try specifying someting like
> Drop Trigger <TriggerName>
> ON <Database or ALL Server>
> Maninder
> MCDBA
> On Jan 30, 1:54 pm, Tracy McKibben <t...@.realsqlguy.com> wrote:
>
>
|||Jen wrote:
> I used "create trigger dbo.trigger_name on userA.table_name..."
> I tried to user "sp_helptrigger userA.table_name" it says "Incorrect syntax
> near '.'"
>
sp_helptrigger 'userA.table_name'
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||As Tracy suggestd, try using the Object owner in the drop statement.
Or if you are db_owner or a sa you can drop the Trigger with the
Schemaname.Triggername
Maninder
MCDBA
On Jan 30, 2:23 pm, Jen <J...@.discussions.microsoft.com> wrote:
> It's sql2000. I got "Incorrect syntax near the keyword 'on'".
>
> "Maninder" wrote:
>
>
>
>
> - Show quoted text -
|||Thanks. I droped it. Even though I specify "dbo.trigger_name" in create
trigger, but the trigger's owner is "userA" by checking sysobjects table. Is
it strange?
Thanks
"Maninder" wrote:
> As Tracy suggestd, try using the Object owner in the drop statement.
> Or if you are db_owner or a sa you can drop the Trigger with the
> Schemaname.Triggername
> Maninder
> MCDBA
>
> On Jan 30, 2:23 pm, Jen <J...@.discussions.microsoft.com> wrote:
>
>
|||We had the same Problem with the windows user accounts.
I had a Workaround for this problem.
I Created a Trigger on the Database for Events we need to capture like
Create_table,Create_procedure
So,every time a user creates a object this trigger Fires and renames
the schema to dbo for the object.
or Use ALTER SCHEMA for single use.
Maninder
MCDBA
Can't drop subscription
even tried to drop it on a per article basis. First few table/articles went
fine, but when went to drop an article for a very large table, whole system
locked up again.
--Thanks,
Kristy
try sp_dropsubscription from QA. You might want to stop your distribution,
merge, log reader agents to be able to do this. Then start them up one by
one.
How many subscribers do you have? are they push or pull? Are you running
them continuously or staggering them. If you have a large number >50 (or
perhaps even >20) use pull, and stagger your schedules, perhaps every 7 or
11 minutes.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:uAVjjbIMFHA.3832@.TK2MSFTNGP12.phx.gbl...
> Either through EM or using sp_dropsubscription. Whole system locks up.
I've
> even tried to drop it on a per article basis. First few table/articles
went
> fine, but when went to drop an article for a very large table, whole
system
> locked up again.
> --Thanks,
> Kristy
>
|||I have run the sp_dropsubscriptions from QA and it locks up. I have also run
it from QA and have been trying to select on a pure article basis. The first
15 articles went fine, but the 16th locked everything up again. This
particular table is massive, so I didn't know if this had anything to do
with it.
We have 1 publisher and 1 subscriber. distributor is currently on publisher.
THe subscriber is really just a hot backup for the publisher since we don't
have clustering. If something were to happen to pub and we couldn't bring
back up then we would switch to sub.
It is currently a push subscription, but we will be using the pull with a
new subscription. the immediate_sync is 1 (which I think means immediate)
and sync_method = 3 (which I have no idea what that means.) The agents have
not been running for 2 days as we are dropping this subscription and
starting over with a remote distributor and pull subscription. I have even
backed up the distribution database, truncated the ms_repltransactions and
ms_replcommands tables and then shrink the distribution database files.
Previously the dist db had grown to about 60 GB with the combined file size.
Now its about 4 MBs.
I have searched all over online and through the repl book and can't find
anything. I don't know what else to do!!!!
Many thanks for your help,
Kristy
we are using tran repl and I have stopped the agents 2 days ago.
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:%232YjarIMFHA.3080@.TK2MSFTNGP10.phx.gbl...
> try sp_dropsubscription from QA. You might want to stop your distribution,
> merge, log reader agents to be able to do this. Then start them up one by
> one.
> How many subscribers do you have? are they push or pull? Are you running
> them continuously or staggering them. If you have a large number >50 (or
> perhaps even >20) use pull, and stagger your schedules, perhaps every 7 or
> 11 minutes.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Kristy" <pleasereplyby@.posting.com> wrote in message
> news:uAVjjbIMFHA.3832@.TK2MSFTNGP12.phx.gbl...
> I've
> went
> system
>
|||I figured it out. The previous DBA had a job that put an UPDLOCK, HOLDLOCK
on the table I was trying to drop from replication. I can probably do a drop
all now instead of a per article basis.
--K
"Kristy" <pleasereplyby@.posting.com> wrote in message
news:%23a98n9IMFHA.3988@.tk2msftngp13.phx.gbl...
> I have run the sp_dropsubscriptions from QA and it locks up. I have also
run
> it from QA and have been trying to select on a pure article basis. The
first
> 15 articles went fine, but the 16th locked everything up again. This
> particular table is massive, so I didn't know if this had anything to do
> with it.
> We have 1 publisher and 1 subscriber. distributor is currently on
publisher.
> THe subscriber is really just a hot backup for the publisher since we
don't
> have clustering. If something were to happen to pub and we couldn't bring
> back up then we would switch to sub.
> It is currently a push subscription, but we will be using the pull with a
> new subscription. the immediate_sync is 1 (which I think means immediate)
> and sync_method = 3 (which I have no idea what that means.) The agents
have
> not been running for 2 days as we are dropping this subscription and
> starting over with a remote distributor and pull subscription. I have even
> backed up the distribution database, truncated the ms_repltransactions and
> ms_replcommands tables and then shrink the distribution database files.
> Previously the dist db had grown to about 60 GB with the combined file
size.[vbcol=seagreen]
> Now its about 4 MBs.
> I have searched all over online and through the repl book and can't find
> anything. I don't know what else to do!!!!
> Many thanks for your help,
> Kristy
> we are using tran repl and I have stopped the agents 2 days ago.
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:%232YjarIMFHA.3080@.TK2MSFTNGP10.phx.gbl...
distribution,[vbcol=seagreen]
by[vbcol=seagreen]
or
>
Sunday, March 11, 2012
Cant delete user table
The type and xtype in sysobjects are both U. They show up in object browser
under user tables. When I try to delete them I get the following message:
You tried to delete one or more system objects. They were not deleted.
Anyone have any ideas as to what is going on here and how I can delete these?
Can you mention the name of these tables?
Thanks
GYK
"Lyle" wrote:
> I have 4 user tables that show up in Enterprise Manager as SYSTEM tables.
> The type and xtype in sysobjects are both U. They show up in object browser
> under user tables. When I try to delete them I get the following message:
> You tried to delete one or more system objects. They were not deleted.
> Anyone have any ideas as to what is going on here and how I can delete these?
|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_History_Detai l
conflict_pubInvHist_Head_Det_Invoice_History_Heade r
conflict_PubInvoice_Head_Det_Invoice_History_Detai l
conflict_PubInvoice_Head_Det_Invoice_History_Heade r
Lyle
"GYK" wrote:
[vbcol=seagreen]
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_History_Detai l
conflict_pubInvHist_Head_Det_Invoice_History_Heade r
conflict_PubInvoice_Head_Det_Invoice_History_Detai l
conflict_PubInvoice_Head_Det_Invoice_History_Heade r
Lyle
"GYK" wrote:
[vbcol=seagreen]
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_History_Detai l
conflict_pubInvHist_Head_Det_Invoice_History_Heade r
conflict_PubInvoice_Head_Det_Invoice_History_Detai l
conflict_PubInvoice_Head_Det_Invoice_History_Heade r
Lyle
"GYK" wrote:
[vbcol=seagreen]
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
Cant delete user table
The type and xtype in sysobjects are both U. They show up in object browser
under user tables. When I try to delete them I get the following message:
You tried to delete one or more system objects. They were not deleted.
Anyone have any ideas as to what is going on here and how I can delete these?Can you mention the name of these tables?
Thanks
GYK
"Lyle" wrote:
> I have 4 user tables that show up in Enterprise Manager as SYSTEM tables.
> The type and xtype in sysobjects are both U. They show up in object browser
> under user tables. When I try to delete them I get the following message:
> You tried to delete one or more system objects. They were not deleted.
> Anyone have any ideas as to what is going on here and how I can delete these?|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_History_Detail
conflict_pubInvHist_Head_Det_Invoice_History_Header
conflict_PubInvoice_Head_Det_Invoice_History_Detail
conflict_PubInvoice_Head_Det_Invoice_History_Header
Lyle
"GYK" wrote:
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
> > I have 4 user tables that show up in Enterprise Manager as SYSTEM tables.
> > The type and xtype in sysobjects are both U. They show up in object browser
> > under user tables. When I try to delete them I get the following message:
> >
> > You tried to delete one or more system objects. They were not deleted.
> >
> > Anyone have any ideas as to what is going on here and how I can delete these?|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_History_Detail
conflict_pubInvHist_Head_Det_Invoice_History_Header
conflict_PubInvoice_Head_Det_Invoice_History_Detail
conflict_PubInvoice_Head_Det_Invoice_History_Header
Lyle
"GYK" wrote:
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
> > I have 4 user tables that show up in Enterprise Manager as SYSTEM tables.
> > The type and xtype in sysobjects are both U. They show up in object browser
> > under user tables. When I try to delete them I get the following message:
> >
> > You tried to delete one or more system objects. They were not deleted.
> >
> > Anyone have any ideas as to what is going on here and how I can delete these?|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_History_Detail
conflict_pubInvHist_Head_Det_Invoice_History_Header
conflict_PubInvoice_Head_Det_Invoice_History_Detail
conflict_PubInvoice_Head_Det_Invoice_History_Header
Lyle
"GYK" wrote:
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
> > I have 4 user tables that show up in Enterprise Manager as SYSTEM tables.
> > The type and xtype in sysobjects are both U. They show up in object browser
> > under user tables. When I try to delete them I get the following message:
> >
> > You tried to delete one or more system objects. They were not deleted.
> >
> > Anyone have any ideas as to what is going on here and how I can delete these?
Cant delete user table
The type and xtype in sysobjects are both U. They show up in object browser
under user tables. When I try to delete them I get the following message:
You tried to delete one or more system objects. They were not deleted.
Anyone have any ideas as to what is going on here and how I can delete these
?Can you mention the name of these tables?
Thanks
GYK
"Lyle" wrote:
[vbcol=seagreen]
> I have 4 user tables that show up in Enterprise Manager as SYSTEM tables.
> The type and xtype in sysobjects are both U. They show up in object brows
er
> under user tables. When I try to delete them I get the following message:
> You tried to delete one or more system objects. They were not deleted.
> Anyone have any ideas as to what is going on here and how I can delete these?[/vbc
ol]|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_His
tory_Detail
conflict_pubInvHist_Head_Det_Invoice_His
tory_Header
conflict_PubInvoice_Head_Det_Invoice_His
tory_Detail
conflict_PubInvoice_Head_Det_Invoice_His
tory_Header
Lyle
"GYK" wrote:
[vbcol=seagreen]
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
>|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_His
tory_Detail
conflict_pubInvHist_Head_Det_Invoice_His
tory_Header
conflict_PubInvoice_Head_Det_Invoice_His
tory_Detail
conflict_PubInvoice_Head_Det_Invoice_His
tory_Header
Lyle
"GYK" wrote:
[vbcol=seagreen]
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
>|||Yes, the table names are:
conflict_pubInvHist_Head_Det_Invoice_His
tory_Detail
conflict_pubInvHist_Head_Det_Invoice_His
tory_Header
conflict_PubInvoice_Head_Det_Invoice_His
tory_Detail
conflict_PubInvoice_Head_Det_Invoice_His
tory_Header
Lyle
"GYK" wrote:
[vbcol=seagreen]
> Can you mention the name of these tables?
> Thanks
> GYK
> "Lyle" wrote:
>
Can't delete SQL 2005 user from SQL 2000 database
IIS_WPG.
I restore a backup of this to a SQL 2005 database (working on a migration to
SQL 2005). Since IIS_WPG is not a Security Login on SQL 2005, when I go to
delete the database user IIS_WPG, it fails with "Drop failed for user
IIS_WPG".
How can I delete this user from the database instance?
Thanks. AmilThe fact that the DB came from SQL 2000 originally ought to be
irrelevant. As soon as you restore it on the SQL 2005 server it becomes
a SQL 2005 database (albeit in 8.0 compatibility mode but that's also
not important). You should be able to drop any users of the DB (except
dbo, which is a special user) with a simple DROP USER
<http://msdn2.microsoft.com/en-us/library/ms189438.aspx> statement in
T-SQL. For example:
use MyDB;
drop user IIS_WPG;
If this doesn't work can you please post the exactly error message that
SQL Server raises. Also posting the result of:
use MyDB;
select current_user;
select
principal_id,
cast(name as varchar(50)) as name,
type_desc
from sys.database_principals
where is_fixed_role = 0;
might help troubleshooting.
*mike hodgson*
http://sqlnerd.blogspot.com
Amil Hanish wrote:
>I have a SQL 2000 database from another system. The database has user
>IIS_WPG.
>I restore a backup of this to a SQL 2005 database (working on a migration t
o
>SQL 2005). Since IIS_WPG is not a Security Login on SQL 2005, when I go to
>delete the database user IIS_WPG, it fails with "Drop failed for user
>IIS_WPG".
>How can I delete this user from the database instance?
>Thanks. Amil
>
>|||Mike, that didn't work.
The iis_wpg user doesn't appear in the Security | Logins so I don't know why
it's complaining. Here is the query info.
use mydb;
drop user iis_wpg
Msg 15138, Level 16, State 1, Line 2
The database principal owns a schema in the database, and cannot be dropped.
=======================
use mydb;
select current_user;
select
principal_id,
cast(name as varchar(50)) as name,
type_desc
from sys.database_principals
where is_fixed_role = 0;
0 public DATABASE_ROLE
1 dbo WINDOWS_USER
2 guest SQL_USER
3 INFORMATION_SCHEMA SQL_USER
4 sys SQL_USER
5 ASPNET WINDOWS_USER
6 IIS_WPG WINDOWS_GROUP
"Mike Hodgson" <e1minst3r@.gmail.com> wrote in message
news:ufZs8F%23cGHA.3888@.TK2MSFTNGP02.phx.gbl...
> The fact that the DB came from SQL 2000 originally ought to be
> irrelevant. As soon as you restore it on the SQL 2005 server it becomes
> a SQL 2005 database (albeit in 8.0 compatibility mode but that's also
> not important). You should be able to drop any users of the DB (except
> dbo, which is a special user) with a simple DROP USER
> <http://msdn2.microsoft.com/en-us/library/ms189438.aspx> statement in
> T-SQL. For example:
> use MyDB;
> drop user IIS_WPG;
> If this doesn't work can you please post the exactly error message that
> SQL Server raises. Also posting the result of:
> use MyDB;
> select current_user;
> select
> principal_id,
> cast(name as varchar(50)) as name,
> type_desc
> from sys.database_principals
> where is_fixed_role = 0;
> might help troubleshooting.
> --
> *mike hodgson*
> http://sqlnerd.blogspot.com
>
> Amil Hanish wrote:
>
>|||Ah. Now we're getting somewhere. The IIS_WPG user owns a schema! OK,
you have 2 options: 1) transfer the ownership of the schema(s) owned by
IIS_WPG to a different user in the database or 2) drop the schema(s)
owned by IIS_WPG.
First you need to know which schema(s) IIS_WPG owns (obviously this
should all be done in the context of the database in question):
use myDB;
select s.* from sys.schemas as s
inner join sys.database_principals as dp on dp.principal_id =
s.principal_id
where dp.[name] = 'IIS_WPG';
Next you should check to see if there are any objects within that/those
schema(s):
select s.[name] as schemaname, o.[name] as objectname, o.type_desc
from sys.objects as o
inner join sys.schemas as s on s.schema_id = o.schema_id
inner join sys.database_principals as dp on dp.principal_id =
s.principal_id
where dp.[name] = 'IIS_WPG'
order by s.[name], o.type_desc, o.[name];
If there any no objects in the schema then you may as well just drop the
schema and be done with it:
drop schema foo;
where foo is the name of the schema. (Do this for each schema you want
to drop.) However, if the schema contains objects (views, tables,
procs, functions, etc.) that you wish to keep then you should either
transfer them to another schema (so you can drop their original schema,
which is owned by IIS_WPG) with the ALTER SCHEMA statement or transfer
ownership of the schema(s) that IIS_WPG currently owns. Transferring
ownership is easier and less likely to break code referencing those
objects. You transfer ownership with the ALTER AUTHORIZATION statement:
alter authorization on schema::foo to MyOtherDBUser;
where foo is the name of the schema you're transferring ownership of and
MyOtherDBUser is another user in the DB to which you wish to transfer
ownership (the dbo user is always a potential candidate). You'd do this
for each schema owned by IIS_WPG.
After all that the IIS_WPG user shouldn't own any schemas any more and
you should be able to drop the user with a DROP USER statement:
drop user IIS_WPG;
This is all documented in BOL if you need any more info about any of
these individual statements (including the sys.objects, sys.schemas &
sys.database_principals catalog views).
Hope this helps.
*mike hodgson*
http://sqlnerd.blogspot.com
Amil Hanish wrote:
>Mike, that didn't work.
>The iis_wpg user doesn't appear in the Security | Logins so I don't know wh
y
>it's complaining. Here is the query info.
>use mydb;
>drop user iis_wpg
>Msg 15138, Level 16, State 1, Line 2
>The database principal owns a schema in the database, and cannot be dropped
.
>=======================
>use mydb;
> select current_user;
> select
> principal_id,
> cast(name as varchar(50)) as name,
> type_desc
> from sys.database_principals
> where is_fixed_role = 0;
>0 public DATABASE_ROLE
>1 dbo WINDOWS_USER
>2 guest SQL_USER
>3 INFORMATION_SCHEMA SQL_USER
>4 sys SQL_USER
>5 ASPNET WINDOWS_USER
>6 IIS_WPG WINDOWS_GROUP
>
>"Mike Hodgson" <e1minst3r@.gmail.com> wrote in message
>news:ufZs8F%23cGHA.3888@.TK2MSFTNGP02.phx.gbl...
>
>
>|||Mike...much thanks! All your info worked like a charm and without issues.
Since the schema had no object, I was able to simply delete. I'll save your
help in case I need it in the future.
Amil
"Mike Hodgson" <e1minst3r@.gmail.com> wrote in message
news:%233VIaFIdGHA.1208@.TK2MSFTNGP04.phx.gbl...
> Ah. Now we're getting somewhere. The IIS_WPG user owns a schema! OK,
> you have 2 options: 1) transfer the ownership of the schema(s) owned by
> IIS_WPG to a different user in the database or 2) drop the schema(s)
> owned by IIS_WPG.
> First you need to know which schema(s) IIS_WPG owns (obviously this
> should all be done in the context of the database in question):
> use myDB;
> select s.* from sys.schemas as s
> inner join sys.database_principals as dp on dp.principal_id =
> s.principal_id
> where dp.[name] = 'IIS_WPG';
> Next you should check to see if there are any objects within that/those
> schema(s):
> select s.[name] as schemaname, o.[name] as objectname, o.type_d
esc
> from sys.objects as o
> inner join sys.schemas as s on s.schema_id = o.schema_id
> inner join sys.database_principals as dp on dp.principal_id =
> s.principal_id
> where dp.[name] = 'IIS_WPG'
> order by s.[name], o.type_desc, o.[name];
> If there any no objects in the schema then you may as well just drop the
> schema and be done with it:
> drop schema foo;
> where foo is the name of the schema. (Do this for each schema you want
> to drop.) However, if the schema contains objects (views, tables,
> procs, functions, etc.) that you wish to keep then you should either
> transfer them to another schema (so you can drop their original schema,
> which is owned by IIS_WPG) with the ALTER SCHEMA statement or transfer
> ownership of the schema(s) that IIS_WPG currently owns. Transferring
> ownership is easier and less likely to break code referencing those
> objects. You transfer ownership with the ALTER AUTHORIZATION statement:
> alter authorization on schema::foo to MyOtherDBUser;
> where foo is the name of the schema you're transferring ownership of and
> MyOtherDBUser is another user in the DB to which you wish to transfer
> ownership (the dbo user is always a potential candidate). You'd do this
> for each schema owned by IIS_WPG.
> After all that the IIS_WPG user shouldn't own any schemas any more and
> you should be able to drop the user with a DROP USER statement:
> drop user IIS_WPG;
> This is all documented in BOL if you need any more info about any of
> these individual statements (including the sys.objects, sys.schemas &
> sys.database_principals catalog views).
> Hope this helps.
> --
> *mike hodgson*
> http://sqlnerd.blogspot.com
>
> Amil Hanish wrote:
>
>
Saturday, February 25, 2012
Cant convert types
I ham trying to convert a 'System.Data.CommandType' to 'System.Web.UI.WebControls.SqlDataSourceCommandType'.
but I get
Error 4 Cannot implicitly convert type 'System.Data.CommandType' to 'System.Web.UI.WebControls.SqlDataSourceCommandType'. An explicit conversion exists (are you missing a cast?) D:\Inetpub\wwwroot\Help_Desk\App_Code\HelpDeskSql.cs 99 42 http://localhost/Help_Desk/
My problem is I cant seem to get a explicit conversion to work. if it cast it I get an.
Specified argument was out of the range of valid values.
Parameter name: value . when running the page. but no build errors, does anyone know how to cast this?
if (cmdUpdate !=null)
{
HDS.UpdateCommand = cmdUpdate.CommandText;
HDS.UpdateCommandType = (SqlDataSourceCommandType)cmdUpdate.CommandType; //errror line
for (int i = 0; i < cmdUpdate.Parameters.Count; i++)
{
HDS.UpdateParameters.Add(cmdUpdate.Parameters[i].ParameterName, cmdUpdate.Parameters[i].Value.ToString());
}
}
Thursday, February 16, 2012
can't connect to SQL 6.5 server in different domain
that is in a different domain. The domains are trusted. I've tried every t
ype of authentication but my Win XP system just can't get a DSN to connect a
gain the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
ChuckHi,
Can you create a alias name using "CLIENT NETWORK UTILITY" from your WIN XP
System by providing the
1. Protocol as TCP/IP
2. Provide the SQL 6.5 IP address
3. Define the Port number
Then use the ALIAS server name to connect.
--
Thanks
Hari
SQL Server MVP
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message news:ziWkd
.18733$Rf1.10698@.newssvr19.news.prodigy.com...
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever
that is in a different domain. The domains are trusted. I've tried every t
ype of authentication but my Win XP system just can't get a DSN to connect a
gain the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck|||If SQL Server 6.5 is set to use Windows only authentication, this will not
work. With SQL Server 6.5 NT authentication only works with named pipes.
Also by default SQL Server 6.5 does not enable TCP/IP. It has to be done
after setup. So use SQL Server setup to see if tcp/ip is enabled. Then set
SQL Server to use mixed security and then configure your DSN to use SQL
authentication. This is just a test to see if you can connect. With this
configuration the alias that Hari suggests should work.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
can't connect to SQL 6.5 server in different domain
Thanks,
Chuck
Hi,
Can you create a alias name using "CLIENT NETWORK UTILITY" from your WIN XP System by providing the
1. Protocol as TCP/IP
2. Provide the SQL 6.5 IP address
3. Define the Port number
Then use the ALIAS server name to connect.
Thanks
Hari
SQL Server MVP
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message news:ziWkd.18733$Rf1.10698@.newssvr19.news.prodigy. com...
Is there any trick to setting up a System DSN to connect to a SQL 6.5 Sever that is in a different domain. The domains are trusted. I've tried every type of authentication but my Win XP system just can't get a DSN to connect again the SQL Server that is running Win NT4 SP6. Is there a trick?
Thanks,
Chuck
|||If SQL Server 6.5 is set to use Windows only authentication, this will not
work. With SQL Server 6.5 NT authentication only works with named pipes.
Also by default SQL Server 6.5 does not enable TCP/IP. It has to be done
after setup. So use SQL Server setup to see if tcp/ip is enabled. Then set
SQL Server to use mixed security and then configure your DSN to use SQL
authentication. This is just a test to see if you can connect. With this
configuration the alias that Hari suggests should work.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
Sunday, February 12, 2012
Can''t connect to MSDE
I opened the port for SQL Server 1433, and MSDE port 1503(get from registry) in the Windows Firewall, and enable DISABLENETWORKPROTOCOLS=0 for MSDE.
I can connect to SQL Server and MSDE in the local server, and can connect to the SQL Server in another machine(ClientA) from Visual Studio .Net and SQL Sever authentication. but can't connect to the MSDE from another machine(ClientA) in Visual Studio .Net by SQL Server Authentication. The visual studio .net can't detect the MSDE instance automatically.
BTW, both the server and ClientA are in the same Workgroug, no domain defined.
I think, this should be something about configuration. Any clue? Thanks very much.
If you're using local security on each machine (because you're in a workgroup) then Windows security probably won't work the way you think it is working. In a domain called DomainA, the account UserA is known as DomainA\UserA. Since all the servers joined to that domain see the same security, they all view this person as DomainA\UserA. Since you don't have a domain, each server has it's own security, meaning that an account created and named on each machine as UserA would be known as ServerA\UserA and ServerB\UserA. These are two different accounts.
So the point is that when SQL Server on ServerA is set to use Integrated security, the only accounts it knows about are ServerA, not Server B. When you log on to a system as ServerB\UserA, the SQL Server does not know who you are.
Now, since you are stating that you are using mixed authentication, you shouldn't have the problem. In fact, you state that you can log on using a tool other than SQL Server from any system in the workgroup, as long as you use a SQL Server account. So this leads me to think that your connection string is trying to use a Windows account to connect. That's where you should start looking.
|||Ok, I have spent the last 3 days trying to do research on SQL Server 2K5 Express connectivity and have not found any definite answers as to what I need to do to solve the problem.
Background:
Client: WinXP Pro 2002 SP2 running MS SQL Server Management Studio Express
Server: WinXP Pro 2002 SP2 running MS SQL Server 2005 Express configured for mixed authentication.
Both machines not on domains but share a common workgroup.
Windows firewalls on these machines disabled. Router firewall opened port 1433 to server. I am connecting from Client to Server by hitting the router IP and coming back in through port forwarding since my clients will have to be hitting my server through my router. Connectivity of the 2 machines is fine as I can telnet from one to the other on 1433 without issue when first stopping SQL Server of course.
Requirement: Connecting the two using Windows Authentication and TCP protocol to MS SQL Server. Ultimately, I am doing this to have clients connect into my server withoug having to be part of my domain/workgroup.
Server name in studio set to: tcp:www.myserver.org\sqlinstance,1433
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now I have read some articles implying that this should be possible using 'workgroup authentication' so I tried that - basically ensuring that identical accounts are set up on both machines with the same passwords - I know this is working since I can transparently (no login required) map shares from one to other. This however still left me with the above error. I am assuming mapped drives used named pipes so this doesn't prove much when I am using Studio to connect via TCP.
For later reference, lets say the client machine is named CLIENT and the server is named SERVER and the common username is USERNAME and common password of PASSWORD.
I read an article stipulating that the authentication is domain based so that machine SERVER would receive an authentication SID (terminology may be wrong here) of CLIENT\USERNAME but since neither machine is on a domain SERVER could not validate the credentials on CLIENT and so it cannot work.
But yet another article said it can...go into Start|Settings|Control Panel|User Accounts and make click on 'Manage my network password' and make a new entry for the server and enter the username as it is required on the server...so I created one as follows:
Server: SERVER
User Name: USERNAME
Password: PASSWORD
...but received the same error.
If I use SQL Server Authentication it works fine...but my readings have shown that SQL Server Authentication is not all that secure (but in fairness don't know if most of the articles I read this in were talking about previous versions of MS SQL Server 2005).
So my questions:
1) Is SQL Server Authentication in MS SQL Server 2005 secure (maybe not as secure as Windows Auth, but secure enough to trust sensitive information to?)
2) Is it possible to use Windows Authentication between 2 machines separated by the internet and not part of domains? If so, what are the requirements for this? Common accounts/passwords? Common Workgroup? etc...
3) If 2) isn't possible does that imply that I need an OS that can act as a domain controller just to host my SQL Server? If so, could I then 'Manage my network password' on any client that needs to connect and have it provide correct domain\user info to the domain controller thereby avoiding having to join the domain to connect to the SQL Server - keep in mind the ultimate goal here is to have clients connect into my SQL Server via the internet where they won't be part of my domain and/or possibly can not be made part of my workgroup.
Thanks so much for any help you can provide.
Best Regards,
DOD
|||Good Questions - Hopefully I can help clear these up a little.
1. SQL Auth is very secure. In SQL 2K5, if you're using Win 2K3, you can even tie some of the Win2K3 policies (password change, length, etc.) to SQL Server Accounts. The rest of these answers is only for Windows Auth. For SQL Server Auth you can just connect using the name and account pair.
2. Management Studio uses your current account to connect - that's by design. If your account can be seen/trusted by the other system, you're in. If not, right-click Management Studio and select "Run As" if you're using XP. Then you can provide a domain/user pair.
You can definitely connect without common domains through any application by providing a connection string. You can also do this with any of the command-line utility such as sqlcmd, since you provide a connection string. Books Online has more about sqlcmd.
3. Not at all. Windows Security is a big subject, but the point is that you just need to determine what the server needs to see. I run several SQL Servers with Local (Workgroup) security.
- Buck
|||Thank you SOOOO much...it's nice to have an authority on the matter give a 'matter of fact' response!
Just a couple more questions regarding the above...
1) Given that I will not be running Win2K3 in the shortterm, but hosting SQL Server on a WinXP 2002 SP2 box, is SQL Auth in SQL Server 2K5 is inherently secure enough for sensitive business information when not tying into OS security policy functionality?
2) Is there any way to have an app always ran under different credentials (to avoid having to select Run As from the context menu each time) via some shortcut property, registry modification, or something else?
Once again, thanks in advance...I spent literally days researching this but because of my security concerns hadn't found what I considered a consistent and direct answer to the above.
<edited>
I just tried using the Run As and get the same error:
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Interesting that in the username field it still shows my local workgroup\logged in user versus what I set up in the Run As dialog. Is this just a bug in that the GUI does not reflect the Run As parameters or is it in fact just always using the logged in user?
I can connect using SQL Auth, so know without question that firewall settings are not an issue. I specified the user as:
WXP-P2000\myadminuser where WXP-P2000 is the computer name of the machine SQL Server is running on and myadminuser is a user in the administrators group on that machine. I provided the password for that account (I know that it is the correct password as I use RDP to connect to that machine to play remotely on the SQL side as needed)
My connection string in MS SQL Server Management Studio Express for 'Server name:' is set to:
tcp:mysql.myip.com\mysqlinstancename,1433 and know this is working since I can use SQL Auth and connect without issue.
From what I understand the above is an auth issue and not a SQL login issue, but what else can I try?
</edited>
Best Regards.
|||No, it's not a GUI issue - that's an odd form of that error, though. It should have had a user name variable. Which OS are you on?
1. Yes - as long as you follow basic security checklists you should be fine. There are lots of security resources for SQL 2K5, just search for those. Basically it is applying service packs, no blank passwords, don't enable bad things, and so on. The Best Practices Analyzer (BPA) will also check some security basics for you.
2. That I have not done. Are you trying to run SSMS as an application? I would recommend managing the system uing RDP and only hit the database through applications - that's the normal management profile.
|||Thanks for the quick reply.
Today I tested from a different machine at my company versus from a machine at home.
All machines involved have been WinXP 2002 SP2 boxes.
1. Will do, I have implemented a good security approach that I acquired doing my last 4 days of research.
2. I am running it as a remote app, trying to connect from my company back to my test SQL Server 2K5 Express install back home. I right click on the 'SQL Server Management Studio Express' shortcut under Start|Programs|Microsoft SQL Server 2005, choose 'Run As', type in the info and it starts up and the rest is as I've described - User name field in studio has my local machine name\user name and not what I've supplied. Ultimately, I can live with managing it via RDP, but can't see any reason why remote management would not work. Wouldn't remote management be more efficient as well as now it is just an app sending/receiving data versus the RDP session having to maintain sending/receiving screen updates (even if I reduce what is updated - i.e. Desktop background, themes, etc)?
Once again thank you for your assitance.
Best Regards,
DOD
|||On number two, there are lots of arguments on both sides. RDP is actually pretty light from a traffic persepctive, especially if you follow a best-practice for setting no themes on servers and using a plain black background. For truly light management, use PowerShell or sqlcmd.
- Buck
|||Don't mean to belabor the point, but do you have any other suggestions regarding connecting remotely into MS SQL Server 2K5 Express. Is there anything I could have missed in the blog trail above?
The most suspect thing to me is the fact that when I start up Studio using the Run As as discussed, it doesn't show me the computer\user that I input but rather the locally logged in credentials...have you seen this before in the workgroup auth you have used successfully in the past? Seems to me that if it is still using the logged in creds, the error would be expected...if this is the case, what's up with the Run As command or the support of it in Studio?
Cheers.
Can''t connect to MSDE
I opened the port for SQL Server 1433, and MSDE port 1503(get from registry) in the Windows Firewall, and enable DISABLENETWORKPROTOCOLS=0 for MSDE.
I can connect to SQL Server and MSDE in the local server, and can connect to the SQL Server in another machine(ClientA) from Visual Studio .Net and SQL Sever authentication. but can't connect to the MSDE from another machine(ClientA) in Visual Studio .Net by SQL Server Authentication. The visual studio .net can't detect the MSDE instance automatically.
BTW, both the server and ClientA are in the same Workgroug, no domain defined.
I think, this should be something about configuration. Any clue? Thanks very much.
If you're using local security on each machine (because you're in a workgroup) then Windows security probably won't work the way you think it is working. In a domain called DomainA, the account UserA is known as DomainA\UserA. Since all the servers joined to that domain see the same security, they all view this person as DomainA\UserA. Since you don't have a domain, each server has it's own security, meaning that an account created and named on each machine as UserA would be known as ServerA\UserA and ServerB\UserA. These are two different accounts.
So the point is that when SQL Server on ServerA is set to use Integrated security, the only accounts it knows about are ServerA, not Server B. When you log on to a system as ServerB\UserA, the SQL Server does not know who you are.
Now, since you are stating that you are using mixed authentication, you shouldn't have the problem. In fact, you state that you can log on using a tool other than SQL Server from any system in the workgroup, as long as you use a SQL Server account. So this leads me to think that your connection string is trying to use a Windows account to connect. That's where you should start looking.
|||Ok, I have spent the last 3 days trying to do research on SQL Server 2K5 Express connectivity and have not found any definite answers as to what I need to do to solve the problem.
Background:
Client: WinXP Pro 2002 SP2 running MS SQL Server Management Studio Express
Server: WinXP Pro 2002 SP2 running MS SQL Server 2005 Express configured for mixed authentication.
Both machines not on domains but share a common workgroup.
Windows firewalls on these machines disabled. Router firewall opened port 1433 to server. I am connecting from Client to Server by hitting the router IP and coming back in through port forwarding since my clients will have to be hitting my server through my router. Connectivity of the 2 machines is fine as I can telnet from one to the other on 1433 without issue when first stopping SQL Server of course.
Requirement: Connecting the two using Windows Authentication and TCP protocol to MS SQL Server. Ultimately, I am doing this to have clients connect into my server withoug having to be part of my domain/workgroup.
Server name in studio set to: tcp:www.myserver.org\sqlinstance,1433
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now I have read some articles implying that this should be possible using 'workgroup authentication' so I tried that - basically ensuring that identical accounts are set up on both machines with the same passwords - I know this is working since I can transparently (no login required) map shares from one to other. This however still left me with the above error. I am assuming mapped drives used named pipes so this doesn't prove much when I am using Studio to connect via TCP.
For later reference, lets say the client machine is named CLIENT and the server is named SERVER and the common username is USERNAME and common password of PASSWORD.
I read an article stipulating that the authentication is domain based so that machine SERVER would receive an authentication SID (terminology may be wrong here) of CLIENT\USERNAME but since neither machine is on a domain SERVER could not validate the credentials on CLIENT and so it cannot work.
But yet another article said it can...go into Start|Settings|Control Panel|User Accounts and make click on 'Manage my network password' and make a new entry for the server and enter the username as it is required on the server...so I created one as follows:
Server: SERVER
User Name: USERNAME
Password: PASSWORD
...but received the same error.
If I use SQL Server Authentication it works fine...but my readings have shown that SQL Server Authentication is not all that secure (but in fairness don't know if most of the articles I read this in were talking about previous versions of MS SQL Server 2005).
So my questions:
1) Is SQL Server Authentication in MS SQL Server 2005 secure (maybe not as secure as Windows Auth, but secure enough to trust sensitive information to?)
2) Is it possible to use Windows Authentication between 2 machines separated by the internet and not part of domains? If so, what are the requirements for this? Common accounts/passwords? Common Workgroup? etc...
3) If 2) isn't possible does that imply that I need an OS that can act as a domain controller just to host my SQL Server? If so, could I then 'Manage my network password' on any client that needs to connect and have it provide correct domain\user info to the domain controller thereby avoiding having to join the domain to connect to the SQL Server - keep in mind the ultimate goal here is to have clients connect into my SQL Server via the internet where they won't be part of my domain and/or possibly can not be made part of my workgroup.
Thanks so much for any help you can provide.
Best Regards,
DOD
|||Good Questions - Hopefully I can help clear these up a little.
1. SQL Auth is very secure. In SQL 2K5, if you're using Win 2K3, you can even tie some of the Win2K3 policies (password change, length, etc.) to SQL Server Accounts. The rest of these answers is only for Windows Auth. For SQL Server Auth you can just connect using the name and account pair.
2. Management Studio uses your current account to connect - that's by design. If your account can be seen/trusted by the other system, you're in. If not, right-click Management Studio and select "Run As" if you're using XP. Then you can provide a domain/user pair.
You can definitely connect without common domains through any application by providing a connection string. You can also do this with any of the command-line utility such as sqlcmd, since you provide a connection string. Books Online has more about sqlcmd.
3. Not at all. Windows Security is a big subject, but the point is that you just need to determine what the server needs to see. I run several SQL Servers with Local (Workgroup) security.
- Buck
|||Thank you SOOOO much...it's nice to have an authority on the matter give a 'matter of fact' response!
Just a couple more questions regarding the above...
1) Given that I will not be running Win2K3 in the shortterm, but hosting SQL Server on a WinXP 2002 SP2 box, is SQL Auth in SQL Server 2K5 is inherently secure enough for sensitive business information when not tying into OS security policy functionality?
2) Is there any way to have an app always ran under different credentials (to avoid having to select Run As from the context menu each time) via some shortcut property, registry modification, or something else?
Once again, thanks in advance...I spent literally days researching this but because of my security concerns hadn't found what I considered a consistent and direct answer to the above.
<edited>
I just tried using the Run As and get the same error:
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Interesting that in the username field it still shows my local workgroup\logged in user versus what I set up in the Run As dialog. Is this just a bug in that the GUI does not reflect the Run As parameters or is it in fact just always using the logged in user?
I can connect using SQL Auth, so know without question that firewall settings are not an issue. I specified the user as:
WXP-P2000\myadminuser where WXP-P2000 is the computer name of the machine SQL Server is running on and myadminuser is a user in the administrators group on that machine. I provided the password for that account (I know that it is the correct password as I use RDP to connect to that machine to play remotely on the SQL side as needed)
My connection string in MS SQL Server Management Studio Express for 'Server name:' is set to:
tcp:mysql.myip.com\mysqlinstancename,1433 and know this is working since I can use SQL Auth and connect without issue.
From what I understand the above is an auth issue and not a SQL login issue, but what else can I try?
</edited>
Best Regards.
|||No, it's not a GUI issue - that's an odd form of that error, though. It should have had a user name variable. Which OS are you on?
1. Yes - as long as you follow basic security checklists you should be fine. There are lots of security resources for SQL 2K5, just search for those. Basically it is applying service packs, no blank passwords, don't enable bad things, and so on. The Best Practices Analyzer (BPA) will also check some security basics for you.
2. That I have not done. Are you trying to run SSMS as an application? I would recommend managing the system uing RDP and only hit the database through applications - that's the normal management profile.
|||Thanks for the quick reply.
Today I tested from a different machine at my company versus from a machine at home.
All machines involved have been WinXP 2002 SP2 boxes.
1. Will do, I have implemented a good security approach that I acquired doing my last 4 days of research.
2. I am running it as a remote app, trying to connect from my company back to my test SQL Server 2K5 Express install back home. I right click on the 'SQL Server Management Studio Express' shortcut under Start|Programs|Microsoft SQL Server 2005, choose 'Run As', type in the info and it starts up and the rest is as I've described - User name field in studio has my local machine name\user name and not what I've supplied. Ultimately, I can live with managing it via RDP, but can't see any reason why remote management would not work. Wouldn't remote management be more efficient as well as now it is just an app sending/receiving data versus the RDP session having to maintain sending/receiving screen updates (even if I reduce what is updated - i.e. Desktop background, themes, etc)?
Once again thank you for your assitance.
Best Regards,
DOD
|||On number two, there are lots of arguments on both sides. RDP is actually pretty light from a traffic persepctive, especially if you follow a best-practice for setting no themes on servers and using a plain black background. For truly light management, use PowerShell or sqlcmd.
- Buck
|||Don't mean to belabor the point, but do you have any other suggestions regarding connecting remotely into MS SQL Server 2K5 Express. Is there anything I could have missed in the blog trail above?
The most suspect thing to me is the fact that when I start up Studio using the Run As as discussed, it doesn't show me the computer\user that I input but rather the locally logged in credentials...have you seen this before in the workgroup auth you have used successfully in the past? Seems to me that if it is still using the logged in creds, the error would be expected...if this is the case, what's up with the Run As command or the support of it in Studio?
Cheers.
Can''t connect to MSDE
I opened the port for SQL Server 1433, and MSDE port 1503(get from registry) in the Windows Firewall, and enable DISABLENETWORKPROTOCOLS=0 for MSDE.
I can connect to SQL Server and MSDE in the local server, and can connect to the SQL Server in another machine(ClientA) from Visual Studio .Net and SQL Sever authentication. but can't connect to the MSDE from another machine(ClientA) in Visual Studio .Net by SQL Server Authentication. The visual studio .net can't detect the MSDE instance automatically.
BTW, both the server and ClientA are in the same Workgroug, no domain defined.
I think, this should be something about configuration. Any clue? Thanks very much.
If you're using local security on each machine (because you're in a workgroup) then Windows security probably won't work the way you think it is working. In a domain called DomainA, the account UserA is known as DomainA\UserA. Since all the servers joined to that domain see the same security, they all view this person as DomainA\UserA. Since you don't have a domain, each server has it's own security, meaning that an account created and named on each machine as UserA would be known as ServerA\UserA and ServerB\UserA. These are two different accounts.
So the point is that when SQL Server on ServerA is set to use Integrated security, the only accounts it knows about are ServerA, not Server B. When you log on to a system as ServerB\UserA, the SQL Server does not know who you are.
Now, since you are stating that you are using mixed authentication, you shouldn't have the problem. In fact, you state that you can log on using a tool other than SQL Server from any system in the workgroup, as long as you use a SQL Server account. So this leads me to think that your connection string is trying to use a Windows account to connect. That's where you should start looking.
|||Ok, I have spent the last 3 days trying to do research on SQL Server 2K5 Express connectivity and have not found any definite answers as to what I need to do to solve the problem.
Background:
Client: WinXP Pro 2002 SP2 running MS SQL Server Management Studio Express
Server: WinXP Pro 2002 SP2 running MS SQL Server 2005 Express configured for mixed authentication.
Both machines not on domains but share a common workgroup.
Windows firewalls on these machines disabled. Router firewall opened port 1433 to server. I am connecting from Client to Server by hitting the router IP and coming back in through port forwarding since my clients will have to be hitting my server through my router. Connectivity of the 2 machines is fine as I can telnet from one to the other on 1433 without issue when first stopping SQL Server of course.
Requirement: Connecting the two using Windows Authentication and TCP protocol to MS SQL Server. Ultimately, I am doing this to have clients connect into my server withoug having to be part of my domain/workgroup.
Server name in studio set to: tcp:www.myserver.org\sqlinstance,1433
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now I have read some articles implying that this should be possible using 'workgroup authentication' so I tried that - basically ensuring that identical accounts are set up on both machines with the same passwords - I know this is working since I can transparently (no login required) map shares from one to other. This however still left me with the above error. I am assuming mapped drives used named pipes so this doesn't prove much when I am using Studio to connect via TCP.
For later reference, lets say the client machine is named CLIENT and the server is named SERVER and the common username is USERNAME and common password of PASSWORD.
I read an article stipulating that the authentication is domain based so that machine SERVER would receive an authentication SID (terminology may be wrong here) of CLIENT\USERNAME but since neither machine is on a domain SERVER could not validate the credentials on CLIENT and so it cannot work.
But yet another article said it can...go into Start|Settings|Control Panel|User Accounts and make click on 'Manage my network password' and make a new entry for the server and enter the username as it is required on the server...so I created one as follows:
Server: SERVER
User Name: USERNAME
Password: PASSWORD
...but received the same error.
If I use SQL Server Authentication it works fine...but my readings have shown that SQL Server Authentication is not all that secure (but in fairness don't know if most of the articles I read this in were talking about previous versions of MS SQL Server 2005).
So my questions:
1) Is SQL Server Authentication in MS SQL Server 2005 secure (maybe not as secure as Windows Auth, but secure enough to trust sensitive information to?)
2) Is it possible to use Windows Authentication between 2 machines separated by the internet and not part of domains? If so, what are the requirements for this? Common accounts/passwords? Common Workgroup? etc...
3) If 2) isn't possible does that imply that I need an OS that can act as a domain controller just to host my SQL Server? If so, could I then 'Manage my network password' on any client that needs to connect and have it provide correct domain\user info to the domain controller thereby avoiding having to join the domain to connect to the SQL Server - keep in mind the ultimate goal here is to have clients connect into my SQL Server via the internet where they won't be part of my domain and/or possibly can not be made part of my workgroup.
Thanks so much for any help you can provide.
Best Regards,
DOD
|||Good Questions - Hopefully I can help clear these up a little.
1. SQL Auth is very secure. In SQL 2K5, if you're using Win 2K3, you can even tie some of the Win2K3 policies (password change, length, etc.) to SQL Server Accounts. The rest of these answers is only for Windows Auth. For SQL Server Auth you can just connect using the name and account pair.
2. Management Studio uses your current account to connect - that's by design. If your account can be seen/trusted by the other system, you're in. If not, right-click Management Studio and select "Run As" if you're using XP. Then you can provide a domain/user pair.
You can definitely connect without common domains through any application by providing a connection string. You can also do this with any of the command-line utility such as sqlcmd, since you provide a connection string. Books Online has more about sqlcmd.
3. Not at all. Windows Security is a big subject, but the point is that you just need to determine what the server needs to see. I run several SQL Servers with Local (Workgroup) security.
- Buck
|||Thank you SOOOO much...it's nice to have an authority on the matter give a 'matter of fact' response!
Just a couple more questions regarding the above...
1) Given that I will not be running Win2K3 in the shortterm, but hosting SQL Server on a WinXP 2002 SP2 box, is SQL Auth in SQL Server 2K5 is inherently secure enough for sensitive business information when not tying into OS security policy functionality?
2) Is there any way to have an app always ran under different credentials (to avoid having to select Run As from the context menu each time) via some shortcut property, registry modification, or something else?
Once again, thanks in advance...I spent literally days researching this but because of my security concerns hadn't found what I considered a consistent and direct answer to the above.
<edited>
I just tried using the Run As and get the same error:
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Interesting that in the username field it still shows my local workgroup\logged in user versus what I set up in the Run As dialog. Is this just a bug in that the GUI does not reflect the Run As parameters or is it in fact just always using the logged in user?
I can connect using SQL Auth, so know without question that firewall settings are not an issue. I specified the user as:
WXP-P2000\myadminuser where WXP-P2000 is the computer name of the machine SQL Server is running on and myadminuser is a user in the administrators group on that machine. I provided the password for that account (I know that it is the correct password as I use RDP to connect to that machine to play remotely on the SQL side as needed)
My connection string in MS SQL Server Management Studio Express for 'Server name:' is set to:
tcp:mysql.myip.com\mysqlinstancename,1433 and know this is working since I can use SQL Auth and connect without issue.
From what I understand the above is an auth issue and not a SQL login issue, but what else can I try?
</edited>
Best Regards.
|||No, it's not a GUI issue - that's an odd form of that error, though. It should have had a user name variable. Which OS are you on?
1. Yes - as long as you follow basic security checklists you should be fine. There are lots of security resources for SQL 2K5, just search for those. Basically it is applying service packs, no blank passwords, don't enable bad things, and so on. The Best Practices Analyzer (BPA) will also check some security basics for you.
2. That I have not done. Are you trying to run SSMS as an application? I would recommend managing the system uing RDP and only hit the database through applications - that's the normal management profile.
|||Thanks for the quick reply.
Today I tested from a different machine at my company versus from a machine at home.
All machines involved have been WinXP 2002 SP2 boxes.
1. Will do, I have implemented a good security approach that I acquired doing my last 4 days of research.
2. I am running it as a remote app, trying to connect from my company back to my test SQL Server 2K5 Express install back home. I right click on the 'SQL Server Management Studio Express' shortcut under Start|Programs|Microsoft SQL Server 2005, choose 'Run As', type in the info and it starts up and the rest is as I've described - User name field in studio has my local machine name\user name and not what I've supplied. Ultimately, I can live with managing it via RDP, but can't see any reason why remote management would not work. Wouldn't remote management be more efficient as well as now it is just an app sending/receiving data versus the RDP session having to maintain sending/receiving screen updates (even if I reduce what is updated - i.e. Desktop background, themes, etc)?
Once again thank you for your assitance.
Best Regards,
DOD
|||On number two, there are lots of arguments on both sides. RDP is actually pretty light from a traffic persepctive, especially if you follow a best-practice for setting no themes on servers and using a plain black background. For truly light management, use PowerShell or sqlcmd.
- Buck
|||Don't mean to belabor the point, but do you have any other suggestions regarding connecting remotely into MS SQL Server 2K5 Express. Is there anything I could have missed in the blog trail above?
The most suspect thing to me is the fact that when I start up Studio using the Run As as discussed, it doesn't show me the computer\user that I input but rather the locally logged in credentials...have you seen this before in the workgroup auth you have used successfully in the past? Seems to me that if it is still using the logged in creds, the error would be expected...if this is the case, what's up with the Run As command or the support of it in Studio?
Cheers.
Can''t connect to MSDE
I opened the port for SQL Server 1433, and MSDE port 1503(get from registry) in the Windows Firewall, and enable DISABLENETWORKPROTOCOLS=0 for MSDE.
I can connect to SQL Server and MSDE in the local server, and can connect to the SQL Server in another machine(ClientA) from Visual Studio .Net and SQL Sever authentication. but can't connect to the MSDE from another machine(ClientA) in Visual Studio .Net by SQL Server Authentication. The visual studio .net can't detect the MSDE instance automatically.
BTW, both the server and ClientA are in the same Workgroug, no domain defined.
I think, this should be something about configuration. Any clue? Thanks very much.
If you're using local security on each machine (because you're in a workgroup) then Windows security probably won't work the way you think it is working. In a domain called DomainA, the account UserA is known as DomainA\UserA. Since all the servers joined to that domain see the same security, they all view this person as DomainA\UserA. Since you don't have a domain, each server has it's own security, meaning that an account created and named on each machine as UserA would be known as ServerA\UserA and ServerB\UserA. These are two different accounts.
So the point is that when SQL Server on ServerA is set to use Integrated security, the only accounts it knows about are ServerA, not Server B. When you log on to a system as ServerB\UserA, the SQL Server does not know who you are.
Now, since you are stating that you are using mixed authentication, you shouldn't have the problem. In fact, you state that you can log on using a tool other than SQL Server from any system in the workgroup, as long as you use a SQL Server account. So this leads me to think that your connection string is trying to use a Windows account to connect. That's where you should start looking.
|||Ok, I have spent the last 3 days trying to do research on SQL Server 2K5 Express connectivity and have not found any definite answers as to what I need to do to solve the problem.
Background:
Client: WinXP Pro 2002 SP2 running MS SQL Server Management Studio Express
Server: WinXP Pro 2002 SP2 running MS SQL Server 2005 Express configured for mixed authentication.
Both machines not on domains but share a common workgroup.
Windows firewalls on these machines disabled. Router firewall opened port 1433 to server. I am connecting from Client to Server by hitting the router IP and coming back in through port forwarding since my clients will have to be hitting my server through my router. Connectivity of the 2 machines is fine as I can telnet from one to the other on 1433 without issue when first stopping SQL Server of course.
Requirement: Connecting the two using Windows Authentication and TCP protocol to MS SQL Server. Ultimately, I am doing this to have clients connect into my server withoug having to be part of my domain/workgroup.
Server name in studio set to: tcp:www.myserver.org\sqlinstance,1433
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now I have read some articles implying that this should be possible using 'workgroup authentication' so I tried that - basically ensuring that identical accounts are set up on both machines with the same passwords - I know this is working since I can transparently (no login required) map shares from one to other. This however still left me with the above error. I am assuming mapped drives used named pipes so this doesn't prove much when I am using Studio to connect via TCP.
For later reference, lets say the client machine is named CLIENT and the server is named SERVER and the common username is USERNAME and common password of PASSWORD.
I read an article stipulating that the authentication is domain based so that machine SERVER would receive an authentication SID (terminology may be wrong here) of CLIENT\USERNAME but since neither machine is on a domain SERVER could not validate the credentials on CLIENT and so it cannot work.
But yet another article said it can...go into Start|Settings|Control Panel|User Accounts and make click on 'Manage my network password' and make a new entry for the server and enter the username as it is required on the server...so I created one as follows:
Server: SERVER
User Name: USERNAME
Password: PASSWORD
...but received the same error.
If I use SQL Server Authentication it works fine...but my readings have shown that SQL Server Authentication is not all that secure (but in fairness don't know if most of the articles I read this in were talking about previous versions of MS SQL Server 2005).
So my questions:
1) Is SQL Server Authentication in MS SQL Server 2005 secure (maybe not as secure as Windows Auth, but secure enough to trust sensitive information to?)
2) Is it possible to use Windows Authentication between 2 machines separated by the internet and not part of domains? If so, what are the requirements for this? Common accounts/passwords? Common Workgroup? etc...
3) If 2) isn't possible does that imply that I need an OS that can act as a domain controller just to host my SQL Server? If so, could I then 'Manage my network password' on any client that needs to connect and have it provide correct domain\user info to the domain controller thereby avoiding having to join the domain to connect to the SQL Server - keep in mind the ultimate goal here is to have clients connect into my SQL Server via the internet where they won't be part of my domain and/or possibly can not be made part of my workgroup.
Thanks so much for any help you can provide.
Best Regards,
DOD
|||Good Questions - Hopefully I can help clear these up a little.
1. SQL Auth is very secure. In SQL 2K5, if you're using Win 2K3, you can even tie some of the Win2K3 policies (password change, length, etc.) to SQL Server Accounts. The rest of these answers is only for Windows Auth. For SQL Server Auth you can just connect using the name and account pair.
2. Management Studio uses your current account to connect - that's by design. If your account can be seen/trusted by the other system, you're in. If not, right-click Management Studio and select "Run As" if you're using XP. Then you can provide a domain/user pair.
You can definitely connect without common domains through any application by providing a connection string. You can also do this with any of the command-line utility such as sqlcmd, since you provide a connection string. Books Online has more about sqlcmd.
3. Not at all. Windows Security is a big subject, but the point is that you just need to determine what the server needs to see. I run several SQL Servers with Local (Workgroup) security.
- Buck
|||Thank you SOOOO much...it's nice to have an authority on the matter give a 'matter of fact' response!
Just a couple more questions regarding the above...
1) Given that I will not be running Win2K3 in the shortterm, but hosting SQL Server on a WinXP 2002 SP2 box, is SQL Auth in SQL Server 2K5 is inherently secure enough for sensitive business information when not tying into OS security policy functionality?
2) Is there any way to have an app always ran under different credentials (to avoid having to select Run As from the context menu each time) via some shortcut property, registry modification, or something else?
Once again, thanks in advance...I spent literally days researching this but because of my security concerns hadn't found what I considered a consistent and direct answer to the above.
<edited>
I just tried using the Run As and get the same error:
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Interesting that in the username field it still shows my local workgroup\logged in user versus what I set up in the Run As dialog. Is this just a bug in that the GUI does not reflect the Run As parameters or is it in fact just always using the logged in user?
I can connect using SQL Auth, so know without question that firewall settings are not an issue. I specified the user as:
WXP-P2000\myadminuser where WXP-P2000 is the computer name of the machine SQL Server is running on and myadminuser is a user in the administrators group on that machine. I provided the password for that account (I know that it is the correct password as I use RDP to connect to that machine to play remotely on the SQL side as needed)
My connection string in MS SQL Server Management Studio Express for 'Server name:' is set to:
tcp:mysql.myip.com\mysqlinstancename,1433 and know this is working since I can use SQL Auth and connect without issue.
From what I understand the above is an auth issue and not a SQL login issue, but what else can I try?
</edited>
Best Regards.
|||No, it's not a GUI issue - that's an odd form of that error, though. It should have had a user name variable. Which OS are you on?
1. Yes - as long as you follow basic security checklists you should be fine. There are lots of security resources for SQL 2K5, just search for those. Basically it is applying service packs, no blank passwords, don't enable bad things, and so on. The Best Practices Analyzer (BPA) will also check some security basics for you.
2. That I have not done. Are you trying to run SSMS as an application? I would recommend managing the system uing RDP and only hit the database through applications - that's the normal management profile.
|||Thanks for the quick reply.
Today I tested from a different machine at my company versus from a machine at home.
All machines involved have been WinXP 2002 SP2 boxes.
1. Will do, I have implemented a good security approach that I acquired doing my last 4 days of research.
2. I am running it as a remote app, trying to connect from my company back to my test SQL Server 2K5 Express install back home. I right click on the 'SQL Server Management Studio Express' shortcut under Start|Programs|Microsoft SQL Server 2005, choose 'Run As', type in the info and it starts up and the rest is as I've described - User name field in studio has my local machine name\user name and not what I've supplied. Ultimately, I can live with managing it via RDP, but can't see any reason why remote management would not work. Wouldn't remote management be more efficient as well as now it is just an app sending/receiving data versus the RDP session having to maintain sending/receiving screen updates (even if I reduce what is updated - i.e. Desktop background, themes, etc)?
Once again thank you for your assitance.
Best Regards,
DOD
|||On number two, there are lots of arguments on both sides. RDP is actually pretty light from a traffic persepctive, especially if you follow a best-practice for setting no themes on servers and using a plain black background. For truly light management, use PowerShell or sqlcmd.
- Buck
|||Don't mean to belabor the point, but do you have any other suggestions regarding connecting remotely into MS SQL Server 2K5 Express. Is there anything I could have missed in the blog trail above?
The most suspect thing to me is the fact that when I start up Studio using the Run As as discussed, it doesn't show me the computer\user that I input but rather the locally logged in credentials...have you seen this before in the workgroup auth you have used successfully in the past? Seems to me that if it is still using the logged in creds, the error would be expected...if this is the case, what's up with the Run As command or the support of it in Studio?
Cheers.
Can''t connect to MSDE
I opened the port for SQL Server 1433, and MSDE port 1503(get from registry) in the Windows Firewall, and enable DISABLENETWORKPROTOCOLS=0 for MSDE.
I can connect to SQL Server and MSDE in the local server, and can connect to the SQL Server in another machine(ClientA) from Visual Studio .Net and SQL Sever authentication. but can't connect to the MSDE from another machine(ClientA) in Visual Studio .Net by SQL Server Authentication. The visual studio .net can't detect the MSDE instance automatically.
BTW, both the server and ClientA are in the same Workgroug, no domain defined.
I think, this should be something about configuration. Any clue? Thanks very much.
If you're using local security on each machine (because you're in a workgroup) then Windows security probably won't work the way you think it is working. In a domain called DomainA, the account UserA is known as DomainA\UserA. Since all the servers joined to that domain see the same security, they all view this person as DomainA\UserA. Since you don't have a domain, each server has it's own security, meaning that an account created and named on each machine as UserA would be known as ServerA\UserA and ServerB\UserA. These are two different accounts.
So the point is that when SQL Server on ServerA is set to use Integrated security, the only accounts it knows about are ServerA, not Server B. When you log on to a system as ServerB\UserA, the SQL Server does not know who you are.
Now, since you are stating that you are using mixed authentication, you shouldn't have the problem. In fact, you state that you can log on using a tool other than SQL Server from any system in the workgroup, as long as you use a SQL Server account. So this leads me to think that your connection string is trying to use a Windows account to connect. That's where you should start looking.
|||Ok, I have spent the last 3 days trying to do research on SQL Server 2K5 Express connectivity and have not found any definite answers as to what I need to do to solve the problem.
Background:
Client: WinXP Pro 2002 SP2 running MS SQL Server Management Studio Express
Server: WinXP Pro 2002 SP2 running MS SQL Server 2005 Express configured for mixed authentication.
Both machines not on domains but share a common workgroup.
Windows firewalls on these machines disabled. Router firewall opened port 1433 to server. I am connecting from Client to Server by hitting the router IP and coming back in through port forwarding since my clients will have to be hitting my server through my router. Connectivity of the 2 machines is fine as I can telnet from one to the other on 1433 without issue when first stopping SQL Server of course.
Requirement: Connecting the two using Windows Authentication and TCP protocol to MS SQL Server. Ultimately, I am doing this to have clients connect into my server withoug having to be part of my domain/workgroup.
Server name in studio set to: tcp:www.myserver.org\sqlinstance,1433
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now I have read some articles implying that this should be possible using 'workgroup authentication' so I tried that - basically ensuring that identical accounts are set up on both machines with the same passwords - I know this is working since I can transparently (no login required) map shares from one to other. This however still left me with the above error. I am assuming mapped drives used named pipes so this doesn't prove much when I am using Studio to connect via TCP.
For later reference, lets say the client machine is named CLIENT and the server is named SERVER and the common username is USERNAME and common password of PASSWORD.
I read an article stipulating that the authentication is domain based so that machine SERVER would receive an authentication SID (terminology may be wrong here) of CLIENT\USERNAME but since neither machine is on a domain SERVER could not validate the credentials on CLIENT and so it cannot work.
But yet another article said it can...go into Start|Settings|Control Panel|User Accounts and make click on 'Manage my network password' and make a new entry for the server and enter the username as it is required on the server...so I created one as follows:
Server: SERVER
User Name: USERNAME
Password: PASSWORD
...but received the same error.
If I use SQL Server Authentication it works fine...but my readings have shown that SQL Server Authentication is not all that secure (but in fairness don't know if most of the articles I read this in were talking about previous versions of MS SQL Server 2005).
So my questions:
1) Is SQL Server Authentication in MS SQL Server 2005 secure (maybe not as secure as Windows Auth, but secure enough to trust sensitive information to?)
2) Is it possible to use Windows Authentication between 2 machines separated by the internet and not part of domains? If so, what are the requirements for this? Common accounts/passwords? Common Workgroup? etc...
3) If 2) isn't possible does that imply that I need an OS that can act as a domain controller just to host my SQL Server? If so, could I then 'Manage my network password' on any client that needs to connect and have it provide correct domain\user info to the domain controller thereby avoiding having to join the domain to connect to the SQL Server - keep in mind the ultimate goal here is to have clients connect into my SQL Server via the internet where they won't be part of my domain and/or possibly can not be made part of my workgroup.
Thanks so much for any help you can provide.
Best Regards,
DOD
|||Good Questions - Hopefully I can help clear these up a little.
1. SQL Auth is very secure. In SQL 2K5, if you're using Win 2K3, you can even tie some of the Win2K3 policies (password change, length, etc.) to SQL Server Accounts. The rest of these answers is only for Windows Auth. For SQL Server Auth you can just connect using the name and account pair.
2. Management Studio uses your current account to connect - that's by design. If your account can be seen/trusted by the other system, you're in. If not, right-click Management Studio and select "Run As" if you're using XP. Then you can provide a domain/user pair.
You can definitely connect without common domains through any application by providing a connection string. You can also do this with any of the command-line utility such as sqlcmd, since you provide a connection string. Books Online has more about sqlcmd.
3. Not at all. Windows Security is a big subject, but the point is that you just need to determine what the server needs to see. I run several SQL Servers with Local (Workgroup) security.
- Buck
|||Thank you SOOOO much...it's nice to have an authority on the matter give a 'matter of fact' response!
Just a couple more questions regarding the above...
1) Given that I will not be running Win2K3 in the shortterm, but hosting SQL Server on a WinXP 2002 SP2 box, is SQL Auth in SQL Server 2K5 is inherently secure enough for sensitive business information when not tying into OS security policy functionality?
2) Is there any way to have an app always ran under different credentials (to avoid having to select Run As from the context menu each time) via some shortcut property, registry modification, or something else?
Once again, thanks in advance...I spent literally days researching this but because of my security concerns hadn't found what I considered a consistent and direct answer to the above.
<edited>
I just tried using the Run As and get the same error:
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Interesting that in the username field it still shows my local workgroup\logged in user versus what I set up in the Run As dialog. Is this just a bug in that the GUI does not reflect the Run As parameters or is it in fact just always using the logged in user?
I can connect using SQL Auth, so know without question that firewall settings are not an issue. I specified the user as:
WXP-P2000\myadminuser where WXP-P2000 is the computer name of the machine SQL Server is running on and myadminuser is a user in the administrators group on that machine. I provided the password for that account (I know that it is the correct password as I use RDP to connect to that machine to play remotely on the SQL side as needed)
My connection string in MS SQL Server Management Studio Express for 'Server name:' is set to:
tcp:mysql.myip.com\mysqlinstancename,1433 and know this is working since I can use SQL Auth and connect without issue.
From what I understand the above is an auth issue and not a SQL login issue, but what else can I try?
</edited>
Best Regards.
|||No, it's not a GUI issue - that's an odd form of that error, though. It should have had a user name variable. Which OS are you on?
1. Yes - as long as you follow basic security checklists you should be fine. There are lots of security resources for SQL 2K5, just search for those. Basically it is applying service packs, no blank passwords, don't enable bad things, and so on. The Best Practices Analyzer (BPA) will also check some security basics for you.
2. That I have not done. Are you trying to run SSMS as an application? I would recommend managing the system uing RDP and only hit the database through applications - that's the normal management profile.
|||Thanks for the quick reply.
Today I tested from a different machine at my company versus from a machine at home.
All machines involved have been WinXP 2002 SP2 boxes.
1. Will do, I have implemented a good security approach that I acquired doing my last 4 days of research.
2. I am running it as a remote app, trying to connect from my company back to my test SQL Server 2K5 Express install back home. I right click on the 'SQL Server Management Studio Express' shortcut under Start|Programs|Microsoft SQL Server 2005, choose 'Run As', type in the info and it starts up and the rest is as I've described - User name field in studio has my local machine name\user name and not what I've supplied. Ultimately, I can live with managing it via RDP, but can't see any reason why remote management would not work. Wouldn't remote management be more efficient as well as now it is just an app sending/receiving data versus the RDP session having to maintain sending/receiving screen updates (even if I reduce what is updated - i.e. Desktop background, themes, etc)?
Once again thank you for your assitance.
Best Regards,
DOD
|||On number two, there are lots of arguments on both sides. RDP is actually pretty light from a traffic persepctive, especially if you follow a best-practice for setting no themes on servers and using a plain black background. For truly light management, use PowerShell or sqlcmd.
- Buck
|||Don't mean to belabor the point, but do you have any other suggestions regarding connecting remotely into MS SQL Server 2K5 Express. Is there anything I could have missed in the blog trail above?
The most suspect thing to me is the fact that when I start up Studio using the Run As as discussed, it doesn't show me the computer\user that I input but rather the locally logged in credentials...have you seen this before in the workgroup auth you have used successfully in the past? Seems to me that if it is still using the logged in creds, the error would be expected...if this is the case, what's up with the Run As command or the support of it in Studio?
Cheers.
Can''t connect to MSDE
I opened the port for SQL Server 1433, and MSDE port 1503(get from registry) in the Windows Firewall, and enable DISABLENETWORKPROTOCOLS=0 for MSDE.
I can connect to SQL Server and MSDE in the local server, and can connect to the SQL Server in another machine(ClientA) from Visual Studio .Net and SQL Sever authentication. but can't connect to the MSDE from another machine(ClientA) in Visual Studio .Net by SQL Server Authentication. The visual studio .net can't detect the MSDE instance automatically.
BTW, both the server and ClientA are in the same Workgroug, no domain defined.
I think, this should be something about configuration. Any clue? Thanks very much.
If you're using local security on each machine (because you're in a workgroup) then Windows security probably won't work the way you think it is working. In a domain called DomainA, the account UserA is known as DomainA\UserA. Since all the servers joined to that domain see the same security, they all view this person as DomainA\UserA. Since you don't have a domain, each server has it's own security, meaning that an account created and named on each machine as UserA would be known as ServerA\UserA and ServerB\UserA. These are two different accounts.
So the point is that when SQL Server on ServerA is set to use Integrated security, the only accounts it knows about are ServerA, not Server B. When you log on to a system as ServerB\UserA, the SQL Server does not know who you are.
Now, since you are stating that you are using mixed authentication, you shouldn't have the problem. In fact, you state that you can log on using a tool other than SQL Server from any system in the workgroup, as long as you use a SQL Server account. So this leads me to think that your connection string is trying to use a Windows account to connect. That's where you should start looking.
|||Ok, I have spent the last 3 days trying to do research on SQL Server 2K5 Express connectivity and have not found any definite answers as to what I need to do to solve the problem.
Background:
Client: WinXP Pro 2002 SP2 running MS SQL Server Management Studio Express
Server: WinXP Pro 2002 SP2 running MS SQL Server 2005 Express configured for mixed authentication.
Both machines not on domains but share a common workgroup.
Windows firewalls on these machines disabled. Router firewall opened port 1433 to server. I am connecting from Client to Server by hitting the router IP and coming back in through port forwarding since my clients will have to be hitting my server through my router. Connectivity of the 2 machines is fine as I can telnet from one to the other on 1433 without issue when first stopping SQL Server of course.
Requirement: Connecting the two using Windows Authentication and TCP protocol to MS SQL Server. Ultimately, I am doing this to have clients connect into my server withoug having to be part of my domain/workgroup.
Server name in studio set to: tcp:www.myserver.org\sqlinstance,1433
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Now I have read some articles implying that this should be possible using 'workgroup authentication' so I tried that - basically ensuring that identical accounts are set up on both machines with the same passwords - I know this is working since I can transparently (no login required) map shares from one to other. This however still left me with the above error. I am assuming mapped drives used named pipes so this doesn't prove much when I am using Studio to connect via TCP.
For later reference, lets say the client machine is named CLIENT and the server is named SERVER and the common username is USERNAME and common password of PASSWORD.
I read an article stipulating that the authentication is domain based so that machine SERVER would receive an authentication SID (terminology may be wrong here) of CLIENT\USERNAME but since neither machine is on a domain SERVER could not validate the credentials on CLIENT and so it cannot work.
But yet another article said it can...go into Start|Settings|Control Panel|User Accounts and make click on 'Manage my network password' and make a new entry for the server and enter the username as it is required on the server...so I created one as follows:
Server: SERVER
User Name: USERNAME
Password: PASSWORD
...but received the same error.
If I use SQL Server Authentication it works fine...but my readings have shown that SQL Server Authentication is not all that secure (but in fairness don't know if most of the articles I read this in were talking about previous versions of MS SQL Server 2005).
So my questions:
1) Is SQL Server Authentication in MS SQL Server 2005 secure (maybe not as secure as Windows Auth, but secure enough to trust sensitive information to?)
2) Is it possible to use Windows Authentication between 2 machines separated by the internet and not part of domains? If so, what are the requirements for this? Common accounts/passwords? Common Workgroup? etc...
3) If 2) isn't possible does that imply that I need an OS that can act as a domain controller just to host my SQL Server? If so, could I then 'Manage my network password' on any client that needs to connect and have it provide correct domain\user info to the domain controller thereby avoiding having to join the domain to connect to the SQL Server - keep in mind the ultimate goal here is to have clients connect into my SQL Server via the internet where they won't be part of my domain and/or possibly can not be made part of my workgroup.
Thanks so much for any help you can provide.
Best Regards,
DOD
|||Good Questions - Hopefully I can help clear these up a little.
1. SQL Auth is very secure. In SQL 2K5, if you're using Win 2K3, you can even tie some of the Win2K3 policies (password change, length, etc.) to SQL Server Accounts. The rest of these answers is only for Windows Auth. For SQL Server Auth you can just connect using the name and account pair.
2. Management Studio uses your current account to connect - that's by design. If your account can be seen/trusted by the other system, you're in. If not, right-click Management Studio and select "Run As" if you're using XP. Then you can provide a domain/user pair.
You can definitely connect without common domains through any application by providing a connection string. You can also do this with any of the command-line utility such as sqlcmd, since you provide a connection string. Books Online has more about sqlcmd.
3. Not at all. Windows Security is a big subject, but the point is that you just need to determine what the server needs to see. I run several SQL Servers with Local (Workgroup) security.
- Buck
|||Thank you SOOOO much...it's nice to have an authority on the matter give a 'matter of fact' response!
Just a couple more questions regarding the above...
1) Given that I will not be running Win2K3 in the shortterm, but hosting SQL Server on a WinXP 2002 SP2 box, is SQL Auth in SQL Server 2K5 is inherently secure enough for sensitive business information when not tying into OS security policy functionality?
2) Is there any way to have an app always ran under different credentials (to avoid having to select Run As from the context menu each time) via some shortcut property, registry modification, or something else?
Once again, thanks in advance...I spent literally days researching this but because of my security concerns hadn't found what I considered a consistent and direct answer to the above.
<edited>
I just tried using the Run As and get the same error:
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Interesting that in the username field it still shows my local workgroup\logged in user versus what I set up in the Run As dialog. Is this just a bug in that the GUI does not reflect the Run As parameters or is it in fact just always using the logged in user?
I can connect using SQL Auth, so know without question that firewall settings are not an issue. I specified the user as:
WXP-P2000\myadminuser where WXP-P2000 is the computer name of the machine SQL Server is running on and myadminuser is a user in the administrators group on that machine. I provided the password for that account (I know that it is the correct password as I use RDP to connect to that machine to play remotely on the SQL side as needed)
My connection string in MS SQL Server Management Studio Express for 'Server name:' is set to:
tcp:mysql.myip.com\mysqlinstancename,1433 and know this is working since I can use SQL Auth and connect without issue.
From what I understand the above is an auth issue and not a SQL login issue, but what else can I try?
</edited>
Best Regards.
|||No, it's not a GUI issue - that's an odd form of that error, though. It should have had a user name variable. Which OS are you on?
1. Yes - as long as you follow basic security checklists you should be fine. There are lots of security resources for SQL 2K5, just search for those. Basically it is applying service packs, no blank passwords, don't enable bad things, and so on. The Best Practices Analyzer (BPA) will also check some security basics for you.
2. That I have not done. Are you trying to run SSMS as an application? I would recommend managing the system uing RDP and only hit the database through applications - that's the normal management profile.
|||Thanks for the quick reply.
Today I tested from a different machine at my company versus from a machine at home.
All machines involved have been WinXP 2002 SP2 boxes.
1. Will do, I have implemented a good security approach that I acquired doing my last 4 days of research.
2. I am running it as a remote app, trying to connect from my company back to my test SQL Server 2K5 Express install back home. I right click on the 'SQL Server Management Studio Express' shortcut under Start|Programs|Microsoft SQL Server 2005, choose 'Run As', type in the info and it starts up and the rest is as I've described - User name field in studio has my local machine name\user name and not what I've supplied. Ultimately, I can live with managing it via RDP, but can't see any reason why remote management would not work. Wouldn't remote management be more efficient as well as now it is just an app sending/receiving data versus the RDP session having to maintain sending/receiving screen updates (even if I reduce what is updated - i.e. Desktop background, themes, etc)?
Once again thank you for your assitance.
Best Regards,
DOD
|||On number two, there are lots of arguments on both sides. RDP is actually pretty light from a traffic persepctive, especially if you follow a best-practice for setting no themes on servers and using a plain black background. For truly light management, use PowerShell or sqlcmd.
- Buck
|||Don't mean to belabor the point, but do you have any other suggestions regarding connecting remotely into MS SQL Server 2K5 Express. Is there anything I could have missed in the blog trail above?
The most suspect thing to me is the fact that when I start up Studio using the Run As as discussed, it doesn't show me the computer\user that I input but rather the locally logged in credentials...have you seen this before in the workgroup auth you have used successfully in the past? Seems to me that if it is still using the logged in creds, the error would be expected...if this is the case, what's up with the Run As command or the support of it in Studio?
Cheers.