Security for Visual Studio.Net

[Robert D. Pinkerton]

I installed VS.NET 2003 on an XP/Pro Client. Also, MSDE 2000A.
This configuration works fine.

When I attempt to use another SQL Server on another machine I get one of two
messages:

1) Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection. (If I used Windows NT Integrated Security)
the connection string is: workstation id=FERRING;packet size=4096;user
id=sa;data source=TRURO;persist security info=False;initial catalog=pubs
or
2) Login failed for user 'sa'. (If I used SQL security)
the connection string is: workstation id=FERRING;packet size=4096;integrated
security=SSPI;data source=TRURO;persist security info=False;initial
catalog=pubs

The SQL Server I am trying to access is on Win2K/SP4 and has the .Net 1.1
Framework installed.
The server is PDC of a domain. The security mode of the SQL Server is set to
Mixed Mode.

The XP/Pro client is not a member of the domain but is a member of a
workgroup.

I have tried giving permissions to IUSR_FERRING and IWAM_FERRING in Active
Directory on TRURO and then mapped these to SQL Server logins/users. No
improvement,

I also create an ASPNET account on TRURO and gave it appropriate SQL
permissions but also no improvement.

This is driving me nuts. Can anyone point me in the right direction?

Thank you

/Bob

 

[Ken Schaefer]

Hi,

I assume you have your connection strings mixed up in this post, because the
first one is attempting to use an SQL Server login ID (and you getting a
Windows login failure), and the second connection string is attempting to
use Windows authentication, and you are getting an error relating to using
an SQL Server login.

If you want to use Windows Integrated Authentication
-and-
You are running the webpages (or VS.NET) on your Windows XP Machine
-and-
You want to connect to a remote SQL Server
-then-
You will be need to be running the webpage or VS.NET in the user context of
an account that can login to SQL Server. It is the current user context on
*your* machine that is attempting to login to SQL Server on the remote
machine. If you're running your ASP.NET pages as Machine\ASPNET, then you'll
see a logon failure for user "Null" because Machine\ASPNET is local to your
WinXP machine, and can't be assigned permissions to remote resources


If you want to use SQL Server Authentication, then I suggest:
a) you do not use the "sa" account - you should be using a least privilege
account
-and-
b) you need to supply an appropriate password. There is no password in your
connection string. Running SQL Server as "sa" with no password is the
dumbest thing I can think of. That's just asking to be hacked. It appears
that the remote SQL Server has a password on the "sa" account, hence your
login failure.

Cheers
Ken

: I installed VS.NET 2003 on an XP/Pro Client. Also, MSDE 2000A.
: This configuration works fine.
:
: When I attempt to use another SQL Server on another machine I get one of
two
: messages:
:
: 1) Login failed for user '(null)'. Reason: Not associated with a trusted
SQL
: Server connection. (If I used Windows NT Integrated Security)
: the connection string is: workstation id=FERRING;packet size=4096;user
: id=sa;data source=TRURO;persist security info=False;initial catalog=pubs
: or
: 2) Login failed for user 'sa'. (If I used SQL security)
: the connection string is: workstation id=FERRING;packet
size=4096;integrated
: security=SSPI;data source=TRURO;persist security info=False;initial
: catalog=pubs
:
: The SQL Server I am trying to access is on Win2K/SP4 and has the .Net 1.1
: Framework installed.
: The server is PDC of a domain. The security mode of the SQL Server is set
to
: Mixed Mode.
:
: The XP/Pro client is not a member of the domain but is a member of a
: workgroup.
:
: I have tried giving permissions to IUSR_FERRING and IWAM_FERRING in Active
: Directory on TRURO and then mapped these to SQL Server logins/users. No
: improvement,
:
: I also create an ASPNET account on TRURO and gave it appropriate SQL
: permissions but also no improvement.
:
: This is driving me nuts. Can anyone point me in the right direction?
:
: Thank you
:
: /Bob
:
:

 

[Robert D. Pinkerton]

Thanks, Ken. I did, in fact, document the errors/connection strings in
reverse.
The sa account does have a password and I forgot to include that in the
connection string.
Adding the password fixed my problem.
Point taken about using a less privileged account for SQL Server access.
Security is a little sloppy around here because this is a closed Intranet
behind a firewall (and a 2-person company).

Thanks for your sage advice.

/Bob