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;
Related
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!
The Plan
Have HR personnel dump an Excel file of payroll Job Titles to a network share, add that file as a Linked Server in SSMS, use those titles in my ASP.Net web forms. Using a Linked Server instead of importing data to allow HR to update the Job Titles file at their discretion.
The Problem
I can create the Linked Server and query it without issue, so long as I'm in SSMS with Windows Authentication. But, if I try to access the linked server using a SQL account, I first get the error:
Access to the remote server is denied because no login-mapping exists (Error 7416)
The SQL account being used is the same account my web forms use for everything else. The fact that this SQL account doesn't have file permissions isn't surprising though, so an adjustment to the Linked Server's security should do the trick.
The Problem (part 2)
To reduce the number of variables, I moved the Excel file so it's on the same machine as my SQL Server. I'm logged into the machine and logged into SSMS with my domain admin account.
I access the Linked Server's security tab and, to try and cast the widest net possible, I leave the local login (top part) blank and head straight to "Be made with this security context:" and proceed to provide my domain admin credentials. I hit OK, and I get the following:
Not a valid account name or password (Error 7399)
I know the account name and password are good, so what gives?
Other Things
Folks who've ran into similar things have been instructed to change the logon account being used for the SQL Server service, which I've done using my domain admin account (for troubleshooting, atm). This did not fix the problem.
This is what the Linked Server code looks like, although I created it via the GUI (included for sake of completeness):
EXEC master.dbo.sp_addlinkedserver #server = N'ADP_TITLES', #srvproduct=N'', #provider=N'Microsoft.ACE.OLEDB.12.0', #datasrc=N'C:\JOB_TITLE_EXPORT.xlsx', #provstr=N'Excel 12.0 Xml'
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'ADP_TITLES',#useself=N'False',#locallogin=NULL,#rmtuser=N'DOMAIN\username',#rmtpassword='########'
The solution appears to be entering "admin" for the remote login, and leave the password blank.
This only works, however, if the file is stored locally. If it's on the network, I still get a 7399 error, but instead of saying the issue is the account name/password, it now says the issue is unspecified.
I can make my project work with a local file though. Since I'll be moving forward with that, I have no need to solicit additional answers.
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!
I have an SSIS package that transfers some tables to CSV files on a network drive; it runs fine from my computer manually. I store it on the server in the MSDB database and execute it from there and it runs fine, but when I create a job that has one step that runs the SSIS package from MSDB it fails saying it can't find the CSV file name.
I spent all day yesterday figuring out this means a permissions issue with whatever logon credentials are being used through the job. The job owner shows to be domain/myuserid and step properties show they are using windows authentication with my username. The problem is, I know I have access to this folder.
The first line of the error log says: "Executed as user: servername\SYSTEM". So I made sure user "SYSTEM" has access to the network folder I want to load the files on, but I still get the same error.
The command line looks like #command=N'/SQL "\SSIS package name" /SERVER servername /CHECKPOINTING OFF /REPORTING E'
edit: I found SQL Server agent job account issue where someone asks who the job is run under and marc_s says "I can't seem to find any definitive answers on that one, really. Since my Jobs typically select and update stuff in the database, I am lead to assume that the "Owner" account will be used by default, unless you specify some other account on a given step"
Which also leads me to believe it is using my logon information that has access
The best practice that we've been able to come up with here is to make a domain account for SSIS and then set up a Proxy in SQL Server that is used to run the SSIS Package in a SQL Job.
I would say that the servername\SYSTEM account is a local account, and therefore won't have access to network folders on other servers.
You probably want to run this as a domain account of some sort, which does have access.
Typically this will be the SQL Server Agent, so check in the Services list, in the control panel, and see what account is running the agent, and if necessary change it to the appropriate account.
This may have knock on consequences though, so be careful what other jobs are running.