I'm trying to run Get-ScheduledTask remotely through Invoke-Command.
The user is a non-admin but is a part of the "Remote Management Users".
PS-Remoting works fine.
Running the command locally works fine.
But running it through Invoke-Command gets me the following error:
Cannot connect to CIM server. Access denied
+ CategoryInfo : ResourceUnavailable: (MSFT_ScheduledTask:String) [Get-ScheduledTask], CimJobException
+ FullyQualifiedErrorId : CimJob_BrokenCimSession,Get-ScheduledTask
+ PSComputerName : us-web1
Here's the code sample:
Note: this is running directly under the non-admin user in question.
$servers = "us-web1","us-web2","us-engine1","us-engine2","us-engine3","us-engine4"
foreach ( $server in $servers ) {
Invoke-Command -ComputerName "$server" -ScriptBlock {
get-scheduledtask
}
}
I was having a very similar issue with trying to use the get-printer command remotely without admin credentials.
What I found really helped was this link:
https://social.technet.microsoft.com/Forums/exchange/en-US/b748d1bb-fa97-4c30-a626-145dfbc40873/service-acccount-permission-to-remote-powershell-to-dns-server-on-windows-server-2012?forum=winserverpowershell
The process that I used for my issue was:
Open Computer Management Console. Right click WMI Control (under Services and Applications) and click property.
In the newly open Window, click on Security tab.
Expand Root tree, and then click on the node CIMV2, and click the button security
In the newly open Window, click the button Advanced.
In the newly open Window, click the button Add under the permission tab.
In the newly open Window, click on “select a principal”, then search and add the account or group you want to have access as the principal, then click ok.
In the applies to, choose “this namespace and subnamespace”.
For the permission, check on “Execute Methods”, “Enable Accounts” and “Remote Enable”
Click accept on all the open dialogue boxes
restart WMI services
attempt remotely running your command again. It will fail again, but this time you will see the real issue. Look in the error for "permission denied" then follow the same steps as above and grant access to the path shown.
Hope this helps
This could be an issue with credentials not passing through. Try adding a get-credential and adding that to your invoke-command. You can use the same creds, just try passing it directly.
Like this:
$Cred = Get-Credential
Invoke-Command -Credential $Cred -ScriptBlock {Get-ScheduledTask}
Related
Been able to do it against Microsoft.PowerShell (5.1), but today I hit a known issue on 5.1 with remote Copy-Item so I installed PowerShell 7 on the remote server (checking "Enable Remoting" in the installer) and am trying to get it working.
$securePassword = ConvertTo-SecureString -AsPlainText -Force -String $Password
$credential = New-Object -TypeName system.management.automation.pscredential -ArgumentList $Username, $securePassword
$session = New-PSSession $targetMachineHostName -Credential $credential -ConfigurationName "Microsoft.PowerShell"
Enter-PSSession $session
Above works. But if I change ConfigurationName to "PowerShell.7.1.0" I get:
[myserver.com.au] Connecting to remote server myserver.com.au failed with
| the following error message : <f:WSManFault
| xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2689860592"
| Machine="myserver.com.au"><f:Message><f:ProviderFault provider="PowerShell.7.1.0"
| path="C:\Windows\system32\PowerShell\7.1.0\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> For more information, see the about_Remote_Troubleshooting Help topic.
On the remote server I've run enable ps remoting in a 7.1 powershell so if I run Get-PSSessionConfiguration it returns a bunch of configurations, including the following:
Name : PowerShell.7.1.0
PSVersion : 7.1
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote
Management Users AccessAllowed
The dll the error refers to exists on the machine.
The user credentials I'm using are for a Local User on the remote machine that isn't an Administrator, but belongs to the Remote Management Users group.
Also worth noting from the remote machine itself (as a different Adminstrator local account, I can start a session to localhost).
After making the user an Administrator I was able to connect, but I'd gone to great lengths earlier to make non-Adminstrator possible on 5.1.
Out of interest, I tried giving the user Full Control to C:\Windows\system32\PowerShell\7.1.0 and then I could connect...
Still would love to know what's going on though and whether I'm doing the right thing or minimum permissions required.
It seems like the minimum security permissions to the folder are:
Read & Execute
List folder contents
Read
Write
Write is bizarre, but without it I get that error. I've assigned those permissions to the "Remote Management Users" group.
Docs here touch a little bit on v5.1 vs v7, and then link to here mentioning an install script so maybe something has fallen through the cracks.
I was getting the same error. I installed PowerShell 7 from Microsoft Store and then ran Enable-PSRemoting. I got this error so I uninstalled it and reinstalled it from WinGet which uses the MSI. That didn't work either. I tried running Enable-PSRemoting again, but nothing changed.
I ran Install-PowerShellRemoting.ps1 and it gave me two errors about things already existing and did not fix the problem. However, I was able to resolve the problem by doing the following:
Delete the PowerShell 7 plugins: Remove-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\PowerShell.7','HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\PowerShell.7.1.1'.
Run Install-PowerShellRemoting.ps1 again.
I'm not sure what the difference was, but deleting and allowing the script to generate it again fixed it for me.
I would like to set Edge as an Assigned Access to a User.
I'm using the following PowerShell Command:
Set-AssignedAccess -AppUserModelId Microsoft.MicrosoftEdge -UserName xy
But I always get the following error (translated from German):
System error 1376 has occurred.
The specified local group does not exist.
New-CimInstance : A general error has occurred, for which
no specific error code is available.
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\AssignedAccess\AssignedAccess.psm1:300
Zeichen:13
+ New-CimInstance -ClassName WEDL_AssignedAccess -Property ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (WEDL_AssignedAccess:CimInstance) [New-CimInstance], CimException
+ FullyQualifiedErrorId : MI RESULT 1,Microsoft.Management.Infrastructure.CimCmdlets.NewCimInstanceCommand
The local user exists, and the app exists too. I also logged in with the user I want to set the assignedaccess to make sure the profile is set u0p correctly
This happened on two different Windows 10 (build 14393) machines
I'm on PSVersion:
PS C:\WINDOWS\system32> $psversiontable.psversion.toString()
5.1.14393.1944
Does anybody know how to solve this?
Ran in to this yesterday. From what i could tell the "local group" thats referenced is actually the admin group.
I ran the following commands in an elevated powershell prompt:
Net localgroup administrators /add.
This creates a local Administrators group.
Net localgroup administratörer administrators /add.
This adds the administrators group to the local admin group (Administratörer is the Swedish localization of Administrators, use the local version depending on your country and replace it).
After this is done, run your previous commands.
Give it a try, hope it helps :)
//Chris
Set-AssignedAccess -UserName weakusername -AUMID Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge
I have a non-admin access to a server. I'm allowed to connect via RDP, and to use PowerShell remoting. When I invoke the following PowerShell command from an RDP session:
Get-WinEvent -MaxEvents 100 -Provider Microsoft-Windows-TaskScheduler
I get 100 records, as expected.
When I do the same via PowerShell remoting, by invoking the following from my local machine:
invoke-command -ComputerName myserver {Get-WinEvent -MaxEvents 100 -Provider Microsoft-Windows-TaskScheduler }
I get an error:
No events were found that match the specified selection criteria.
CategoryInfo : ObjectNotFound: (:) [Get-WinEvent], Exception
FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEventCommand
Any idea why? The remote PowerShell session should be running under identical credentials, right?
EDIT: whoami does show a difference in the security context between RDP logon and PowerShell remoting - the group set is different. In the RDP logon session, there are the following groups in the token:
BUILTIN\Remote Desktop Users
NT AUTHORITY\REMOTE INTERACTIVE LOGON
while in the remoted one, there's
CONSOLE LOGON
That could account for the discrepancy in rights...
EDIT: from the registry, it looks like the task scheduler log somehow is a part of the System log. According to MS KB article Q323076, the security descriptor for the System log can be found under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System, value CustomSD. I can't check the server in question, but on another server where I'm an admin, there's no CustomSD under that key. Under HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System\Microsoft-Windows-TaskScheduler, neither. Only the Security log gets a CustomSD. The next question is, where's the default SD?
Permissions on the actual log file at C:\Windows\System32\winevt\LogsMicrosoft-Windows-TaskScheduler%4Operational.evtx are irrelevant, the access is being mediated by the EventLog service anyway.
If you are not an administrator on the remote computer, and invoke-command -ComputerName myserver {whoami /all} tells you are who you expected to be.
You will need to be part of Event Log Reader group on the remote computer.
As well as Remote Management Users group, which I believe you already are.
If you need to read security logs, you will also need Manage auditing and security log under Local Security Policy -> Security Settings -> Local Policies -> User Rights Assignment
According to Default ACLs on Windows Event Logs # MSDN blog, in Windows Server 2003+, the default ACL for the System log goes:
O:BAG:SYD:
*(D;;0xf0007;;;AN) // (Deny) Anonymous:All Access
*(D;;0xf0007;;;BG) // (Deny) Guests:All Access
(A;;0xf0007;;;SY) // LocalSystem:Full
(A;;0x7;;;BA) // Administrators:Read,Write,Clear
(A;;0x5;;;SO) // Server Operators:Read,Clear
(A;;0x1;;;IU) // INTERACTIVE LOGON:Read <===================
(A;;0x1;;;SU) // SERVICES LOGON:Read
(A;;0x1;;;S-1-5-3) // BATCH LOGON:Read
(A;;0x2;;;LS) // LocalService:Write
(A;;0x2;;;NS) // NetworkService:Write
Does NT AUTHORITY\INTERACTIVE LOGON include RDP logon? I've found a forum message that says so, but I'd better find a doc to that effect...
The article claims this ACE comes "straight from the source code". So it's hard-coded in the service, with a chance to change via the registry.
You need local admin rights to open a powershell session.
But there is a workaround/alterative here:
https://4sysops.com/archives/powershell-remoting-without-administrator-rights/
I had the weirdest variation of this problem, was driving me nuts !
Remoting from a server W2008r2 (logged on as domain admin, inside interactive powershell session) to workstation Win7 to get logon/logoff events :
invoke-command -computername $pc {Get-WinEvent -FilterHashtable #{logname='
Security';Id=#(4624,4634)}}
-> No events were found that match the specified selection criteria.
But it does work when outputting an empty string in the scriptblock before the Get-Winevent :
invoke-command -computername $pc {"";Get-WinEvent -FilterHashtable #{lognam
e='Security';Id=#(4624,4634)}}
TimeCreated ProviderName Id Message PSComputerName
----------- ------------ -- ------- --------------
19/03/2018 11:51:41 Microsoft-Windows-Se... 4624 An account was succe... b25_x64
19/03/2018 11:51:41 Microsoft-Windows-Se... 4624 An account was succe... b25_x64
Stumbled upon this fix after trying everything: Enter-Pssession, New-Pssession, using -credential parameter to pass a predefined credential to invoke-command, to get-winevent, to both. Nothing worked, gave "No events..." in every combination.
Then I inserted a $cred inside the scriptblock to show the passed on credential for debugging, and suddenly I got the events I was looking for...
I'm using a script to create a folder on a remote server which is a filew server and a RODC.
When I run the script from a domain admin user the command complet successfuly. When I run with an account that is on the group that can administer the RODC I got an access denied.
$remotefolder = [scriptblock]::create("New-Item -Path d:\testfolder -type directory -Force ")
Invoke-Command -ComputerName server1 -ScriptBlock $remotefolder
I get this error:
[server1] Connecting to remote server server1 failed with the following error message : Access is denied.
For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (server1:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken
As it's an RODC there's no local groups that I can add my users that need to run this script.
Is anybody know how I can stop getting this accessdenied ?
Update 12/12:
I tried the same script block on a domain member server only and I don't get the access denied message, the folder is created as it should. Any toughs on how I can get this script block running on a RODC without using a Domain admin user ?
You should probably read up on PSSessionConfiguration before you do this, so you understand the implications, starting with
help about_Session_Configurations
First, create a domain group called 'RODC PowerShell Users'. Put yourself in it, wait for replication, log off and on again. Check that you're in this group.
Second, from an elevated shell on the RODC, run this:
Set-PSSessionConfiguration microsoft.powershell -ShowSecurityDescriptorUI
(After the first, time you'll probably want to use -Force but it's useful to see what it's doing.) Hit Y when asked to confirm.
After a few seconds it will display the Permissions UI for http://schemas.microsoft.com/powershell/microsoft.powershell
Click Add, enter your group name in the dialog that appears, and click OK.
In the "Permissions for RODC PowerShell Remoting Access" box, start with Read and Execute. (You may need Write or Full Control, depending on what you want to do.)
Click OK.
Then enter Y in the PowerShell window to confirm you want to restart WinRM.
From your remote box, assuming you've already set up remoting on the RODC, you should now be able to run:
Invoke-Command -ComputerName server1 { $env:computername }
OK here is my issue:
I am trying to run a script remotely on a server.
I am an administrator on both boxes, firewall exceptions are in place, remote admin is enabled, and everything else looks good that i can see.
invoke-command -ComputerName $ComputerName -ScriptBlock `
{
cd C:\Windows\System32\inetsrv\;
./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files>
}
I keep getting the following error in return
ERROR ( hresult:80070005, message:Failed to commit configuration changes. Access is denied.
The server it is trying to run on is a server 2k8 R2 box and I am thinking the issue is a UAC problem. Is there anyway to get this to run as administrator without having to click yes on a UAC box?
This piece of code will eventually become a script that will have to be completely automated.
Any help would be greatly appreciated.
OK. After some research and testing I figured out the issue. After disabling UAC and the firewall and the script still not working I dug a little deeper and discovered that the main issue was the way invoke-command runs the commands. it uses the credentials of the person running the script to authenticate to the server then tries to use another account to run the permissions or lowers the privileges of the user so that certain commands cannot be run.
I added the -Credentials switch to the invoke command and everything is working great now. Corrected code sample below:
$user = New-Object Management.Automation.PSCredential("$UserName", $securePassword)
invoke-command -ComputerName $ComputerName -Credential $user -ScriptBlock `
{
cd C:\Windows\System32\inetsrv\;
./appcmd.exe ADD vdir /app.name:<SiteName>/ /path:/<VDir Name> /physicalPath:<Path to files>
}
This seems to indicate that you need to ensure you are a local admin on the remote machine (although admittedly this is for WMI specifically). According to this you can change a registry key to stop UAC applying to remote logons for administrators (search for LocalAccountTokenFilterPolicy). That shouldn't disable UAC just not filter the token if you use powershell/WMI remotely with an administrator account.
Set the option "EnableLUA" (DWORD value) found in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 0 and reboot.
This will disable UAC without a problem, I would do it for all your users, whether with or without permission is up to you.
This trick works in Windows Vista and Windows 7 too.
Is there anyway to get this to run as administrator without having to click yes on a UAC box?
If this were possible it would entirely defeat the point of UAC.
Thus, it would appear your only real solution is to disable UAC on the box.