I wonder if I can assign xp_cmdshell_proxy_account to [NT Authority\Network Service]. Basically, I want network users to execute xp_cmdshell without giving them sysadmin role.
I tried
EXEC sp_xp_cmdshell_proxy_account [NT Authority\Network Service], 'password'
but I got error saying :An error occurred during the execution of sp_xp_cmdshell_proxy_account. Possible reasons: the provided account was invalid or the '##xp_cmdshell_proxy_account##' credential could not be created. Error code: '1326'.
I tried to run sql server as administrator too, but I got the same error.
The only thing I do know on this, is what I've done in the past on this.
I remember that it is possible to run xp_cmdshell using whatever valid system credentials desirable.
I also remember that I needed to have xp_cmdshell run windows scripts to get some files from a network location, such as "\\somePC\c$\somefolder\*.*" and to do this I needed the SQL Server windows service, to have it run by a valid account other than Network Service or Local Service etc. It needed a normal let's say, account. Otherwise it wouldn't work.
Related
I have an SSIS Package that runs via a SQL job on a SSIS server (Server A) that executes a stored procedure on the database server (server B). This stored procedure does a Bulk insert from a file share that is located on the SSIS Server (Server A). However, every time that the stored procedure runs it fails with the follow error:
Execute Membership Process:Error: Executing the query "exec storedprocname ?, ?" failed with the following error: "Cannot bulk load because the file "\ServerA\TestLoads\Membership\Processing\filename.csv" could not be opened. Operating system error code 5(Access is denied.).". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I am pretty positive that the issue is related to permissions. If I store the files on the database server (Server B) then it processes. Or if I run the proc manually, it will work.
When I execute the job on Server A it executes as the service account for that server. That account has full access to Server A and Server B (Admin in SQL and on the server). I believe what is happening is the credentials get passed the first time, but they are not continued once the stored proc runs. I ran wireshark on Server A (SSIS Server) so that I could see what was access the share and try to get some more information. What I found was that there was no account information being passed, it was just blank.
I went through a lot of steps just to try to see if could get that work such as granting everyone access to the share, enabling the guest account, allowing anonymous users, etc. Not stuff I would want to do, but trying to narrow down the issue. None of those worked.
I tried modify the stored proc to use WITH EXECUTE AS OWNER. Still did not work, but got a different error. Also tried a variety of other accounts to execute as and got the same error each time.
Execute Membership Process:Error: Executing the query "exec [storedprocname] ?, ?" failed with the following error: "Could not obtain information about Windows NT group/user '', error code 0x5.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Tried a variety of solutions that I found online to get this to work and nothing so far has done it.
I understand that is not an ideal solution. I was under the impression that the developers where using SSIS to load the file initially and then using SQL for the rest of the process which would have worked. But because SQL has to touch the file system it keeps failing. And at this stage, there is not the option of rewriting this. Additionally, this process will work if we move the files to the database server (Server B), but that eliminates a large need for us in having the SSIS server in the first place which was to get files being processed off of the database server
Any ideas on if there is a way to get the current solution to work? Basically, what I think I am needing is to run the SSIS package and for a way to pass credentials via the stored proc to the file share during that process.
We are using Windows Server 2012 R2 on both servers and SQL Server 2012 sp3 Developer edition.
Thanks for the help!
I've had this issue before, and I still don't fully understand Kerberos authentication, but that fixed it for me. It's something to do with "double-hop" of authentication i.e. creds going from SSIS, through SQL Server, to a network Server.
Try setting up Kerberos Authentication for SQL Server. There are detailed step-by-step instructions with screenshots here => Setup Kerberos Authentication for SQL Server
I understand this is like a "link-only" answer, but I don't want to copy-paste & plagiarize the author's original works i.e. blog post, hence the link.
I am unable to grant access to a newly restored database using sp_grantdbaccess. I am trying to do this via dynamic sql like below.
DECLARE #grant_access nvarchar(500)
SET #grant_access = 'EXEC ' + #new_db_name + '.dbo.sp_grantdbaccess ''IIS APPPOOL\myApp'''
EXEC sp_executesql #grant_access
I get the below error back trying to run this from a sproc. Any ideas on how I can grant permission for the app to call sp_grantdbaccess etc? I guess I am needing permission to give permission...
Error restore_backup restore_new_configDBThe server principal "IIS
APPPOOL\myApp" is not able to access the database "new_db_name" under
the current security context
Based on the error message it looks like you are trying to grant access to IIS APPPOOL\myApp using the security context IIS APPPOOL\myApp, but IIS APPPOOL\myApp doesn't have the access rights to the db to grant access rights to itself. I think this is akin to me trying to grant myself access to my neighbors house, but I don't have any authority to do so.
Depending on what type of security policies you are working under, I would either run the app pool under an account that has the greater privileges through integrated auth (but this might negate your need to grant privileges), or execute these SQL statements using a local SQL account with the necessary privileges to the database. In these cases, it would be like asking my neighbor (elevated access) to let me (IIS APPPOOL\myApp) in.
If you think it should work because IIS APPPOOL\myApp had access to the DB prior to being backed up, could this be a problem with IIS APPPOOL\myApp being an orphaned user? See http://msdn.microsoft.com/en-us/library/ms175475.aspx But with this case, you still might run into the above scenario trying to fix the orphaned user.
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 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.
I am creating a SQL Server Replication using a script. When I try to execute
The job failed. Unable to determine if the owner (STAR\moorer7) of job L3BPT2M-Atlas-14 has server access (reason: Could not obtain information about Windows NT group/user 'STAR\moorer7', error code 0x5. [SQLSTATE 42000] (Error 15404)).
This is a job created by a script that defines replication.
How do I debug this?
Active Directory is refusing access to your SQL Agent. The Agent should be running under an account that is recognized by STAR domain controller.
For me, the jobs were running under DOMAIN\Administrator and failing with the error message "The job failed. Unable to determine if the owner (DOMAIN\administrator) of job Agent history clean up: distribution has server access (reason: Could not obtain information about Windows NT group/user 'DOMAIN\administrator', error code 0x5. [SQLSTATE 42000] (Error 15404)). To fix this, I changed the owner of each failing job to sa. Worked flawlessly after that. The jobs were related to replication cleanup, but I'm unsure if they were manually added or were added as a part of the replication set-up - I wasn't involved with it, so I am not sure.
We encountered similar errors in a testing environment on a virtual machine. If the machine name changes due to VM cloning from a template, you can get this error.
If the computer name changed from OLD to NEW.
A job uses this stored procedure:
msdb.dbo.sp_sqlagent_has_server_access #login_name = 'OLD\Administrator'
Which uses this one:
EXECUTE master.dbo.xp_logininfo 'OLD\Administrator'
Which gives this SQL error 15404
select text from sys.messages where message_id = 15404;
Could not obtain information about Windows NT group/user '%ls', error code %#lx.
Which I guess is correct, under the circumstances. We added a script to the VM cloning/deployment process that re-creates the SQL login.
In my case I was getting this error trying to use the IS_ROLEMEMBER() function on SQL Server 2008 R2. This function isn't valid prior to SQL Server 2012.
Instead of this function I ended up using
select 1
from sys.database_principals u
inner join sys.database_role_members ur
on u.principal_id = ur.member_principal_id
inner join sys.database_principals r
on ur.role_principal_id = r.principal_id
where r.name = #role_name
and u.name = #username
Significantly more verbose, but it gets the job done.
Just solved this problem. In my case it was domain controller is not accessible, because both dns servers was google dns.
I just add to checklist for this problem:
check domain controller is accessible
I was having the same issue, which turned out to be caused by the Domain login that runs the SQL service being locked out in AD. The lockout was caused by an unrelated usage of the service account for another purpose with the wrong password.
The errors received from SQL Agent logs did not mention the service account's name, just the name of the user (job owner) that couldn't be authenticated (since it uses the service account to check with AD).
I had to connect to VPN for the publish script to successfully deploy to the DB.
In our case, the Windows service account that SQL Server and SQL Agent were running under were locked out in Active Directory.
I just got this error and it turns out my AD administrator deleted the service account used by EVERY SQL Server instance in the entire company. Thank goodness AD has its own recycle bin.
See if you can run the Active Directory Users and Computers utility (%SystemRoot%\system32\dsa.msc), and check to make sure the account you are relying on still exists.