Connecting To SQL Server

Hi,

I have a problem in logging in to an SQL Server database engine. I can log in to the engine with Windows authentication method. The problem is, when I create a page with an SqlDataConnection control, the page can not connect to the database engine eventhough I select "Use Windows Authentication" when configuring the SqlDataConnection. What should I do?

Best regards,

Haris

This article explains how to connect to SQL Server using Windows authentication.

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

|||

Is the steps in the article that you mentioned also applicable on SQL Server 2005?

|||

Hi haris101,

Yes. It is applicable on sql2005.

The problem is, when I create a page with an SqlDataConnection control, the page can not connect to the database engine eventhough I select "Use Windows Authentication" when configuring the SqlDataConnection

what is your error message when your connection fails? also, did you get the error from visual web developper or IIS?

If you are getting the error from IIS (which i thin is the most case), make sure you have granted ASPNET (if using win xp) or NETWORK SERVICE (if using win 2003 server) the proper access permission. As to how to grant permission to a specific account, you can check the link tsm gave you . thanks

Connecting to MSDE2000RelA

I was able to install MSDE into WXP and migrated my Access
databases through Windows Integrated Authentication Method.
But whenever I tried connecting to MSDE by SQL login it
gives me the following error:
Invalid username and/or password, you are using a windows
login that is not your own, or server does not exist.
Please help.
Tnx,
Jess
hi Jess,
jess.tayag@.dhl.com wrote:
> I was able to install MSDE into WXP and migrated my Access
> databases through Windows Integrated Authentication Method.
> But whenever I tried connecting to MSDE by SQL login it
> gives me the following error:
> Invalid username and/or password, you are using a windows
> login that is not your own, or server does not exist.
>
if the raised error is
"Login failed for user 'UserName'. Reason: Not associated with a trusted SQL
Server connection."
the reason is MSDE is only allowing WindowsNT trusted connections and not
SQL Server authenticated connections, and this can be solved as explained in
http://support.microsoft.com/default...b;en-us;285097 in the part
regarding the Windows registry modification, while the
"SQL Server does not exists or access denied"
message is usually related to other kind of troubles, as indicated in
http://support.microsoft.com/default...06&Product=sql
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.10.0 - DbaMgr ver 0.56.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply

Connecting OSQL to MSDE using Windows NT Authentication?

I am installing MSDE SP3a on an NT 4.0 server and experiencing the
'CryptoAPI failed' error.
Now I found the error solution on the MS website, but this requires using
osql and connecting using Windows NT Authentication.
I have installed using SQL securitymode. Will this prevent me from
connecting using Windows NT Auth..?
If so, how can reset the securitymode to SQL after I have installed and
applied the correction for the original issue?
I am logged onto the NT server using the ADMINISTRATOR id, can I start OSQL
without the -U and -P parms?
Does the ADMINISTRATOR id require any additional permissions to connect to
MSDE? The reason I ask is because the MS document specifies "Make sure to
use Windows NT Authication while you are logged on with a Windows NT Account
that is a member of the SQL Server sysadmin role".
Install parms:
MSDERelA\setup.exe DATADIR=^sDataDrive"^ DISABLENETWORKPROTOCOLS=0
INSTANCENAME=XXXXX SAPWD=SA_pwd SECURITYMODE=SQL TARGETDIR=^sDataDrive^ /L*v
^sDataDrive XXXXX.log^ /qb
Thanks for any/all help..
Jim K.
This is mixed Authentication, so Windows Authentication should work, if
you are a local administrator try using the -E switch with OSQL. OSQL
-E which connects to the local server with the Windows credentials.
HTH, Jens Suessmeyer.

Connecting client to SQL Server via Cisco VPN

We are having one client PC running Win XP. SQL Server has been set to
Windows Authentication, TCP/IP 1433, Windows 2003 (!).
Via Cisco VPN we are making a connection. IAS has been configurated, so the
local user profile doesn't matter. The server recognizes the user that is
part of the domain that has been defined at the server. So far so good.
When the user tries to connect via any client software (Enterprise Manager,
Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
osql -l -S <hostname> -E
We have used several providers (dail-in, ADSL etc) and some of them works
fine, some not. You would probably say: use the one that works fine, but this
is not satisfying. Some client users are connected to a local network (no
dail in) and do also have the same problem.
The message we got is:
Login failed user '(null)'. Reason: not associated with trusted SQL Server
connection
I have seen at one of the Microsoft pages that we have to set the local
policies correct at the server where the domain has been defined (in case of
Windows 2003). We have done so. No results.
We first thought that it was a problem at the client, but since we have
proved that the same PC can connect to SQL it seems to be a networking
problem. We have also tried Named Pipes as a protocal but we did not succeed.
Since 50% of our clients are not able to connect (this is a world wide
application) we have serious problems. If anyone has any suggestion please
help us.
Thanks in advance
Jeroen
"Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> We are having one client PC running Win XP. SQL Server has been set to
> Windows Authentication, TCP/IP 1433, Windows 2003 (!).
> Via Cisco VPN we are making a connection. IAS has been configurated, so
the
> local user profile doesn't matter. The server recognizes the user that is
> part of the domain that has been defined at the server. So far so good.
> When the user tries to connect via any client software (Enterprise
Manager,
> Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
> osql -l -S <hostname> -E
> We have used several providers (dail-in, ADSL etc) and some of them works
> fine, some not. You would probably say: use the one that works fine, but
this
> is not satisfying. Some client users are connected to a local network (no
> dail in) and do also have the same problem.
> The message we got is:
> Login failed user '(null)'. Reason: not associated with trusted SQL Server
> connection
> I have seen at one of the Microsoft pages that we have to set the local
> policies correct at the server where the domain has been defined (in case
of
> Windows 2003). We have done so. No results.
> We first thought that it was a problem at the client, but since we have
> proved that the same PC can connect to SQL it seems to be a networking
> problem. We have also tried Named Pipes as a protocal but we did not
succeed.
> Since 50% of our clients are not able to connect (this is a world wide
> application) we have serious problems. If anyone has any suggestion please
> help us.
There are a number of areas that these clients could be failing... name
resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
guide will help:
How to troubleshoot connectivity issues in SQL Server 2000
http://support.microsoft.com/kb/827422
Steve
|||Thanks Steve,
The article helped us to get better focus on the issue. Instead of 50% of
the clients, almost all of them cannot connect when the try to establish a
connection via their local LAN.
We are almost sure that port 1433 is the problem. Since we got 3 dial in
providers 1 of them doesn't work. We have seen that NETSTAT -an shows us that
1433 is the problem. We have asked the provider and they have confirmed that
they give a random range of ports available.
Now the local LAN's... We have asked them to open port 1433 ingoing and
outgoing. But it still doesn't solve our problem. The VPN connection is
established via port 80 and this goes fine from any local LAN.
Windows authentication is chosen for a single point of entry. Some people do
not recommend this, but it is supported by Microsoft...
We are really lost, maybe someone has other ideas, maybe we can trace
somehow what goes wrong.
Regards,
Jeroen
"Steve Thompson" wrote:

> "Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
> news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> the
> Manager,
> this
> of
> succeed.
> There are a number of areas that these clients could be failing... name
> resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
> guide will help:
> How to troubleshoot connectivity issues in SQL Server 2000
> http://support.microsoft.com/kb/827422
> Steve
>
>

Connecting client to SQL Server via Cisco VPN

We are having one client PC running Win XP. SQL Server has been set to
Windows Authentication, TCP/IP 1433, Windows 2003 (!).
Via cisco VPN we are making a connection. IAS has been configurated, so the
local user profile doesn't matter. The server recognizes the user that is
part of the domain that has been defined at the server. So far so good.
When the user tries to connect via any client software (Enterprise Manager,
Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
osql -l -S <hostname> -E
We have used several providers (dail-in, ADSL etc) and some of them works
fine, some not. You would probably say: use the one that works fine, but thi
s
is not satisfying. Some client users are connected to a local network (no
dail in) and do also have the same problem.
The message we got is:
Login failed user '(null)'. Reason: not associated with trusted SQL Server
connection
I have seen at one of the Microsoft pages that we have to set the local
policies correct at the server where the domain has been defined (in case of
Windows 2003). We have done so. No results.
We first thought that it was a problem at the client, but since we have
proved that the same PC can connect to SQL it seems to be a networking
problem. We have also tried Named Pipes as a protocal but we did not succeed
.
Since 50% of our clients are not able to connect (this is a world wide
application) we have serious problems. If anyone has any suggestion please
help us.
Thanks in advance
Jeroen"Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> We are having one client PC running Win XP. SQL Server has been set to
> Windows Authentication, TCP/IP 1433, Windows 2003 (!).
> Via cisco VPN we are making a connection. IAS has been configurated, so
the
> local user profile doesn't matter. The server recognizes the user that is
> part of the domain that has been defined at the server. So far so good.
> When the user tries to connect via any client software (Enterprise
Manager,
> Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
> osql -l -S <hostname> -E
> We have used several providers (dail-in, ADSL etc) and some of them works
> fine, some not. You would probably say: use the one that works fine, but
this
> is not satisfying. Some client users are connected to a local network (no
> dail in) and do also have the same problem.
> The message we got is:
> Login failed user '(null)'. Reason: not associated with trusted SQL Server
> connection
> I have seen at one of the Microsoft pages that we have to set the local
> policies correct at the server where the domain has been defined (in case
of
> Windows 2003). We have done so. No results.
> We first thought that it was a problem at the client, but since we have
> proved that the same PC can connect to SQL it seems to be a networking
> problem. We have also tried Named Pipes as a protocal but we did not
succeed.
> Since 50% of our clients are not able to connect (this is a world wide
> application) we have serious problems. If anyone has any suggestion please
> help us.
There are a number of areas that these clients could be failing... name
resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
guide will help:
How to troubleshoot connectivity issues in SQL Server 2000
http://support.microsoft.com/kb/827422
Steve|||Thanks Steve,
The article helped us to get better focus on the issue. Instead of 50% of
the clients, almost all of them cannot connect when the try to establish a
connection via their local LAN.
We are almost sure that port 1433 is the problem. Since we got 3 dial in
providers 1 of them doesn't work. We have seen that NETSTAT -an shows us tha
t
1433 is the problem. We have asked the provider and they have confirmed that
they give a random range of ports available.
Now the local LAN's... We have asked them to open port 1433 ingoing and
outgoing. But it still doesn't solve our problem. The VPN connection is
established via port 80 and this goes fine from any local LAN.
Windows authentication is chosen for a single point of entry. Some people do
not recommend this, but it is supported by Microsoft...
We are really lost, maybe someone has other ideas, maybe we can trace
somehow what goes wrong.
Regards,
Jeroen
"Steve Thompson" wrote:

> "Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
> news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> the
> Manager,
> this
> of
> succeed.
> There are a number of areas that these clients could be failing... name
> resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
> guide will help:
> How to troubleshoot connectivity issues in SQL Server 2000
> http://support.microsoft.com/kb/827422
> Steve
>
>

Connecting

Hello All:
I have installed MSDE, using Windows Authentication. I can connect to it from a Query GUI tool I downloaded, which has an automatic option of NT Authentication. It does not ask me for a user, and has the password (too long to be my password) already writt
en in. I cannot connect using anything else, including Andrea Montanori's DbaMgr2k. I get a msg:
Login failed for user 'sa' Reason: not associated with a trusted SQL Server Connection.
I am running this on Win XP.
I know I can add users for specific databases, but I think I should be able to log in with 'sa' and the password. Am i getting my own password wrong?
Thanks.
andrew.
Hi Andrew,
This is because you have not enabled mixed mode authenticaton. As an
installation option, enter SECURITYMODE=SQL to enable this.
HTH,
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com
"andrewnichols" <anonymous@.discussions.microsoft.com> wrote in message
news:E7B59B91-D84D-4E52-8192-96473E52C339@.microsoft.com...
> Hello All:
> I have installed MSDE, using Windows Authentication. I can connect to it
from a Query GUI tool I downloaded, which has an automatic option of NT
Authentication. It does not ask me for a user, and has the password (too
long to be my password) already written in. I cannot connect using anything
else, including Andrea Montanori's DbaMgr2k. I get a msg:
> Login failed for user 'sa' Reason: not associated with a trusted SQL
Server Connection.
> I am running this on Win XP.
> I know I can add users for specific databases, but I think I should be
able to log in with 'sa' and the password. Am i getting my own password
wrong?
> Thanks.
> andrew.
|||If you don't want to re-install MSDE, you can change the registry key to
enable mixed auth and reset the sa password.
1. use regedit to change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SQL Server\MSSQL.1\MSSQLServer\LoginMode to 2 (mixed authentication) and 2.
execute following query: EXEC sp_password NULL, 'yourpassword', 'sa'
Amy
| From: "Greg Low \(MVP\)" <greglow@.lowell.com.au>
| References: <E7B59B91-D84D-4E52-8192-96473E52C339@.microsoft.com>
| Subject: Re: Connecting
| Date: Thu, 8 Apr 2004 00:16:44 +1000
| Lines: 36
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <ew4j2rKHEHA.688@.tk2msftngp13.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.msde
| NNTP-Posting-Host: 66.17.222.193
| Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftn gp13.phx.gbl
| Xref: cpmsftngxa06.phx.gbl microsoft.public.sqlserver.msde:13478
| X-Tomcat-NG: microsoft.public.sqlserver.msde
|
| Hi Andrew,
|
| This is because you have not enabled mixed mode authenticaton. As an
| installation option, enter SECURITYMODE=SQL to enable this.
|
| HTH,
|
| --
| Greg Low (MVP)
| MSDE Manager SQL Tools
| www.whitebearconsulting.com
|
| "andrewnichols" <anonymous@.discussions.microsoft.com> wrote in message
| news:E7B59B91-D84D-4E52-8192-96473E52C339@.microsoft.com...
| > Hello All:
| >
| > I have installed MSDE, using Windows Authentication. I can connect to it
| from a Query GUI tool I downloaded, which has an automatic option of NT
| Authentication. It does not ask me for a user, and has the password (too
| long to be my password) already written in. I cannot connect using
anything
| else, including Andrea Montanori's DbaMgr2k. I get a msg:
| >
| > Login failed for user 'sa' Reason: not associated with a trusted SQL
| Server Connection.
| >
| > I am running this on Win XP.
| >
| > I know I can add users for specific databases, but I think I should be
| able to log in with 'sa' and the password. Am i getting my own password
| wrong?
| >
| > Thanks.
| >
| > andrew.
|
|
|

Connect to SQLExpress via Internet with Windows Authentication?

I posted this message on Google but never received an answer so I thought I would try here.

Is it possible to connect to SQLExpress over the Internet (TCP/IP) using Windows Authentication? I can connect using SQL Authentication but the client would rather use Windows Authentication to avoid manageing another set of user names and passwords.

I have tried connecting with a workstation using cached credentials but I just receive an error "Cannot generate SSPI context".

Any assistance is appreciated.

By “Internet” do you mean the network around world, or just “across TCP/IP within your client’s intranet”?

Zlatko

|||Your client would need to open up 'windows' ports on their server in order to get windows auth to work. (i.e. SMB and other ports, including kerberos, etc.)

Typically, this is the WORST possible move to do on a web facing server, it effectively puts the server 'out' on the internet. Yes, Windows Authentication IS more secure than SQL Server auth, but when you put your server 'out' like that on the internet, then you're exposing it to hackers who may stumble across it and attempt to brute-force their way on to the box. Even if they don't succeeed, they may DOS the box with all of the traffic.

In other words, YES, you can use windows authentication on the "internet" but that requires your server to therefore be on the "internet" - i.e. it's no longer effectively behind a firewall and in your 'LAN' it's just 'out' and ready to be hacked.

If you really need more security than what SQL Server auth provides (which can be made pretty secure using pass phrases instead of passwords (like "When will the world end, I wonder?"), then maybe look at getting a VPN.

|||Internet as in worldwide.|||

I was afraid someone was going to say that but I appreciate the feedback. I know SQL authentication is not very secure and was hoping Windows authentication would be a better solution.

Ideally I would lik to find a way to have users connect to the SQL server using RPC over HTTP similar to how Outlook 2003 remotley connects to Exchange 2003 without VPN or openning ports on the firewall.

Does anyone happen to know how I might do this with SQL?

|||SQL Server 2005 natively supports SOAP over http.

Connect to SQL with NT authentication from form...

I have a login page that checks the given userid/password against ADSI and redirects the user if successful. My problem seems to come when I try to connect to the SQL database with the user's NT credentials. I have the user's NT account setup in SQL, have anony. disabled in IIS, using Integrated Windows Security in IIS, and am using the following connection string:

connectionString = "data source=SqlServer;initial catalog=pubs;Trusted_Connection=Yes"

I also have this entry in my Web.Config file: <identity impersonate="true" /
Actually, it seems to connect OK, but I can not select any data. I just receive "Select permission denied..." errors even though the user has been given these permissions in SQL.

Any advice would be greatly appreciated.

Thanks,
-BenYou need to set the proper access rights in for the User in SQL Server itself.|||The user has all the proper permissions on the SQL server.

Connect to SQL Server from Client Using Windows Authentication

On a newly installed workgroup computer, the client, I've been able to
establish connections to the SQL Server on a different computer using SQL
authentication via ODBC and Query Analyzer.
Now I am trying to figure out how to connect with WIndows authentication.
On the client computer (PCMAX04), when I try to login to SQL Server via QA,
the error reads "Login failed for user DELLJAN2005\Guest" even though I am
logged in to the client computer as MST.
DELLJAN2005 is the name of the SQL Server and the computer on which it is
installed.
In SQL Server, there is a login named "DELLJAN2005\MST".
How can it arrange it so that when I log on from the client computer using
Windows authentication, SQL Server interprets the login as being for "MST"?
Many thanks,
Mike Thomas
You don't mention the specific operating systems involved.
With XP home, authentication is done using the guest account
as simple file sharing is always enabled on XP Home. You
could hit the issue with XP Pro if simple file sharing is
used. It's optional but is the default with XP Pro. How you
address the issue depends somewhat on what specific
operating systems are involved. Refer to the following for
more info:
SQL Server clients are authenticated as guests if Simple
File Sharing is enabled
http://support.microsoft.com/?id=831133
-Sue
On Fri, 18 Feb 2005 09:38:43 -0500, "Mike Thomas"
<mike@.ease.com> wrote:

>On a newly installed workgroup computer, the client, I've been able to
>establish connections to the SQL Server on a different computer using SQL
>authentication via ODBC and Query Analyzer.
>Now I am trying to figure out how to connect with WIndows authentication.
>On the client computer (PCMAX04), when I try to login to SQL Server via QA,
>the error reads "Login failed for user DELLJAN2005\Guest" even though I am
>logged in to the client computer as MST.
>DELLJAN2005 is the name of the SQL Server and the computer on which it is
>installed.
>In SQL Server, there is a login named "DELLJAN2005\MST".
>How can it arrange it so that when I log on from the client computer using
>Windows authentication, SQL Server interprets the login as being for "MST"?
>Many thanks,
>Mike Thomas
>
>
>
>

Connect to SQL Server from Client Using Windows Authentication

On a newly installed workgroup computer, the client, I've been able to
establish connections to the SQL Server on a different computer using SQL
authentication via ODBC and Query Analyzer.
Now I am trying to figure out how to connect with WIndows authentication.
On the client computer (PCMAX04), when I try to login to SQL Server via QA,
the error reads "Login failed for user DELLJAN2005\Guest" even though I am
logged in to the client computer as MST.
DELLJAN2005 is the name of the SQL Server and the computer on which it is
installed.
In SQL Server, there is a login named "DELLJAN2005\MST".
How can it arrange it so that when I log on from the client computer using
Windows authentication, SQL Server interprets the login as being for "MST"?
Many thanks,
Mike ThomasYou don't mention the specific operating systems involved.
With XP home, authentication is done using the guest account
as simple file sharing is always enabled on XP Home. You
could hit the issue with XP Pro if simple file sharing is
used. It's optional but is the default with XP Pro. How you
address the issue depends somewhat on what specific
operating systems are involved. Refer to the following for
more info:
SQL Server clients are authenticated as guests if Simple
File Sharing is enabled
http://support.microsoft.com/?id=831133
-Sue
On Fri, 18 Feb 2005 09:38:43 -0500, "Mike Thomas"
<mike@.ease.com> wrote:

>On a newly installed workgroup computer, the client, I've been able to
>establish connections to the SQL Server on a different computer using SQL
>authentication via ODBC and Query Analyzer.
>Now I am trying to figure out how to connect with WIndows authentication.
>On the client computer (PCMAX04), when I try to login to SQL Server via QA,
>the error reads "Login failed for user DELLJAN2005\Guest" even though I am
>logged in to the client computer as MST.
>DELLJAN2005 is the name of the SQL Server and the computer on which it is
>installed.
>In SQL Server, there is a login named "DELLJAN2005\MST".
>How can it arrange it so that when I log on from the client computer using
>Windows authentication, SQL Server interprets the login as being for "MST"?
>Many thanks,
>Mike Thomas
>
>
>
>

Connect to SQL Server 2K through ODBC

Does anyone know a way to still authenticate to a SQL
Server 2000 server using SQL Authentication when Anonymous
Access is turned off?
176380 How To Use ASP with a SQL Trusted Connection with Guest Account
http://support.microsoft.com/?id=176380
169377 How to access SQL Server in Active Server Pages
http://support.microsoft.com/?id=169377
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Thanks for your post, but this still requires Anonymous
Access to be turned on... It just changes the account
from IUSR_MACHINENAME to an account that you create. I
need it turned off because I am trying to get the logged
in user via Request.ServerVariables("LOGIN_USER") and it
won't work with Anonymous Access turned on.
Are there any other ways?
Thanks again for any help.
Yong
>--Original Message--
>
>176380 How To Use ASP with a SQL Trusted Connection with
Guest Account
>http://support.microsoft.com/?id=176380
>169377 How to access SQL Server in Active Server Pages
>http://support.microsoft.com/?id=169377
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and
confers no rights.
>
>.
>
|||What security are you using in IIS and SQL?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Integrated Windows Authentication.
>--Original Message--
>What security are you using in IIS and SQL?
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and
confers no rights.
>
>.
>

Connect to SQL Server 2K through ODBC

Does anyone know a way to still authenticate to a SQL
Server 2000 server using SQL Authentication when Anonymous
Access is turned off?176380 How To Use ASP with a SQL Trusted Connection with Guest Account
http://support.microsoft.com/?id=176380
169377 How to access SQL Server in Active Server Pages
http://support.microsoft.com/?id=169377
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Thanks for your post, but this still requires Anonymous
Access to be turned on... It just changes the account
from IUSR_MACHINENAME to an account that you create. I
need it turned off because I am trying to get the logged
in user via Request.ServerVariables("LOGIN_USER") and it
won't work with Anonymous Access turned on.
Are there any other ways?
Thanks again for any help.
Yong
>--Original Message--
>
>176380 How To Use ASP with a SQL Trusted Connection with
Guest Account
>http://support.microsoft.com/?id=176380
>169377 How to access SQL Server in Active Server Pages
>http://support.microsoft.com/?id=169377
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and
confers no rights.
>
>.
>|||What security are you using in IIS and SQL?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Integrated Windows Authentication.
>--Original Message--
>What security are you using in IIS and SQL?
>Thanks,
>Kevin McDonnell
>Microsoft Corporation
>This posting is provided AS IS with no warranties, and
confers no rights.
>
>.
>