SQL Authentication from outside domain

[Anthony Benbrook]

Hello

I've read many articles on this subject, but most seem to be concerned
with integrated security. I'm shooting for basic SQL Authentication

I have an IIS server on a standalone machine on our network; not part
of the domain. My ASP.NET application has a connection string to a
SQL Server on the domain. The connection string uses a login/password
for a basic SQL Authentication account. Attempting to connect with
this conn string produces the fabled "SQL server does not exist or
access denied" error.

Meanwhile, I am also unable to connect to this SQL server as a locally
logged in user from Enterprise Manager etc. UNLESS I use Windows
Explorer to navigate to the SQL Server's file-share, and log in with a
domain account when prompted. I am then able to connect via
Enterprise Manager. Magic!

My understanding is that by logging into the file share with the
domain account, I am establishing a trust between the standalone
machine and the domain machine. This allows access to the SQL server
in the context of the local non-domain user. (Using the same SQL
Authentication login/password in the conn string)

The question is, how can I establish this same trust for my ASPNET
worker process so that it might access the SQL Server with the conn
string?

This is only for development purposes, and needn't be the cleanest or
most secure solution. I would like to avoid adding the IIS machine to
the domain.

Thanks for any info or clarification!
Tony

 

[Ken Schaefer]

What type of authentication mode are you using on your SQL Server:
Integrated Windows? or Mixed Mode?
What netlib is the ASP.Net application using to connect to the SQL Server?
TCP/IP? (or something else)?

Cheers
Ken

: Hello
:
: I've read many articles on this subject, but most seem to be concerned
: with integrated security. I'm shooting for basic SQL Authentication
:
: I have an IIS server on a standalone machine on our network; not part
: of the domain. My ASP.NET application has a connection string to a
: SQL Server on the domain. The connection string uses a login/password
: for a basic SQL Authentication account. Attempting to connect with
: this conn string produces the fabled "SQL server does not exist or
: access denied" error.
:
: Meanwhile, I am also unable to connect to this SQL server as a locally
: logged in user from Enterprise Manager etc. UNLESS I use Windows
: Explorer to navigate to the SQL Server's file-share, and log in with a
: domain account when prompted. I am then able to connect via
: Enterprise Manager. Magic!
:
: My understanding is that by logging into the file share with the
: domain account, I am establishing a trust between the standalone
: machine and the domain machine. This allows access to the SQL server
: in the context of the local non-domain user. (Using the same SQL
: Authentication login/password in the conn string)
:
: The question is, how can I establish this same trust for my ASPNET
: worker process so that it might access the SQL Server with the conn
: string?
:
: This is only for development purposes, and needn't be the cleanest or
: most secure solution. I would like to avoid adding the IIS machine to
: the domain.
:
: Thanks for any info or clarification!
: Tony

 

[Anthony Benbrook]

The SQL Server uses Mixed Mode. The login in the connection string is
a SQL login, not domain.

As for the netlib, I have tried explicityly setting the Network
Library attribute of the conn string to dbmssocn (TCP/IP), dbmsrpcn
(Multiprotocol), and dbnmpntw (Named pipes). All 3 produce the "does
not exist" error.

The odd thing is that there are a few other SQL servers on the domain
that the connection string *will* connect to successfully. But the
one I want to connect to, as well as another server on the domain,
produce the error. Even though I am able to establish a connection
through Enterprise Manager as mentioned before. Could there be a SQL
Server setting I'm missing?

Thanks again
Tony

 

[Anthony Benbrook]

Well...nevermind.

The guy running the SQL server "jiggled the wires" of SQL's network
settings and it suddenly started working over TCP/IP.

Beats me.