I'm working on improving some sql stored procedures and our server health monitoring processes that are mainly driven by sql today. One of them is checking the server hard drives bitlocker status.
I have a sproc that runs xp_cmdshell 'manage-bde -status' and looks for the auto unlock status for our external back up drive.
Running it through the stored procedure that runs as a SQLServiceAccount administrator account returns auto unlock enabled.
However running it through cmd line on any other local user account shows it disabled. Not finding much about this online, anyone have experience with this?
Related
Problem
I have developed an SSIS package for an ETL process, which I have deployed successfully to a remote server. I have windows and SQL logins for this server, but not admin. The data that this ETL process loads is generated on a different machine on a different domain early in the morning each day (i.e. before I get to work) and needs to be automatically loaded after the data generation process as soon as possible.
Currently, I manually run the ETL package in SSMS, and authenticate this by spoofing the windows user credentials on the remote server by launching SSMS with runas.exe. This is currently okay since we are in early development, but this is obviously not an acceptable solution in production. Hence, I would like to automate this process, since a) the data is extremely time sensitive and b) manually running this process is a PITA.
How should I go about automating execution of the ETL package such that:
Execution happens immediately after the data is available, and
No user input is required from me e.g. to enter passwords?
Attempted solutions
Scheduling a SQL server agent job on a schedule is not an option, because of the time sensitivity. (Also my sysadmin seems to have not enabled/disabled the SQL server agent)
Continuing to use runas.exe is not an option either, as the /netonly flag, which is required, and the /savecred flag, which would prevent the need for manual password entry, are mutually exclusive.
sqlcmd.exe can be scripted to run with a SQL user and password (bad practice putting passwords in plain text, I know) but then running a stored procedure that calls the SSIS package fails, as windows authentication is required to run the package.
I would strongly advice you to ask for working SQL Agent and create an Agent Job to run the package. This way has a lot of advantages:
Native Windows user credentials management with proxy accounts
You can configure specific values for package/project parameters, connection managers via SSMS interface
You can use environment references of SSIS 2012 and above, and manage it via SSMS as well
Job can be started on schedule or manually from SQL command. Thus you can automate package start.
In a nutshell - it is much easier to manage and you do not disclose user credentials needed to run the package - you might even do not know it.
For the alternative - you can try PsExec from SysInternals tools. It allows to start program on another computer explicitly specifying username and password as psexec \\server -u user -p password .... However, I would opt against it.
Running a Cmd.exe inside an ETL Process Task and it's failing with Exit code 1.
If I run the command as the same user I'm running the SQL Agent job as outside of the ETL it's running fine and giving Exit code 0.
I've seen some DCOM errors in Event Viewer and Ive taken steps to give permissions to the user I'm running the ETL through the SQL Agent Job for. However it's still failing.
Are there other things I should check about running a CMD command across servers as a specific user?
Just to say this was a permission issue ultimately for it to write a file inside the Default folder. It wasn't manifesting as such until I dumped out the Log a little more. I had to make the user I was running the agent job to be a part of the Administrators group on the SSIS server to allow the process to work.
I'm trying to add a new database device using SAP ASE Cockpit Database Creation Wizard.
The script issued behind the wizard is the following:
set quoted_identifier on
go
USE master
go
disk init name='COMERCIO', physname='C:\SAP\data\COMERCIO.dat', size='100M', cntrltype=0,vdevno=5, dsync=false, directio=true, skip_alloc= true
go
set quoted_identifier off
go
But it only shows me the following error:
"JZ0PA: The query has been cancelled and the response discarded"
My environment is a Test machine running Windows 7 x64. I have plenty of hard disk space and I have an Administrative Account available. Also, I have "Full Control" privileges in the 'C:\SAP\data\' directory folder.
The server Log does not show any particular remark pointing to this issue, the only thing that records is the following:
00:0006:00000:00033:2017/01/23 11:49:52.69 kernel warning: Ignoring the 'skip_alloc' option for device "ะค ", as it is not applicable to the special devices.
Any ideas?
I finally solved the problem. Here is what I did:
From the very beginning I suspected a permissions problem. I suspected the user at the prompt, the SA account and even suspected not to have enough/right file writing permissions at some level.
I had to uninstall the Sybase ASE engine completely and started all over again. This time:
a. First of all, created an user with Local Administrator privileges, only to run Sybase's Services.
b. Created a folder reserved to hold Sybase's Devices. Tested first if it was possible to fully read/write everything in that folder using the account created in step a.
c. Installed Sybase ASE 16.0 SP2. At the step indicated by the installer, choosed the the account created in step a to be responsible of Sybase Services.
d. Done.
Thanks to the people who took the time and effort to read this post.
I'm trying to set up a Stored Procedure as a SQL Server Agent Job and it's giving me the following error,
Cannot bulk load because the file "P:\file.csv" could not be opened. Operating system error code 3(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 4861)
Funny thing is the Stored Procedure works just fine when I execute it manually.
The drive P: is a shared drive on Windows SQL Server from LINUX via Samba Share and it was set up by executing the following command,
EXEC xp_cmdshell 'net use P: "\lnxusanfsd01\Data" Password /user:username /Persistent:Yes'
Any help on this would be highly appreciated
I do not know if you solved this issue, but I ran into the same issue. If the instance is local you must check the permission to access the file, but if you are accessing from your computer to a server (remote access) you have to specify the path in the server, so that means to include the file in a server directory, that solved my case.
example:
BULK INSERT Table
FROM 'C:\bulk\usuarios_prueba.csv' -- This is server path not local
WITH
(
FIELDTERMINATOR =',',
ROWTERMINATOR ='\n'
);
To keep this simple, I just changed the directory from which I was importing the data to a local folder on the server.
I had the file located on a shared folder, I just copied my files to "c:\TEMP\Reports" on my server (updated the query to BULK INSERT from the new folder). The Agent task completed successfully :)
Finally after a long time I'm able to BULK Insert automatically via agent job.
Best regards.
I have solved this issue,
login to server computer where SQL Server is installed get you csv
file on server computer and execute your query it will insert the
records.
If you will give datatype compatibility issue change the datatype for that column
Using SQL connection via Windows Authentication:
A "Kerberos double hop" is happening: one hop is your client application connecting to the SQL Server, a second hop is the SQL Server connecting to the remote "\\NETWORK_MACHINE\". Such a double hop falls under the restrictions of Constrained Delegation and you end up accessing the share as Anonymous Login and hence the Access Denied.
To resolve the issue you need to enable constrained delegation for the SQL Server service account. See here for a good post that explains it quite well
SQL Server using SQL Authentication
You need to create a credential for your SQL login and use that to access that particular network resource. See here
I would suggest the P: drive is not mapped for the account that sql server has started as.
It's probably a permissions issue but you need to make sure to try these steps to troubleshoot:
Put the file on a local drive and see if the job works (you don't necessarily need RDP access if you can map a drive letter on your local workstation to a directory on the database server)
Put the file on a remote directory that doesn't require username and password (allows Everyone to read) and use the UNC path (\server\directory\file.csv)
Configure the SQL job to run as your own username
Configure the SQL job to run as sa and add the net use and net use /delete commands before and after
Remember to undo any changes (especially running as sa). If nothing else works, you can try to change the bulk load into a scheduled task, running on the database server or another server that has bcp installed.
I did try giving access to the folders but that did not help.
My solution was to make the below highlighted options in red selected for the logged in user
We are in the process of migrating from SQL 2000 to SQL 2005. We have hundreds of DTS pacakges, that the development team is reluctant to redevelop using SSIS.
When migrating these packages to SSIS, I am faced with a problem - many of these packages read from Excel files.
Given that my production Box is 64 bit, I am forced to use CmdExec sub-system to call the 32 bit runtime to execute these packages.
My question here is : What are the security risks involved with using CmdExec subsystem to schedule these SSIS packages as SQL agent jobs?
Thanks,
Raj
Whatever account running the job will potentially have access to run commands from the command line - so you need to think about how it will be running and what permissions the account will have.
For example, if a user could create a job that would run under the context of your sqlagent and your sql agent was overpriviledged (rights to change security), she could grant herself elevated privs or hurt your machine.
SQL 2008 introduced a switch for DTExec that allows you to run the packages in 32 bit mode using the native SQL Agent task for SSIS. On the execution tab of the job step properties there is a check box for 32 bit, which translates to the "/X86" switch when looking at the command line view.
If you are stuck using SQL 2005 then the CMDEXEC option is the only one I know of.
xp_cmdshell is the biggest security risk in SQL Server because it allows a compromised SQL Server box to elevate the attack to the host operating system itself, and from there to the entire network.
The typical vector of attack is web site HTTP form -> SQL injection -> xp_cmdshell -> take over SQL hosting machine -> take over domain. If xp_cmdshell is shut down then the attacker has to find other means to elevate its attack from SQL to the host.
Other scenarios exists, like insider users using it to elevate privileges, or using the cmdshell for other purposes, eg. steal a database. All are based on the fact that xp_cmdshell allows arbitrary commands to be executed and on the host, and in some cases the commands executed also inherit the SQL Server service account privileges.
There are other commands and extend procedures that can be used by an attacker if xp_cmdshell is blocked, but they far less known. Using the xp_cmdshell vector is in every SQL injection cheat sheet and forum discussion, so is known by everyone and their grand ma.