I'm trying to run a SQL job (sql server 2008) every day that needs to read a file stored on another server. I have set up a share and I can access it using my user through windows explorer.
Then I set up the sql job to "run as" that same user, but it doesn't seem to be able to access the file.
I set up Delegation in Active Directory (windows 2003). This didn't solve the issue.
How can i access the file in the share?
Does that user have access to sqlcmd or whichever command line tools you're using to run the SQL?...Does that user have access to all the sql server obujects in the sql?
Related
I'm trying to create a linked table connection in MS Access to a SQL Server instance table through Linked Table Manager in the External Data ribbon.
To grant access to this SQL Server instance in READONLY mode, a DBA in the organization I work for create a new Domain User Account different from my personal one.
In other applications, Windows authentication as different user in case of Excel and Powerbi and Run as different for SSMS works fine.
In MS Access there is no -Use Alternative Windows credential- term of authentication and all the others that I have tried do not function (Active Directory Password/Integrated/Interactive/servicePrincipal).
Does anyone know a possible solution to access the SQL Server from MS Access using a different Windows Domain user?
open the command prompt in administrative mode and run the below command
replace <<domain\username>> with user details.
update the msaccess.exe location("C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE") if it differs in your system.
C:\Windows\System32\runas.exe /netonly /user:<<domain\username>> "C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE"
by this way ms-access will be opened using alternate user credential,
then click the "Linked Table Manager" and connect to SQL server, it will connect to SQL server using alternate user credential.
We have a legacy AS400 host system that runs our warehouse. We want it to securely trigger jobs on the SQL server that runs the rest of the business to enable automatic and timely data exchange between the two systems.
Currently we have the IBM iSeries Access for Windows client software installed on an old Windows SQL 2005 server. This allows the AS400 to run remote commands on a Windows box. The AS400 uses this client software to run batch files that execute dtexec on the SQL 2005 server box which then runs SSIS packages that exchanges data between the AS400 and the production SQL servers. The SQL 2005 box is just acting as a go between the AS400 and the production SQL servers. The two problems with this setup are:
The AS400 client software runs as a system process and not a network account so the SQL login info has to be included in the plain text in the SSIS files.
When dtexec is run it adds two entries into the Windows event log. We have several process that poll for new data every few minutes or in some cases seconds so the event log is consistently purging older entries which leaves about 4 hours worth of events. To say this makes it hard to troubleshoot errors on this box would be an understatement.
We are decommissioning the old SQL 2005 server box so I have to replicate this functionality on a newer server. I want to address these two issues before doing so.
I have tried using sqlcmd but since the AS400 Client software is running under a local system process it can't connect to the production SQL servers which are setup with Windows Authentication Mode. I tried using psexec which works if I leave a RDP session for the user open to but would still need the user name and password to be in plain text. I have been testing out having the batch file write a blank file to a directory and having the SQL job triggered by an WMI event. In testing this works but is unreliable when the job needs to be quickly triggered multiple times in a row, like most of our jobs need to be.
I have also looked into using the C# and .NET to store the password using the Windows Security classes and/or data protection API (DPAPI) but I am at best a intermediate .NET programmer so this is a worse case solution for me.
This has to be a common issue with integrating older host systems with SQL Server so I assuming there has to be a solution that allows for the Host system to call the SQL server in a secure method. If not a Job directly, run a stored procedure that can trigger the Job. Any alternative that does not require a the password/user name saved in plain text somewhere and not using dtexec would be appreciated.
LocalSystem Account "has extensive privileges on the local computer, and acts as the computer on the network."
This means you can grant it access to your remote SQL Servers by creating a login for the "computer account". If you server is named MyServer and the domain is MyDomain then:
use msdb
create login [MyDomain\MyServer$] from windows
create user [MyDomain\MyServer$] for login [MyDomain\MyServer$]
alter role SQLAgentOperatorRole add member [MyDomain\MyServer$]
And a process running as LocalSystem on the other server will be able to connect via Windows Integrated Auth and run SQL Agent jobs.
I'm having some trouble with my SQL Server Logons. I'm building an Excel Spreadsheet that will retrieve data from an SQL Server (2008) and then display it in what ever way is required etc...
I have set up a SQL User without Login 'genericReadOnly' and 'genericReadWrite', it was my intention to then capture the windows login with environ("username") which will then retrieve what reports that person is allowed to access. This was working fine whilst me and my team were working on it, but we are already set up on the SQL Server as 'Windows Users'.
I've now sent the file to someone who isn't also listed as a Windows User and it fails with ACCESS DENIED FOR DOMAIN\USERNAME, even though the connection string uses the genericReadOnly SQL Username.
Any ideas as I cannot add specific usernames for everyone that requires access.
I would suggest creating a domain group and add that group as a windows login to SQL instance with the appropriate permissions.
Then add anyone that needs to use your Excel file just has to be a member of that group and requires no changes to your code or SQL setup.
What should I do? I could disable UAC to access the database. Is there a way I could copy the my database but strip the account control informations attached to it? Many thanks.
Read this article for possible options. Excerpt: `After the SQL Server Instance starts in single-user mode, the Windows Administrator account is able to connect to SQL Server using the sqlcmd utility using Windows authentication. You can use Transact-SQL commands such as "sp_addsrvrolemember" to add an existing login (or a newly created one) to the sysadmin server role.
I have built an SSIS job in visual studio 2005 that accesses a flat file and updates a table in SQL Server 2005. This works perfectly. I then store a copy on SQL Server by using the server storage option in the protection level property. When I try to run this it cannot locate the flat file. The flat file is located on a server and I use the IP address to access it. I have noticed that if I remove my maping to this server and run the job from visual studio, it cannot find it either. Hoe do I access the file from SQL Server 2005 ? I intend to schedule this job to run automatically on SQL Server.
Many Thanks for any help you can give.
Ronnie Carlin
Just to avoid anything more complex being the issue, check what account the job is being run under (e.g. has a procy and credential) or whether it is using the base SQL Agent account, and then check whether that account has access rights to the folder \ file you are trying to import.
Had that catch us out more than once.
Edited to include the additional information in the main answer.
When SQL Agent runs a job it does not use your account, even if you initiated the job execution - it uses the SQL Agent account. The account the SQl Agent is set up under (by default) or a named account you specidy with a proxy / credential. You might be able to access the folder, but you need to check what account SQL Agent is running under and whether it can access it.
To find out which account the job is running under by default you can access it via
Start -> Program files ->SQL Server -> Configuration Tools -> SQL Server Configuration Manager. In the 2005 Services SQL Server Agent will be listed, right click properties, first tab shows what account the Agent is being run under.
However, if you need a job running under a specific account I would advise you create a proxy / credential and not alter the agent account - since that is the account all the other jobs are using.
Credential and proxy are different objects within SQL, Credentials are stored under the security folder / credentials - that is where you create a credential and place your AD username / pwd.
The proxy then asks you to select a credential from the list of credentials already stored on the system - not your domain\user at that point.