So, there used to be a very useful article explaining windows 2008 r2 uac and permissions here http://blog.akinstech.com/understanding-windows-7-and-2008-r2-uac-and-permissions/
This explains why even though you are logged on as a domain admin you still can't do anything because of the two tokens yada yada.
I kick myself since I didn't make a copy of the article
But his method to allow domain admins to use files with full permissions was to create a local group called F_FileAdmin and then use icacls to grant that group full rights to the C:\ and then add domain admins to that group. I thought it was a pretty elegant approach.
So, anyone know the icacls syntax off hand to accomplish this? And or can pull up the article from some cache somewhere and or contact Mr. akinstech and ask him to put this very useful article back online :)
A-Ha! I did save it. I realize I'm a year to late here, but maybe someone else can use it.
Create a group called F_FileAdmin and add the users you want to it.
icacls D:\ /grant "F_FileAdmin":(OI)(CI)F /T
This will add the “F_FileAdmin” group to the entire D: drive and propogate the permissions down to all subfolders and files, ensuring you have access.
Stick this batch file in your scripts directory such that it is in your path. Now on any server, from an elevated command prompt, you can provision a folder by simply typing:
setfileadmin d:\SharedData
setfileadmin e:\
setfileadmin "f:\Accounting Files"
Or even use it remotely like this…
setfileadmin \\MyServer\d$\GroupData
Related
Afternoon everyone,
I've tried to research this topic in depth and I cannot come to a conclusion for my problem. I'm trying to automate a batch file in Task Scheduler to execute two SSIS packages. Currently when I attempt to execute the scheduled task (either waiting for its set schedule or running on demand), task scheduler will show that the task has completed successfully, the "Status" will continue to say "Running" but the destination files are never created/re-created. This is the script:
dtexec /f "D:\SSIS\Folder\Folder\Folder\Package.dtsx"
dtexec /f "D:\SSIS\Folder\Folder\Folder\Package.dtsx"
The SSIS is supposed to pull information from SQL and export it to a CSV which it does wonderfully... If I execute this script in CMD, Powershell, or run my batch file directly.
About my environment:
My script resides on a SQL Server. (Windows Server 2016 Standard)
I have a domain admin account used for scripting permissions (all parent folders including the batch file itself have that domain admin added with full permissions, including the csv destination).
The scheduled task is set to: "Run whether user is logged on or not", "Run with highest privileges", Configured for Windows Vista and Windows Server 2008. I know my credentials are correct for my domain admin account.
In "Actions", "Program/script:" is currently set to "C:\Scripts\file.bat", there is nothing in "Add Arguments (optional):" currently, "Start in (optional):" is set to "C:\Scripts".
So here is what I've tried:
I've set "Program/script:" to "cmd.exe" and added an argument of "file.bat" with a start in as "C:\Scripts", no dice.
I've set "Program/script:" to "Powershell.exe" and set an argument of "-ExecutionPolicy Bypass C:\Scripts\file.bat" with a start in as "C:\Scripts", no luck again.
I added my domain admin account to the local administrators group on the server as well.
I've changed the user/group from my domain admin account to my domain admin account (the one I'm logged into the server with) and set it to "Run only when user is logged on", if this is set and I attempt to run the scheduled task, CMD flashes on screen and disappears before I can read anything (it's still too fast for the script to actually run, it takes ~20 seconds) and the destination file isn't altered.
(This one really stumps me) I've tried to add the script to another scheduled task on the server, that scheduled task will run on schedule and complete every script in the batch file except for these 2 lines. The other scheduled task it was added to uses the same domain admin account, same settings across the board, it even has other similar SSIS packages being run using "dtexec", I don't get it.
Thanks for any input anybody can give me, it's greatly appreciated.
I know this is a super old post, but I just had the same issue and wasn't successful with any other popular solutions around StackOverflow, so I want to put out an alternative solution for anyone still struggling!
When in doubt, double check the user account in the Security Options under Properties (right-click on Task > Properties > first page under "Security Options").
Even though the user that it had selected by default should have permission to execute the script, I had to change the user account to a user with a higher privilege (I'm on a work computer). For me, this meant I had to select the Administrator group on my particular desktop environment.
I am creating directories with xp_cmdshell but I can't delete them after because of the permission, I am not even allowed to see the owner of the folders.
I have to enter in safe mode to be able of delete the folders.
I am using SQL Server 2008.
Danger, Will Robinson, Danger!
This sounds like it might not be ideal from several angles - security, future-proofing, and scalability. Assuming none of those are priorities for your code, crack on with Edgard's answer.
Otherwise, I would question any design that has the DBMS (directly) write folders in the file system. I don't question that you have your reasons, it's just that there are some very big, but very non-obvious risks that won't bite you until later when you're already committed to the course. There may be less risky and more straightforward ways to do whatever you're doing.
I'm assuming it's an ACL problem.
A directory created with xp_cmdshell is owned by SQL Server (The service account) and its access rights are inherited from the parent.
If you have to modify the directory's content after its creation, you'll have to :
Create your directory inside another one who already have good access rights.
Or grant more rights after its creation (with xp_cmdshell and icacls to manipulate the ACLs)
Eg, change domain\group & d:\folder_path in the following snippet to whatever suits you to give a group (your users, admins, etc...) full control on a directory :
exec xp_cmdshell 'icacls "d:\folder_path" /grant "domain\group":(f)'
I want to run a program from startup by a batch file in startup folder, the file says this:
runas.exe /savecred /"user:pedro burgos" "%cd%\test.bat"
But, the problem is that when I run this and enter my password, it says Error 5: Access denied
Can anyone help me pls?
Found this in another forum.
Feel like a dumbass now, but do use caution, and get more info.
The runas command depends on the Secondary Logon service.
On my system, it is by default set to manual, and it is not activated.
AFAIK, this is a legacy feature, so that is probably the reason why it is not running.
EDIT:
It's legacy, because this command predates UAC; MS would like you to use UAC instead of runas, which is safer; you can trigger a UAC prompt by calling scripts in PowerShell with -Verb RunAs argument
Had the same issue as you on Server 2019, secondary logon service on manual. Your initial answer seemed to be the solution but it wasn't. On server 2019 the secondary logon service is on manual by default and will start automatic if you are using a run as command.
The answer was as is upgraded the server 2019 edition that the local system account didn't have the correct rights to engage with the secondary logon service.
Resolved the issue with this MS article (article is for server 2012)
Start CMD as administrator;
sc sdset seclogon D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPDTLOCRRC;;;IU)(A;;CCLCSWDTLOCRRC;;;SU)(A;;CCLCSWRPDTLOCRRC;;;AU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
try this
runas.exe /savecred /user:"pedro burgos" "%cd%\test.bat"
Make sure user "pedro burgos" actually has access to that directory. For example, one user can't just access other user's directories. You can test this theory by moving the script to something like C:\temp
I read other help posts but I keep getting file not found on the the network. The path is on the network on a fileshare and I'm using RDP to remote to my own machine that connects to the SQL Server database.
I'm using xcopy command with xp_cmdshell. I can't use just "copy" because I get an access denied error so I'm using Xcopy in this format:
echo f|xcopy /i "\\fileserver\file\excelfile1.xls" \\fileserver\file\newdirectory\excelfile1.xls"
I have tried almost everything and read other posts but this is still not working. I do have parameters for the directory and files, etc. but I actually have it hard-coded in the dos command it's still not working.
Any ideas would be great.
If you get an "access denied" with copy, you'll get the very same error with xcopy too. It offers more options, but won't let you bypass the OS security at will, both are still bound to the permissions of the user account that runs them, like every other software.
There are two options:
Use sp_xp_cmdshell_proxy_account to specify a different user for all xp_cmdshell operations (as suggested by Bacon Bits). This user must have enough permissions to both origin and target files.
Give those permissions to the account that runs the SQL Server service, so that it can access the files directly.
Thank you everyone for responding. This is the first time I've used this forum.
I found out the files were named .XLS but actually in .TXT delimited format. So I renamed them through SSIS with a ForEach Loop and processed them from there.
I tried to XCOPY from command line with new permissions that that didn't work. I was getting an extension hardening error and that is why, XLS to TXT wasn't liking it.
I am trying to run a batch file to copy a backup file from one location to other.
I keep on getting the error:
Invalid drive specification
My path is as follows:
\\server\drive:\folder\folder\folder\*.bak drive:\folder\.bak
That typically doesn't work out too well. You'll want this:
cp \\server\C$\folder\folder\folder\copy.bak C:\folder\copied.bak
This presupposes that you actually have access to the folder \\server\C$\folder\folder\folder from your box. If you do not, then you need to configure permissions correctly on the server to give you access.
You only have access to administrative shares (\\server\C$ <- the $ denotes an admin share) if you have administrative rights on the server. If you don't you need to actively share the folder in question, i.e. on the server, navigate to drive:\folder\folder\folder and share it (context menu of the folder, menu item Sharing and Security). Note that you need at least temporary admin rights on the server in order to create a share.
Do not forget to configure the permissions for the share you create, so that the limited account you are using for the copy process has read rights.
Once this is et up, you should be able to copy the files using
Copy \\Server\NewShareName\*.bak c:\folder\.bak
If you have problems with the files being in use by another process, have a look at robocopy instead of the copy command.