I have an extremely simple SSIS package on my SQL Server 2017 database instance, running via an agent job. I have created a credential and proxy account to run the integration service job. If the job owner is 'sa' the job will run fine. however if I change the job owner to the service account I need to have I get the following error:
The job failed. Unable to determine if the owner (THE_FUND\xyz_svc) of job MYPITAJob has server access (reason: Could not obtain information about Windows NT group/user 'THE_FUND\xyz_svc'<c/> error code 0x5. [SQLSTATE 42000] (Error 15404)
Additionally the service account is a local admin on the server, and sysadmin in sql server in an attempt to remove possible permission issues.
I created a credential using the service account as its identity. Then created a proxy account under SSIS Package Execution referencing the credential i created.
Would love to know what I am missing.
As it turns out the issue was related to Active Directory. The service account had no registered OU. Once the service account was removed, and recreated the OU was populated and everything with the SQL Server jobs started working. I guess sometimes SQL Server is not to blame. Once SQL Server was able to find the information it needed from AD, problem solved.
Related
I have a SQL Server 2019 with SSIS and I want to execute SSIS packages using SQL Agent jobs with proxy domain accounts.
Currently my sample SSIS packages are failing, all simply stating "Unexpected termination", with no additional errors in Basic or Verbose logging modes. Packages are doing various tasks, working with both local and remote files, all permissions to read/write to folders and files are set.
In the Event Viewer I can see the "The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID" for my proxy account.
Adding the proxy accounts to local Administrators group on VM solves the issue, but I would like to evade doing this.
Instead I have:
added permissions for my proxy accounts in Component Services/DCOM Config/Microsoft SQL Server Integration Services 15.0/Launch and Activation + Access + Configuration permissions
added proxy accounts to Distributed COM Users group. (basically following the SSIS Service MS Documentation these two solve the COM Server error)
granted local permissions to proxy accounts (Log on as a batch job, Log on as a service, Allow log on locally)
but I'm still ending up with Unexpected termination with no further errors/warnings and no further errors/warnings in event viewer as well.
Can anyone advise me what other (Windows) permissions am I missing so I don't have to resolve it using local Administrators group? Or where else I might find additional logs to search for errors?
I have a SQL Server service account: domain\sqlservice.
This account is running both SQL Server service and SQL Server Agent Service.
This account has read/write permission to a file share: \\fileserver\Path1, and from the SQL Server and SQL Server Agent jobs, we are able to write to this folder path using the service account (using master..xp_cmdshell. xp_cmdshell is enabled).
This permission got removed by mistake, now we have added it back.
I can use the service account domain\sqlservice to browse to \\fileserver\Path1 and create files and folders (using Windows Explorer), but SQL Server and SQL Server Agent jobs still could not.
I have restarted the SQL Server Agent service (I believe this is account used to access the file share when running the SQL Server Agent jobs).
But it still failed to access the path - I get an access denied error.
I think I will need to restart the SQL Server service to fix this issue (waiting for my maintenance window now).
I want to understand it better, can someone give me some hint on why SQL Server Agent job is related to the SQL Server services running account? And what is the relationship between SQL Server Agent job service account and SQL Server service account? Are we still utilize this account to access fileshare defined in the SQL Server Agent job?
Thank you all very much
It looks like it takes time for the service account to get updated.
So I rerun the task in 10 hours
and task runs fine.
So I guess you have two options.
wait for the token or something expire and renewed.
you can restart the service.
#Charlieface’s comment explains the reason:
Double check that SQL Server is definitely still running under that service account, as well as which account has now received permissions to the share. The permissions for xp_cmdshell depend on whether the session has sa rights, see learn.microsoft.com/en-us/sql/relational-databases/…. Quite why you are using xp_cmdshell is a different question: it has major security implications, and should probably be converted into a SQL Agent job written in Powershell.
I have done much searching on this without a solid solution.
I just set up a new SSRS instance on the same server as my SQL 2016 instance. Everything is running fine report wise, etc. The problem is that when a report is scheduled, it creates a Sql Agent Job in SQL Server, and the SQL Agent is erroring out with the following:
The job failed. Unable to determine if the owner
(MyDomain\ReportService) of job 17F8E31D-0838-4829-8C3C-E3FE5BBD3483
has server access (reason: Could not obtain information about Windows
NT group/user 'MyDomain\ReportService', error code 0x5. [SQLSTATE
42000] (Error 15404)).
Current setup:
SSRS using an Active Directory account as the service account called
Report Service
Sql Server 2016 Engine is using an Active Directory account as the service
account called SqlService
Both SSRS and SQL Database are on the same machine
I double checked that SqlService is SysAdmin and has all other
permissions, and non-SSRS jobs run fine
From my research, I can solve this in one of three ways:
Change the SSRS SQL Agent job created by SSRS to be owned by SA (by
default the job is owned by MyDomain\ReportService). The problem
with this is that I would have to do this every time a user creates
a new subscription via SSRS or create an ongoing script because SSRS
by default will use the service as the owner. And I KNOW that this
was not done at my previous employer.
I could make the SqlService a
domain administrator. I don't want to do this for security reasons,
obviously.
I could give the SqlService "SeImpersonatePrivilege"
(Impersonate a client after login) on my domain via the security
policy. This also works, but there seems like there would be a
better way, and I would think this is also a security risk as
setting this doesn't explicitly limit SqlService to only
impersonating the ReportService.
So, my question is hopefully from those who have set SSRS up, what is the best practice for allowing SQL Server to run the SSRS subscriptions? It's possible that something in our environment is messed up permissions wise, but I guess mostly I'm looking for advice on how should this be set up. Thank you greatly in advance.
I eventually discovered that we had some kind of limitation on the active directory rights of the service account. I wasn't unable to pinpoint the exact permissions, but after adding the account to a group that explicitly allowed viewing active directory users and groups, it worked. So, this was due to abnormal limitations for basic domain user rights.
Link
From the site listed above:
Could not obtain information about Windows NT group/user ‘domainuser’, error code 0x5. [SQLSTATE 42000] (Error 15404)(ConnIsLoginSysAdmin)
The solution to this is to add the SQL Server service account to the ‘BUILTINWindows Authorization Access Group’ on your DC.
You can then run “EXECUTE AS USER = ‘domainuser’” on SQL Server to check.
I have a an SSIS solution that runs fine in BIDS. However, once I try to deploy it to the server and execute through SQL Server Agent, it fails with:
Cannot access datafile...
Details:
server: localhost that I built
sysadmin: my local domain account is the sysadmin using Windows Authentication
filepath: my local C:\Users\me\Downloads
I have tried mapping my login to a credential and using that credential as a proxy, but it still fails.
Can someone help with a step-by-step solution as to how to make sure the SQL Server Agent account has access to write and read files on my local file directory?
look that：
What is the service account for SQL Server Agent? Is has privilege to access operation sytem?
I am running SQL Server 2014
I am trying to set up a scheduled SQL Agent job that runs an SSIS package and I need it to use a SQL Authentication login in order to access all the applications/servers the SSIS package accesses.
I have created a Credential that is mapped to the SQL Authentication login and connected it to a Proxy which the SQL Agent runs as when accessing the SSIS package, however, the job fails with an error message:
Unable to start execution of step 1 (reason: Could not get proxy data for proxy_id = 1). The step failed.
I have confirmed that:
I can access all servers/applications using the SQL Authentication account
The SSIS package connections are configured for SQL Authentication
I can run the SSIS package manually using the SQL Authentication fine
All accessed SQL Server Databases are configured for both Windows AD and SQL authentication login
When I create the SQL Server Agent Job, the step that runs the SSIS package has an option for the SQL Server Authentication login but the option is greyed out and I cannot select it:
I feel like I am missing a very obvious step but it's eluding me, any assistance will be appreciated.
#oscar and #chuck are both correct SQL Agent jobs running SSIS packages cannot run in SQL Authentication mode they have to use Windows Authentication. The user that runs the agent job unless you specify otherwise is the SQL Agent service account. It is that service account and the SQL Service account on the server you are running it on that will need certain permissions. However, you can change which account it executes as per chuck's note. Of course depending on who many different servers you are passing credentials and what is being accessed you can also get into a kerberos double hop problem...... Trust me solving that last part not so fun but still doable.
However the thing is if you must use SQL Authentication you don't need a windows user at all. you can put the SQL Authentication credentials in your connection strings of the connection managers in SSIS package. The SQL Agent service account can handle any file access issues for you and your connection strings can pass the sql credentials. no double hop problem and easy. If you are worried about embedding credentials you should use a less privileged sql account but you can also encrypt them and store them with the package. There are also several ways of dynamically getting them from an encrypted state.