I have a job which tries to access data from a remote server. I have created linked server which is connected successfully. When I try to access tables by directly running the query it works fine. But when I run same query via job it throws an error "login failed for user".
Job is assigned owner 'sa' and running with ssis proxy with sysadmin and public roles. In security tab of linked server properties I have no mappings and "be made using the login's current security context" selected.
I am not sure how should I correct it. If I should add mappings then what should be mapped? Please help me as I already spend whole day exploring possible options but couldn't find anything useful.
It does not matter who is the owner of package. Only the user under whom the packet is launched is important.
If this user is Windows (Windows domen) user, read this link.
If your user is sql-user, check it password and permissions on linked server.
If all from previous step are correct, try to add this user to mapping with checked Impersonate checkbox.
Related
I received a ticket that someone of the BI team could not make use of a linked server. He got the "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'"-ERROR and sent me the query.
I ran the query and it ran just fine from the same exact SQL instance. I took over his machine and noticed that when I checked the Security settings in the Linked Server Properties on the SQL instance they are set to "Not be made" and could not be changed...
I check the same settings under my user and there they are set to the correct setting "Be made using the login's current security context".
Do the settings need to be set for every user? If so, how?
EDIT:
For the doubters
Our business has just changed Active Directories and the domain changed, from "YMS" to "YMSNET". So I used to be able to log in with "YMS\tkol" and I can now log in with "YMSNET\tkol" (these usernames and domains are faked for the purpose of example), but when I log in as that now, I can't actually expand any of the databases or look at any of the tables, I can just see a list of the database names. When I try to expand a database in the UI it says "This database is not accessible (Object Explorer)."
Now I have another user, called "sqluser", and I keep trying to use that user to log in as well by changing the Authentication Method to SQL Server Authentication rather than Windows Authentication. But I get Microsoft SQL Server, Error: 4064
Now I know this sqluser user exists and the password is correct, because I can authenticate to the server and successfully interact with the tables from an external process on a separate computer on the same network (node.js, package mssql). And I used the query on the accepted answer on this question, and found my sqluser is there, with roles db_accessadmin, db_ddladmin, db_owner. And yet it still won't let me log in with that user in the SQL Server Management Studio UI
How can I get this working again and log in with my sqluser account? Or add the appropriate permissions for my YMSNET\tkol account?
--- edit ---
My first idea is that, because I can log into the UI with YMSNET\tkol, but I can interact with the databases externally with sqluser, that there is some query or command I can run with sqluser that will add permissions for YMSNET\tkol so that that user can now look at all the databases and tables. I don't know which commands I'd run for that.
It can be because your account's default database is mapped to some another db which is not available for you, for instance, you have no permissions there, or that database not exists anymore etc.
Your organization DBA can fix it by:
ALTER LOGIN [sqluser] WITH DEFAULT_DATABASE = [rightDB]
Default db name can be checked by:
select default_database_name from sys.server_principals
where name = 'sqluser'
This property can be overridden by opening "Options" of SSMS connection window and specifying it explicitly:
I have some reports and a data source on a share point. Everything is working correctly, but I need to change the account used on the data source. I gave permissions to this new account to login in SQL server. When I set the credentials of the new account, on the share point data source, it fails with this error "Log on failed. Ensure the user name and password are correct.", but if I log in using the new account directly in SQL Server it works correctly. I think the problem is only when I try to log in using the share point data source.
Regards and thanks!
Check if the new account have the permission for SharePoint, if not, add the new user to SharePoint and set permissions for this user.
And I suggest you provide more information about the data source.
Running SQL Server 2016. Currently have a solution that is hosted in one domain and of course our access point is in another. we need to pull data in an automated fashion.
We have added a windows credential with the credential manager which collects endpoint information and a set of credentials.
e.g.
Internet or Networkaddress: mydatabase.remotedomain.com
Username : remotedomain\username
Password : password
This solution works with many tools, Excel, SSMS direct query, Visual Studio. The user enters the endpoint (server url or IP/port) and uses windows integrated security. the connection is made and credential store does the trick and user is authenticated.
SSMS example
Server name: mydatabase.remotedomain.com
Authentication: Windows Authentication
My challenge is SSIS and SQL Agent. The SSIS package runs in VS2015. deploy the package to Integration Services Catalog - highlight package and execute and it runs.
Create a SQL Server Agent Job and execute the job and I receive this gift.....
Login Failed: The login is from an untrusted domain and cannot be used with Windows authentication
I have created a SQL credential, created a Proxy (SSIS Package Execution), created a job that uses the Run As with the Credential but this ends with the same result. The credential has to be in my local domain or the job wont run....and of course localdomain\username does not authenticate against the remote data connection. So Proxy does not help the situation.
What I was expecting is that the windows credential manager would swap the credentials as it does when the job is run manually, or through excel or a number of any other ways...
I opened a ticket with Microsoft and worked with one of their senior resources on this.
this appears to be a bug in SQL Agent. There is no known reason or issue that prevents SQL Agent from picking up the remote credential from the Windows Credential Store, but it is not.
A working alternative was to use the command line utility DTEXEC. some slight modification to the SSIS project to make sure all connection managers are at the package level instead of project (created a reference issue).
this solution is not ideal, but it worked and DTEXEC allowed SSIS to pickup the required credential in the store and execute without issue.
I will follow up once Microsoft completes their research and gets back to me, the ticket is still open.
Sorry but changing the group to Global or Universal for the local AD account is not having any effect. I am bit lost on how making a change on the local account in use for SQL Agent will make any difference. The solution works in all the tools by local account substitution with the remote account setup in Credential Manager. If I missed it, and making this change should work, please provide an example of the setup if possible.
Again it appears this process is not being executed/followed by SQL Server Agent since it works everywhere else but not in a job executed by the Agent.
so again my hope is somebody has seen something like this before and has a solution.
my end goal is to just automate pulling data from a remote SQL server where there is no trust. I was hopeful that the proxy solution would work, but when you set the credentials to the remote domain\username, the job wont even execute.
Is there a way to setup my connection in the SSIS package to expressly set the credentials to the remote domain\username\pwd. I took a stab at that and couldnt get that to fly either. if so, an example is priceless to me.
I dont care how i get to the goal line, just need to...thanks all for the help
Your window credential account should be an AD user account which is in a Group with a scope of either Global or Universal. Universal groups are useful where you have multiple domains.
The process will execute in whatever context it's called in (i.e. by you, SQL Agent, or the proxy account). It doesn't change executable context as it calls different processes, unless you pragmatically make it, and that's bad idea anyway...
Had similar issue and it was a nightmare to resolve! Learned a lot of fun AD configuration tips along the way.
Understanding User and Group Accounts states the following:
Groups can have different scopes—domain local, built-in local, global, and universal. That is, the groups have different areas in which they are valid.
Global groups:
Groups that are used to grant permissions to objects in any domain in the domain tree or forest. Members of global groups can include only accounts and groups from the domain in which they are defined.
Universal groups:
Groups that are used to grant permissions on a wide scale throughout a domain tree or forest. Members of global groups include accounts and groups from any domain in the domain tree or forest.
EDIT
If it's just a data pull from one domain to another, can the data be first exported to a csv in the untrusted domain and then SFTP'd into your environment where the TL(Transform and Load) of the ETL(Extract-Transform-Load) process could take place?
SSIS would be a good tool for this, but C# and Powershell could also be used.
I just enabled remote connections on my SQL Server Express 2012 installation. Now I am a little bit worried about the server security because allowing connections to everybody sounds like a big security hole for me.
Is it possible to tell the SQL Server to disconnect if the user is trying to authenticate with a user which is not on my "allow" list? If so, I could add my monitoring user to this list and don't have to worry that my administration accounts are accessible.
First of all, this is probably a question that should be asked in the DBA site. Anyway, you can set up the security of the server so that only certain users are allowed to login.
When you set up the server, you add Logins to the Server Level and then Users at the database level. Only the users that are setup can, obviously, use a particular database. You can place users into roles, so, for example, they will have read-only access to a database. You can control, down to the object level, who has access to what.
There is a good article on what SQL Server security is about here
Having said that, sometimes, after, you have setup your security, you need to disallow certain users to not be allowed to Logon. Perhaps you are doing some major upgrade to the database. One option in this case is to create a Logon trigger.
A Logon Trigger will fire every time a user Logs in. You could create a table of "allowed" users and, in the trigger, if they are not in the table you ROLLBACK, effectively disallowing the Logon.
Here is information about creating a Logon trigger
You should be able to set up the db server to only accept connections from certain IP addresses, rather than to all of them. I'm unsure of the T-SQL syntax, but someone will surely chime in with the correct one.
If you really mean business, that being said, you'll want to authenticate clients using certificates that you give them. See this and the various articles it links to:
https://security.stackexchange.com/questions/14589/advantages-of-client-certificates-for-client-authentication
Being able to connect remotely to a SQL Server instance does not mean that they can Login to it. If they are not authorized properly, they should still get kicked-off by the SQL Server Login Authentication sequence.
This is silent/invisible for "Trusted Logins" (where the authorization comes from their Windows Login/Domain Account), but it still happens.
If you look under the "Security" folder of your Server (in SSMS), you will see the list of authorized Logins to you SQL Server. By adding or removing these you can control who can actually create a session on your SQL Server.