I'm getting a strange error when I enable windows authentication on IIS and try to run some database update scripts:
Invalid token for impersonation - it
cannot be duplicated.
I have not enabled any explicit impersonation.
I have narrowed it down to being something to do with SMO as when I change to a normal SqlClient and use ExecuteNonQuery, the problem goes away. This unfortunately is not a long term solution as the update scripts must be able to contain the 'GO' keyword which is not recognized by the standard SqlClient.
IIS worker processes are running as some user. When you use windows authentication, you are implicitly doing impersonation to the that user.
If your SQL server is on a different host, this probably isn't good enough. The impersonated user I think can only access local resources.
http://msdn.microsoft.com/en-us/library/ff647405.aspx#paght000025_usingimpersonation
Is SQL Server using windows authentication?
Related
A client of mine is using some older software I had written on a newer server setup. Despite having a connectionstring declared in the web.config file, the program keeps trying to log in as the current user and dumping out the error:
Login failed for user 'DOMAIN\currentUserJimbo'
Any ideas what would be causing this?
Their setup
Windows Server 2008
IIS 7
MSSQL 2005
If you have integrated authentication in the connection string and have enabled impersonation you should see that behaviour.
Integrated authentication will cause the web site to log on to the SQL server using the thread's current principal. When enabling impersonation, the thread will take the identity of the client. This can be useful if the web server is to access files or other resources on behalf of the user.
Maybe SQL Server authentication is turned off? And it connects using Windows Authentication?
Check to make sure the connection string being used doesn't have Integrated Security=SSPI; in it.
Check out these connection strings for some tips.
I have installed a new web application that access a SQL Server database in a different server. I'm using Windows Authentication and get the error of:
Login Failed for user XXX
When I try to set identity impersonate="true" in the web.config file, it just throws an error
Login Failed for anonymous user
Also, I'm using forms authentication to validate users from my website and using a different application pool.
Update: connection string Basically like this:
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
Update:
My Virtual Directory has Anonymous Authentication and Windows Authentication enabled.
Typically ASP.NET runs as an anonomous account. In order to access a remote SQL Server using integrated authentication (SSPI), you'll need to have a bit more "permenant" presence. Easy way would be to shift the app pool to use the NETWORK SERVICE built-in account. Slightly trickier would be to use a named account. On the SQL server side of the equation you will need to give the same account -- either matching user/pass or NETWORK SERVICE -- proper permissions to your database.
Your DBA should be able to help.
It is difficult to provide you with an exact answer because you have not provided your connection string or info on your SQL Server config. Your best bet is to look at the IIS configuration and work out what user is attempting to access the different SQL Server. You then need to give this account access to the database. This is a common problem and most of the changes need to happen in SQL Server unless you can change the account that the web server is running under.
I have an internal website that is using integrated windows authentication and this website uses sql server & active directory queries via the System.Directory.Services namespace.
To use the System.Directory.Services namespace in ASP.NET I have to run IIS under an account that has the correct privileges and importantly have impersonation set to true in the web config. If this is done then when I make a query against AD then the credentials of the wroker process (IIS) are used instead of the ASPNET account and therefore the queries will now succeed.
Now if I am also using Sql Server with a connection string configured for integrated security ('Integrated Security=SSPI') then this interprets the ASP.NET impersonation to mean that I want to access the database as the windows credentials of the web request not the worker process.
I hope I'm wrong and that I've got the config wrong, but I don't think I have and this seems not to be inconsistent?
It should be noted I'm using IIS 5.1 for development and obivously this doesn't have the concept of app-pools which I believe would resolve the problem.
Following the documentation if you want to impersonate a SPECIFIC user, you must put the username and password in the web.config file, so that it uses that same user account for all requests.
I'm trying to get an ASP.NET website running on Vista (IIS7), using SQL Server and Windows Authentication. No matter what I do, when I connect to the database, I get the exception:
SqlException was unhandled
Login failed for user 'MyDomain\MachineName$'.
It doesn't seem to matter what settings I apply, I cannot get IIS7 to pass through my Windows login credentials.
Extra details:
Both the SQL Server and my local machine are on ActiveDirectory
Vista Enterprise, IIS7
SQL Server 2005
Anonymous Authentication disabled, Windows Authentication enabled
Impersonation on/off makes no difference
All Identities (NetworkService, LocalSystem, etc) give the same result
Classic and integrated pipelines give the same result
Help!
Impersonation on/off makes all the difference, when properly configured. What you want is caled 'constrained delegation' and you need to configure IIS and ASP for it:
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Configure ASP.NET Impersonation Authentication (IIS 7)
Configuring Servers for Delegation
By default, the IIS server is not allowed to impersonate you towards the SQL Server. There's an MSDN article on how to configure it. The configuration process is complex and error prone.
If your production ISS and SQL Server run on different servers, you'll need a domain admin to configure impersonation trust between the two servers. This is typically a no-go in a big organization.
In addition to not being deployed by normal admins, impersonation also prevents users from sharing their connections in the SQL connection pool. This results in a very noticeable performance penalty for even small (5+ users) websites.
Did you try to create a new user account for your application, grant it the appropriate rights on the Sql Server, and then set the application pool to run under this new account?
This is what I usually do, and it works. I'm not running my application under NetworkService, LocalSystem or other builtin accounts.
Does your connection string contain Integrated Security=SSPI?
Have you switched the asp.net context to be a domain user as well?
Here is an MSDN article on this topic
http://msdn.microsoft.com/en-us/library/2xzyzb0f.aspx
I am using SQLServer2005 and VS2008. My connection string in web.config is:
add name="library" connectionString="Data source=KMT; Initial Catalog=Library;Integrated Security=SSPI"
Here, KMT is my server name, Library is my database.
When I run my page through VS2008 localhost, it's fine. However, when viewing through IIS it shows an error message like "login failed for user, 'KMT/ASP.NET'". My sqlserver authentication mode is windows and it's ok in web.config. What will be the solution?
Using "Integrated Security" means logging in to the database with the identity of the user running the process. When you run the local VS web server, it runs as your login. But in IIS, the web server worker process runs as a predefined user account. Your worker process identity must have rights to your SQL Server and database.
Check the properties of your App Pool in IIS. If you are running as Network Service for example, go into SQL and create a new user, enter Network Service as the Windows user name, and grant that user rights to your database.
one of my friends helped me to solve this problem as
i executed the SQL to add ASPNET as a login to
my DB and setup DA permissions
exec sp_grantlogin N'MACHINE\ASPNET'
exec sp_defaultdb N'MACHINE\ASPNET', N'Database'
use Database
exec sp_grantdbaccess N'MACHINE\ASPNET', N'ASPNET'
exec sp_addrolemember N'db_owner', N'ASPNET'
here MACHINE is machine name and database is my database name.
but through this the ASPNET user has total
control over that DB.
VS2008 uses your credentials to authorize to the db, IIS is using different account.
Make sure the IIS account has enough permissions.
If you use Integrated Security=SSPI, the credentials of the current user (in VS that would be YOU) are used to connect to SQL Server.
From an IIS app, the user associated with the IIS service is used for log in.
Solutions:
Assign the IIS service a special user that's allowed to connect to SQL
Use SQL Server authentification to access the database, and stored username/password in the connection string
Were you planning to use the ASP.NET system account or the users windows account?
If the latter you need impersonation. That works if SQL and IIS are on the same machine, otherwise it is a double hop and requires a non trivial amount of work to set up delegation.
If the server is windows 2003 you can give the Network Service the permissions to access to SQL Server