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!
Related
I'm trying to create a login on our test server with:
CREATE LOGIN [<DOMAIN>\<LOGIN>] FROM WINDOWS;
GO
As opposed to the live server the test server does not have any active directory. So it fails with:
Windows NT user or group 'DOMAIN\LOGIN' not found. Check the name again.
Worth to be mentioned, that on the test server we use a backup of a database dump from the last release and apply new migrations to this dump. This means, that this error would not occur, if a more recent dump from the live server was used, where the active directory login already exists.
To enable proper testing, we discussed three possible options:
Recreate the active directory on the test server: I would like to avoid this, because nobody really wants to administer an additional active directory clone for testing purposes.
Use a more recent database dump: The problem here is, that the live server is not ours and we only have restricted access to it. It is possible, but still not the optimal solution in regard to practicability. Also, it would mean, that we would play in migrations to the live server before having tested them on the test server.
Alternative SQL syntax: I am aware, that there alternative ways of creating logins, e.g., CREATE LOGIN <login_name> WITH PASSWORD. But I could not think of any way, which allows us to create logins depending on which system we are on.
Option 3 is our strong favorite, but we are missing a piece to the puzzle. Anything we are missing here?
You can create a new user on your local computer.
And then add this new user to the instance.
CREATE LOGIN [<domainName or your hostName>\<login_name>] FROM WINDOWS;
I have been able to set up an active directory login for my Azure database.
Now I want to add additional active directory logins and set their permissions
I understand that I need to use Management Studio to do this and have installed SSMS v17.8.1
I have been studying docs but I can't find the instructions
[Update]
After reading Conor's answer I was able to create the user
CREATE USER [jobuser#mydomain] FROM EXTERNAL PROVIDER WITH DEFAULT_SCHEMA=[dbo]
However if I try to login using MSSMS with Active Directory - Password authentication I get
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' (MIcrosoft SQL Server, Error 18456)
[Update]
In the Connection Properties Tab
I had to overtype with the database name
That particular page only shows an example using a SQL login/user, so I can understand why you are confused.
Please read through this page:
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-user-transact-sql?view=sql-server-2017
Specifically, you want to create a user using the AS EXTERNAL PROVIDER example. This tells SQL Azure (and SQL DW) to use Azure Active Directory instead of creating a SQL user. Please note that this does not (as of today) work in SQL Server. (SQL Server supports integrated authentication against a local Active Directory, but it just does not currently support the Azure Active Directory service).
Also, there is no specific requirement that you use SSMS to do this step. You can do it within SSMS, SQL Operation Studio, through one of the SQL client drivers in a program you write (or some third party program that can invoke SQL over them), sqlcmd, etc. You don't even need to have the latest SSMS to make things work (though it is recommend to get the best experience against SQL Azure including syntax highlighting).
Please give that a try and see if it gets you unblocked.
Best of Luck!
I have posted a related question few days back and provided its answer as well.
I am facing a strange issue, I have 2 servers first one is dev server and second is QA
When I execute the below line on dev server it works fine, but when I execute it on QA, it gives me the error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON', as I posted in my previous question.
EXEC master.dbo.xp_cmdshell ‘sqlcmd -D db_name -S server_name -i sqlfile’
To resolve the above issue I have provided the username and pwd in the above query and it is working fine on both DEV and QA server. But to provide the username and pwd is not a nice approach as if we will change the server or pwd it directly impacts my query. So I want to execute the cmdshell command without using username and pwd on QA as well.
Can anyone please tell me what I am missing on QA. I have already provided the permissions to cmdshell on QA
ANY QUICK HELP
This is because the user the command runs as is NT AUTHORITY\ANONYMOUS LOGON, and this login does not have access to the DB.
Consider this: everything must run under a user context. Every process needs a to have a windows user owning it.
The SQLCMD you are running - who is the windows user running it? it isn't you. It is the SQL Server service. (do some research on xp_cmdshell)
You first need to do some research on windows service accounts and understand what they are.
Then, some possible solutions:
A. Check what your QA SQL Server service is running as (in the logon tab in services.msc)
B. USe a linked server insteadm which can use your logon instead
C. You might also be able to use some kind of proxy (a windows user to override the SQL Service user just for this pupose) but I haven't investigated that.
i created a software in vb.net 2005. i create a database in sql server 2005. i connect it with window authentication. everything works fine.
but problem started when i replace my database with old database copyed from different computer.
i attach screnshot of both database with attached users.
old database
and new database is
when i try to connect my software with old database with window authentication, it is not connected.
can anyone please tell me what the problem is and how to solve this?
When you restore a Microsoft SQL Server database on a different machine, the user could be no more the same on the previous machine. Even if you see the same username listed.
This user is called an 'orphaned user'.
Meaning that there is no login id or password associated with the user since the original SID identifying the user is no more valid on the new machine.
You could check if you have this situation with
EXEC sp_change_users_login 'Report'
and, you could fix with
EXEC sp_change_users_login 'Auto_Fix', 'Gauntam-PC\Gautam'
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.