I created a db via app-data folder, migrated over to server explorer and tried to connect to it and I get
Cannot open database "abc" requested by the login. The login failed. Login failed for user 'xyz'. I came across this: [Cannot open database “test” requested by the login. The login failed. Login failed for user 'xyz\ASPNET'
I have two questions concerning the best answer.
Whenever I connect to ssms windows authentication is selected. So does windows authentication still matter if a db is created using visual studio?
Second is concerning this:
UPDATE: Ok, you're using integrated Windows authentication --> you need to create a SQL Server login for "xyz\ASPNET" on your SQL Server"
What does he mean by create a sql login for user "xyz"?
I thought the purpose of win authentication was so you didnt have to type login and pass to connect. You're automatically connected through windows. Right?
Related
My web site uses Windows authentication and the connection string looks like this:
<add name="MyConnString"
connectionString="Server=MyServer;Database=MyDb;Integrated Security=true" />
When I run it on my dev box the web site knows me as my windows login and so does the database. However when I publish the web site to our test server the database refuses connection saying:
Login failed for user...
and it has the domain and name of the web server so it looks like this:
Login failed for user MyDomain\Myserver$
Apparently it isn't trying to connect to the database using my windows login. The web site Windows auth is returning my correct windows login.
I admit I have never used a conn string like this before I always us a specific SQL Server login and every one comes in under those credentials, but I'm being asked to do it this way. So the goal would be to grant every users windows login access to this database.
I have an asp.net application running in IIS using the account which has access to my database. With windows authentication, I am able to log into this account in sql server manager and other things. In my connection string, I have Integrated Security=true, and the error message I get when loading a page using this connection string references the correct user. (Not 'IIS APPPOOL\ect...' like all the other instances of this question I have found on SO). Is there something else that can cause this issue? I just dont understand why I am able to log in with the same windows account in other applications.
Im currently trying to deploy my .NET MVC Application to IIS 7.5.
There is a database connection problem that im trying to figure out. In localhost, everything seems fine, however, when I deploy my app to remote server, the app runs, without connecting to database. For example I have a VisualLeadController that has getMonthlyLeadsByYear() method that connects to database and retyrns data. When I try to execute it from brower by typing
http://staging2.landornet.com/WebLeadsVisualizer/VisualLead/getMonthlyLeadsByYear
It generates this error:
Exception Details: System.Data.SqlClient.SqlException: Login failed for user ''.
The steps that I followed:
1-Removed integrated security=True from WebConfig connection strings
2- Changed applicationpool identity from applicationPoolIdentity to local system.
Still now working... anyone has any idea?
When deploying your web app to your remote server, you will need to use a SQL connection string that contains an explicit username and password associated with a SQL account. For example,
Data Source=SERVER;Initial Catalog=DATABASENAME;User ID=SQLUSERNAME;Password=SQLUSERPASSWORD
To use this connection string, you will need to first use SQL Management Studio to create a SQL login with a username and password, and give that user access to your database. Then log out out of SQL Management Studio and log back in using that user/password to make sure that it correctly can access your database. Hopefully then your web app should be able to connect to the database.
I am using Microsoft.SqlServer.Management.IntegrationServices in an ASP.NET web form to access an SSIS project in SSISDB. Testing locally on my own PC I am able to access the package from the test server and it runs fine.
My issue comes up when I try to run the site from the test server. The same test server hosts the site with IIS 7 and hosts the Sql Server database which stores the package with Integration Services. So like I said, the package is hosted on the server and when I run the site locally on my PC, all works fine.
When I run the site on test and try to access the package I get:
System.Data.SqlClient.SqlException (0x80131904): Login failed for user '[DOMAIN]\[PCNAME]$'.
I am using integrated security in my connection string:
SqlConnection connection = new SqlConnection(#"Data Source=[Test_Server];Initial Catalog=master;Integrated Security=True;");
IntegrationServices integrationServices = new IntegrationServices(connection);
My error comes up here when trying to connect.
I've tried adding '[DOMAIN]\[PCNAME]$' as a Sql login using Windows authentication with every permission I can think of. User mapping for database SSISDB has accessadmin, datareader, datawriter, owner, public, and ssis admin. I know not all of these should be needed, but I'm trying everything.
I went to SSISDB under databases, and gave the login permission to Connect, Execute, and Select.
Under Integration Services Catalogs I gave my folder, under SSISDB catalog, permission for the my Windows User ('[DOMAIN]\[PCNAME]$') login to Read, Execute Objects, and Read Objects.
I gave the SSISDataTransfer project permission for the Windows User to Read, Modify, and Execute.
I'm out of ideas and figure it's probably some IIS issue. It has Windows Authentication installed and set.
Anyone have any ideas? I've found posts about how to get the code to work, but nothing on connection specifics. Thanks!
i have had similar problem recently and i have worked with SSIS packages being used with web applications too. in my opinion you should use a custom user account to be used as your app pool account. and you will have to add this account to your database server. when running an app pool as local system or network service, the account being used for connection to a remote database server will be "DomainName\MachineName$" which will be different for every machine which tries to connect to your sql server. so instead of adding all these user names in sql, you will be better off using a custom user account.
Secondly looks like your web application does not run on the same machine as your sql server which i think will not work because you can invoke SSIS package from the same server only.
Another thing to try is to add a credential to sql server - in Security - Credentials in SQL Server management studio. This credential would be the authenitcated user that you are running it successfully under. Then in your SSIS package, in SQL Server agent, go into the job step and in the "Run As"drop down, select the new credential for your user that you created.
I use a dbml for my Data Access Layer to provide the data that i need in my app.
When i connect from the server explorer everything seems fine. I choose to use my windows authentication and the connection test shows everything works just fine. When i Build my solution and run it on my IIS it says that i'm using a login that is not working.
How to solve this issue?
The web site will be logging in to the SQL Server using the identity of the application pool of the web site, you have to grant that user (normally network service) access to the database.
When you try to connect from server-explorer and chose windows authentication, it uses currently logged in user to authenticate with the sql-server. You must be logged in as Administrator of the local system so it lets you in using windows authentication.
But when you run your application through IIS, and try to authenticate using windows authentication it uses local system aspnet_user account to authenticate which must not have authorization to access your database. You need to authorize aspnet_user to access your database and it will work.
A recommended practice is to not
authenticate using windows
authentication but to use sql server
authentication which will work in every context.
Did you define the appropriate connectionstring in your web.config?