So we have a number of databases in SQL Server set to "Partial" containment. We do this as they are part of a AAG, and it means the users can be contained in the database so when it's copied over to the other server the users are copied too.
I have the site using one such user and that works fine. However I want to point a console application at the same database using the same password. I copied the connection string but when I try to run the console application I get both the following errors logged in the event viewer:
Login failed for user 'MyUser'. Reason: Could not find a login matching the name provided. [CLIENT: SERVERIP]
Login failed for user 'MyUser'. Reason: Password did not match that for the user provided. [Database: 'MyDatabase'] [CLIENT: SERVERIP]
If I create a login and a user in the traditional SQL way I can connect fine but then if we ever failover to the other server the login won't exist. If I create a new contained user it fails in the same way. The contained user works fine on a website running on the same server with the same connection string.
Any ideas why the console app can't connect while the site can? It's SQL Server 2012 if that makes any difference and a .net site and console app written in C#
Related
I have a .Net Core 2.0 application that I host in IIS 7.
With IIS Express the application works fine and I'm able to connect to the database successfully. With IIS I get this error:
Cannot open database "Books" requested by the login. The login failed. Login failed for user 'DOMAINNAME\PCNAME$'.
My connectionString in appsettings.production.json file looks like this :
"ConnectionStrings": {
"BooksDatabase": "Server=PCNAME\\SQLEXPRESS;Database=Books;user id=iisAccess;password=iisPassword;Trusted_Connection=True;ConnectRetryCount=0;MultipleActiveResultSets=true"
};
What am I doing wrong and why does it say that the "login failed for 'DOMAINNAME\PCNAME$'" when I put the credentials user id=iisAccess;password=iisPassword; in my JSON file?
You are asking for Windows Authentication:
Trusted_Connection=True
Remove this part of the connection string and give it another try.
The reason for the error goes along these lines:
IISExpress runs as a normal process in your logon session. So it runs with your Windows Credentials. When your app is running inside IISExpress it is actually running under your credential, and when you connect to the database using Windows Authentication, is your login that SQL Server will receive.
The full IIS on the other hand runs as a service under a different session and a different user account. There are the application pools that also play a part and run under yet another account. But the main thing is that those default IIS accounts are local accounts, so they have no "visibility" to another computers. Hence when your app tries to connect to SQL Server, SQL "sees" the machine account, which goes by the name DOMAIN\MACHINE$.
Most likely, ASPNETCORE_ENVIRONMENT is not set correctly on the server (i.e. either not set at all or not set to Production).
On your server, edit the system environment variables and add one (if it doesn't already exist) with the name ASPNETCORE_ENVIRONMENT and the value Production. Also, edit the advanced settings of your app pool in IIS for the application and ensure that the key Load User Profile is set to True.
I'm just in the process of trying to properly configure asp.net 4.5 on our IIS servers.
I have been able to navigate and launch an ASPX page that contains no data conenctions sucessfully so I know that the application pool authentication to the local directories is working as it should.
Now though I have a seperate SQL server that is connected to the domain and have a connection string stored in the code that connects the ASPX page to the server using a trusted connection. When running in visual studio debug mode, the connection works fine - but at that point I assume it is using my login credentials.
My question is, when a user calls the aspx page via the browser when hosted on the new IIS7 server, which account is used to call the SQL server when using a trusted connection? - Is it the end users or is it a local account from the IIS server?
When I call a page with data connections embedded I get the error: Login failed for user ADMIN\PCNAME$ ... which is an indication that this is the account that it is using. However this account doesn't exist on the domain that I'm aware of. - Or does it ?!
Thanks in advance,
It will use the account that ASP.NET is running under, as you've worked out. What you usually should do is create a Domain Account (with the right privileges) and run your ASP.NET AppPool under that account. Then a Trusted Connection will use that account for connecting to the database, and as long as you've given it access (which as a Domain Account you can do) it should all work.
Added:
After some back and forth on comments, lets go back to the start: set the new AppPool to run with the domain users account, and recycle the AppPoolo. What is it that says the password is wrong? If it's IIS trying to start the AppPool, then it is extremeny likely that the Password you gave the AppPool IS wrong, or else that the password is set to change on first logon.
If its not IIS, but opening a Database connection, are you sure that the database allows this Domain Account access to the database and the tables within it it will need? What roles have you assigned to this account? Also, what SQL statement is it trying to execute (if it's got far enough to try and execute a statement at all)?
I suggest you put any response in you original question - comments get to be a drag if there are too many of them.
I have an issue with logging a Support user into an Application that has a SQL Server backend.
When configuring the application itself, the SQL set-up asked me to assign whether the Security to access the Application would be Windows Authentication or SQL: server Authentication, I chose Windows Authentication, and as I was using a login called
'LabUser1' I have been able to login to the application fine.
However, when I logon to the server using a different windows login, this time 'Support', SQL keeps giving me the error:
Error accessing the database DSN
Now I know the reason is because the install of SQL happened using the 'Labuser1' profile, but how can I create a script that will allow me to add the 'Support' user to the 'Allowed Logins' so that I can logon to the app server and at least open the Application? (I have seperate logins for when I see the applicatiojn login window, so please don't confuse the matter by thinking it is a simple case of creating a login for Support....I am talking about logging into the server)
The current batch file I am trying to run is:
sqlcmd -S localhost\OCDBB01 -i createSupportlogin.sql
Then I run this batch file after having created the following SQL script:
CREATE LOGIN OCDMW1\Support FROM WINDOWS
GO
Your description of the situation is a bit confusing to me however it appears that the "SQL setup" that is part of the application configuration created a ODBC DSN that uses the credentials of person logging into the machine as the login for SQL Server.
Simply creating a new (correct) login to the SQL instance may not resolve this issue since that does nothing to modify the DSN. If you are tied to using Window Authentication for SQL access it might be necessary to create multiple DSNs for the application to use and find a way to have the correct DSN associated to the right login for the application to use.
Oh yes, the famous error:
Cannot open database "MYDBNAME" requested by the login. The login failed. Login failed for user 'USERNAME'.
Let me explain my situation:
I have a database server, which has a SA account and my user account. The user has the correct mappings to my database (dbowner).
I can open the database with this user, using SQL Management Studio 2008 R2, both on the SQL server itself (using localhost), and on my frontend server.
However, when I run my application, I get the login failed error.
Strange thing is I have a test application and a production application on our frontend server. The test application has test databases on the same database server, and there are no login problems here. The only difference between the two, are the prefix which differs from "TEST" to "PROD". The test application works, the production however, doesn't. The user mappings and seem it should work on both.
Any ideas?
EDIT:
Our connectionstring:
<add key="umbracoDbDSN" value="Server=Websqlsrv01;Database=PROD_Databasename;User ID=umbraco_user;Password=password;Trusted_Connection=False" />
Sql server has a dichotomy login/user
they are 2 different entity:
http://www.akadia.com/services/sqlsrv_logins_and_users.html
maybe your sql login is not associated with an user for database PROD_Databasename but only for TEST_Databasename
another cause could be the user default database or eventually different database schemas
you can easily check if one of those is the problem simply creating a new user for PROD_Databasename and using it in connectionstring.
another way is to execute
exec sp_helpuser
in both databases (PROD and TEST) and see if the username "umbraco_user" is listed.
Anyway it is not a good practice to use same login for 2 different users:
https://dba.stackexchange.com/questions/16374/is-there-any-benefit-to-having-one-sql-server-login-for-multiple-users
Sometimes you need to use servername\instancename in your connection string if you've setup something other than a default instance. Use this link to find your instance name. Give that a try!
right click on you application and run as admin. This should work!
why this error comes?
I am using windows authentication. But i am getting error
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
can any one help me in this how to solve this problem?
Most likely it means you're trying to connect from an impersonated context and you did not set up constrained delegation. See Manage Kerberos Authentication Issues in a Reporting Services Environment for details and troubleshooting.
First of all, I always prefer to use the 'impersonation' settings in the ISS configuration that do not set the user/password in the web.config. Everything was fine in the QA environment, but then I passed to the production environment and some options of the web site in production started to show the 'Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error.
The issue was that I copied the web-site configuration from the QA server, using the 'Save configuration to a file' option in IIS6 while creating a brand new Application Pool in the production server.
After several hours trying to solve this error, I just deleted the Application Pool, and used the 'Save configuration to a file' option to copy the Application Pool configuration and then restored it to the new server.
If you copy the web-site configuration, also copy the Application Pool configuration. That solved my problem, without changing anything about the authentication method, the database or the web-site itself.
Reporting Setup:
I had a report accessing datasource A, with a subreport which accessed datasource B.
The report connections were set to use Integrated Security.
From my development machine:
The "main" report would run perfectly fine from my development environment (as it was running everything as me.)
From the server:
I was able to execute the subreport directly, with no problem.
The main report would run, with the text "Error: Subreport could not be shown."
Actual Problem:
The subreport was executing under the NTAUTH\ANON user, because it was the Reporting Services code which was calling the sub-report. This error was in the SSRS Logs:
System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Solution:
Set up the sub-report data connection to execute using a SQL User login.
Only grant that user execute on the particular procedure you're calling for the report.
This allowed me to get the report working without involving other departments that controlled the application servers (modifying web.configs or IIS configurations)