Re: ASPNET Account, Impersonation, SQL Server problem

From: Javier Miranda (jamiranda@lycos.com)
Date: 03/18/03 

From: "Javier Miranda" <jamiranda@lycos.com>
Date: Tue, 18 Mar 2003 15:42:07 -0400

Ron:

>Does
> this have to be a domain level account?
--------- Yes, beacuse SQL Server does not know anything about other
computers local accounts. It knows about domain account IF it is member of
a domain. If servers are in different domains, you have to implement domain
trust relationships.

> problem! He is using SQL server authentication like I am
> but is NOT using impersonation and the DB login has NOT
> had the ASPNET account added because as I mentioned the
> account currently doesn't even exist. I don't understand
> why it works.
---------- If you are connecting to SQL Server using SQL Server
authentication, impersonation setting does not matter. I assume that your
Server is configured to use both (SQL and Windows) authentications. What
impersonation does is let ASPNET process to assume the identity of the
calling user. Here could be the strange behavior you are experimenting. If
you are using Administrator account, witch usually has administrator rights
on SQL Server, you can connect with no problem to the database. This can
vary depending if you logon with a local or domain account and by the
authentication settings in IIS. Remember that all necessary security
verification performed between IIS and IE runs in the background.

The best approach:
Separate your connection to the database in data tier components.
Impersonate a DOMAIN user in code before making a call to the database OR
enable the component to be a serviced component and you can easily change
identity in COM+ without recompiling (beast way).

Hope it helps, if not, let me know.

"Ron Bearry" <rbearry@hotmail.com> wrote in message
news:070501c2e9c3$38f0e0c0$3401280a@phx.gbl...
> It's like sniffing too much perfume until your nose is
> dead. I've scoured the docs/net and I've read so much
> that I'm confused and need clarity.
>
> I have a web server (IIS) and a SQL server 2000 and each
> of these live on a different box on our network. I want
> to let my asp.net app talk to my SQL server box but it's
> not working unless I enable impersonation AND use SQL
> server authentication passing a username and password in
> the connection string which I'd rather not do. However,
> everything works great on my single (sql and iis on same
> box) developer machine without impersonation and that's
> because I've set up a login on my DB for
> localmachine\ASPNET.
>
> If I understand, what I need to do for the separate boxes
> to talk, is set up a login on my SQL server database for
> the ASPNET account. This is where it gets foggy. Does
> this have to be a domain level account? (domain\ASPNET)
> The ASPNET account on the web server is a local account
> so I am confused. Does my network admin have to create an
> account like this for me? What do they use for the
> password? An account by this name does not currently
> exist.
>
> Here's another point of confusion. The servers in
> question are my test servers under my control in my cube.
> They are both on our LAN. The web server is running Win2K
> server and the SQL box is the Developer Edition runnning
> on Win2K pro.
>
> Here's the confusion. My coworker is also developing an
> asp.net app and using my web server. However, we tested a
> different scenario today by copying his DB up to our
> official SQL 2000 test server and it worked with no
> problem! He is using SQL server authentication like I am
> but is NOT using impersonation and the DB login has NOT
> had the ASPNET account added because as I mentioned the
> account currently doesn't even exist. I don't understand
> why it works. I know for a fact that the web server is
> using the "stock" .net framework configuration. We
> haven't edited the machine.config or anything like that.
>
> Any insight is appreciated. I need to figure this out so
> I can talk more intelligently with our admins about this.
> I don't know networks and they don't currently know
> anything about .NET
>
> Thanks,
> -Ron

Relevant Pages

  • Re: SQL account rights
    ... Please advice what is the best, suitable rights rather than domain admin ... issues, such as a server that might have IIS running on the same machine, ... applicable to SQL 2000 environment, ... files, or backups, make sure that the service account has Full ...
    (microsoft.public.sqlserver.security)
  • RE: MP Install issue
    ... Where in the installation are you talking about specifying the account rather ... > MPDB ERROR - CONNECTION PARAMETERS ... > SQL Server Name: servername ... > with a trusted SQL Server connection. ...
    (microsoft.public.sms.setup)
  • Re: SQL Express Fails with Hardware Error
    ... The LocalSystem account is a built-in account, ... which the SQL Service runs. ... MCSE, CCEA, Microsoft MVP - Terminal Server ... Minimum Hardware Requirement (Warning) ...
    (microsoft.public.sqlserver.setup)
  • Re: SCCM with a remote SQL instance problems (IT IS NOT A WARNING)
    ... PreReq check is not a WARNING it is a FAILURE. ... account the run the SQL Server Service on the server, Domain Memberships, AD ...
    (microsoft.public.sms.installer)
  • Re: Distributed Query - Linked Servers?
    ... In the case of SQL style accounts, it doesn't seem very secure to me, because the password will be transmitted over the network. ... it should also be able to work by setting up a credential and proxy account on Server1. ... In this case it could work with NTLM authentication. ... we just need to verify that the 2 sql server instances are under sql server and windows authentication mode and the sql account you use has the permission on the 2 sql server instances. ...
    (microsoft.public.sqlserver.server)
Quantcast