Scenario:
Normally, I would use remote desktop, log on to my server, launch the Powershell window as Administrator and perform the import-module and subsequent commands to get the information I'm looking for. When I log on using remote desktop, I don't log on as Administrator, but I do log on as a user that belongs to the Administrators group. (I don't have the Admin creds.)
Question:
I can easily create a session using New-PSSession. I can enter this session using Enter-PSSession. After I've entered the session, I import the module I need to use. After I import the module, I attempt to run a command from that module. I do get some output, but I also get "[Get-WmiObject], UnauthorizedAccessException". I do not get this error when I log on to the server with remote desktop and launch the powershell window as Administrator. Is there a way I can do this with a PSSession?
I met such a problem and it was due to the Forwarding of credentials in multihop environments.
Using New-PSSession you only have a network token on the second computer, you can’t directly connect to another computer.
The interactive token, I mean what you get when you sit down in front of a PC and log on (or using TS) is required to automatically connect to another computer, and to create an interactive token, the user’scredentials are needed.
To accomplish the interactive credential forwarding magic, PowerShell uses a mechanism called CredSSP (Credential Security Service Provider).
CredSSP need to be allowed on both side. You have to run these commands from an elevated PowerShell
session.
To allow CredSSP on the client side run :
Enable-WSManCredSSP -Role client -DelegateComputer computername
To allow CredSSP on the server side run :
Enable-WSManCredSSP -Role server
You've got a good explanation in Chapter 13. Remoting: configuring applications and services
Related
Is there a way to use a managed service account (msDS-GroupManagedServiceAccount) to connect to Exchange via Powershell? Our scenario is as follows:
We have a service component written in c# that connects to Exchange via Remote Powershell. The service component runs as a managed service account.
The call to New-PSSession is as follows:
New-PSSession
-Configurationname Microsoft.Exchange
-ConnectionUri "http://server/powershell"
-Authentication Kerberos
-AllowRedirection
-ErrorAction Stop
As you can see, a credential is not specified so the credential that is sent to the Exchange server is the credential of the current user (which seems to work when looking at the returned errormesage).
The result is the following error:
Processing data from remote server failed with the following error message:
[ClientAccessServer=...,BackEndServer=...,RequestId=...,TimeStamp=...]
[AuthZRequestId=6c727005-565b-4019-855f-657ae6b86ee7][FailureCategory=AuthZ-CmdletAccessDeniedException]
The operation couldn't be performed because 'domain\account$' couldn't be found.
domain\account$ shows the correct login of the managed service account.
The eventlog of the exchangeserver also states:
Source: "MSExchange RBAC", Event ID: 16):
(Process w3wp.exe, PID 8980)
"RBAC authorization returns Access Denied for user domain\account$ (SID=S-...).
Reason: User was not found on Domain Controller XYZ.
I currently suspect, that the RBAC "component" explicitly looks for objects of type 'user' in Active Directory but not for msDS-GroupManagedServiceAccount objects so I wonder if this is supported at all.
I have the same problem and found a statement by Microsoft:
"Group Managed Service Accounts (gMSA) are not supported in on-premises Exchange Server environments and thus cannot be used to perform Exchange things."
No, a Managed Service Account is local to the host you define it on. Windows 2012 introduced gMSA which can be used on multiple hosts. You may have better luck using one of them. Also, you have to grant the account the correct permissions/RBAC roles depending on the commandlets you need to run.
We have TFS 2017 in premise setup hosted on our internal network. Lets call that tfs.OurInternalDomain.com
TFS application and its build controllers and agents are all hosted on our internal n/w.
Our production servers are hosted on a separate domain (data center) for security reasons.
I am trying to deploy TFS Build artifacts [files and folders] from within our internal n/w onto our production server using TFS Release management definition.
I am able to copy the files using "Copy files from" task onto a folder on our production server (which is on a separate domain) from our internal n/w using a separate ID with $(AdminLogin) and $(Password). This userID is a local admin on the production server. TFS services are running under a separate ID on our domain.
These are the variables for task: "Copy files from"
Source=$(System.DefaultWorkingDirectory)/$(BuildDefinitionName)/$(BuildArtifactName)
Machines=$(ServerOneOnSeparateDomain)
Admin Login=$(AdminLogin)
Password=$(Password)
Destination Folder=$(BuildDropLocation)
So far so good.
Next task is to run a powershell script on the target machine and that is where the build agent on our internal n/w is not able to execute the powershell script. I used both -http and https protocol. Below is the error log when http was selected.
Executing the powershell script: D:\TFS2017Build\Agent1\tasks\PowerShellOnTargetMachines\1.0.41\PowerShellOnTargetMachines.ps1
Deployment started for machine: '<ServerOneOnSeparateDomain>.com:5985'
##[debug]Deployment logs for Deployment operation on <ServerOneOnSeparateDomain>:5985
##[debug]Permission denied while trying to connect to the target machine <ServerOneOnSeparateDomain> on the port:5985 via power shell remoting. Please check the following link for instructions: https://go.microsoft.com/fwlink/?LinkID=390236System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server <ServerOneOnSeparateDomain> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
Below is output when I execute winrm on production server:
winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Is there a way to fix this such that we do not disturb the existing TFS architecture of having the TFS Application, Build controller and agents hosted on the InternalDomain and be able to execute a powershell script on a separate domain? If not, is there any other way to fix this?
My end objective is to be able to deploy code to production via TFS that is hosted on our internal n/w.
I may provide more details if required.
According to this part error info:
##[debug]Permission denied while trying to connect to the target machine <ServerOneOnSeparateDomain> on the port:5985 via power shell remoting. Please check the following link for instructions: https://go.microsoft.com/fwlink/?LinkID=390236System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server <ServerOneOnSeparateDomain> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Permission denied The account used here must have permission to connect via power shell remoting.
To establish a PSSession or run a command on a remote computer, the user must have permission to use the session configurations on the remote computer.
By default, only members of the Administrators group on a computer have permission to use the default session configurations. Therefore, only members of the Administrators group can connect to the computer remotely.
To allow other users to connect to the local computer, give the user Execute permissions to the default session configurations on the local computer.
The following command opens a property sheet that lets you change the security descriptor of the default Microsoft.PowerShell session configuration on the local computer.
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
If that fails try adding the source to the TrustedHosts of the remote machine. You can read how here http://technet.microsoft.com/en-us/library/hh847850.aspx.
If you want to use https, you need Configure WinRM to listen on 5986.
More detail info please refer below similar issue and tutorial:
Release Management Error - Permission denied while trying to connect
to the target machine
Configuring WinRM over HTTPS to enable PowerShell remoting
Searching around the windows authentication methods and protocols, i decided to understand the exact difference between Negotiate, Kerberos, and NTLM used in a simple executable file before liking it with IIS and Web Authentication.
I reached to good results, BUT I still need more details about the Negotiate and Kerberos.
I have the following scenario :
I have created very simple C# windows forms application that shows a message box displays the value for :
System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType
Note that i'm a domain user with admin privileges on my local machine, I have the following results :
When i run the exe file (double click) while i'm actively connected to the DC, i got "Negotiate".
When i run the exe file (run as differnet user / using local user) while i'm actively connected to the DC, i got "NTLM".
When i run the exe file using "Run as Administrator", or "Run as Different User" i got "Kerberos".
When i run the exe file while i'm locally logged in using local account, i got "NTLM".
I understand that the LSA will use NTLM for local accounts. Also i understand that Active Directory uses Kerberos to authenticate domain users and computers.
My question is, why i'm getting the Negotiate Authentication Type when i run the exe using my account either by (Double Click), or "run as different user" using my Same account ?
Update : I noticed the following :
- If local user is running the exe then it is NTLM
- If domain user run the exe then it is Negotiate (If that user is local admin) but is is Kerberos (if that user is not local admin)
- If domain admin run the exe then it is Kerberos
I just a clarification about this behavior.
First off, (which you seem to understand in the question, but just to be clear) an EXE doesn't have any authentication - it is just an executable. The OS creates a process object which executes it within a logon session identified by a principal. It's this principal which has been authenticated by NTLM or Kerberos (or some other protocol).
Next, Negotiate means that when the logon session was created the Negotiate authentication package was used to decide which authentication package - Kerberos or NTLM - would be used.
When you query the WindowsIdentity.AuthenticationType value, you are ultimately calling a function in the Local Security Authority (LSA) called LsaGetLogonSessionData. This reports details of the logon session used to run the process you are executing. The way that this logon session was created probably has the largest effect on the authentication package used to verify the credentials.
When logging into Windows the first time, Winlogon.exe establishes an interactive logon by calling LsaLogonUser. It queries the authentication packages in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages in order until it finds one that can authenticate the given credentials. Once an interactive logon has been established, you can create new processes using noninteractive logons under different credentials, and in this case, the LogonUser function is likely called. One of the parameters to this function is dwLogonProvider which has the following default (which is likely the one used):
LOGON32_PROVIDER_DEFAULT
Use the standard logon provider for the system.
The default security provider is negotiate, unless you pass NULL
for the domain name and the user name is not in UPN format.
In this case, the default provider is NTLM.
So, the package reported for the logon session the process is running under depends on how the logon session was created. (It isn't clear from your question exactly how you create the logon sessions you are testing... doing "Run As" in all cases? Logoff / Logon Windows for some cases?) It also depends on which package Winlogon was able to successfully authenticate with first for the interactive logon session. Ultimately, though, note that the authentication mechanisms all call down to some authentication package, and if Negotiate is used, Kerberos is preferred, though Negotiate is what is reported.
Here is an old but still relevant diagram which shows how all the authentication fits together in Windows:
Source
In my company I used to code on one of our domain controllers (DCs) with Windows Server 2012. However since I can not do it there anymore, I am now forced to code on my workstation using my normal user account instead of my domain administrator account.
The problem I encountered now was that when I run PowerShell as administrator I can use "Set-ExecutionPolicy unrestricted", but I don't have full access to our DFS filesystem since I am not the domain administrator with this account.
When I start PowerShell as the domain administrator I can not set the execution policy since I didn't run PowerShell as administrator.
How can I run PowerShell as administrator and domain administrator?
We have a SQL server (Name: SQL) that launches an SSIS job with proxy credentials (a service account), consisting of multiple steps.
One of these steps require files to be put in a local folder on a remote machine (Name: VM) and execute a program that securely copies these files to a service on the net. I have successfully ran both PowerShell and WinRM commands to do this (as administrator), but I need to find a way to run them without being an admin on SQL.
All of these steps work fine, when the service account is a local administrator of both SQL and VM. However, we do not want the service account to be a local admin on SQL.
The command I run is:
Invoke-Command -ComputerName vm.fqdn -ScriptBlock {E:\Share\ThirdParty\FTP_Admin\FtpUpload.bat}
I found a google post suggesting I need to give access to the root/CIIV2 namespace. I gave the service account full control and restarted the WinRM service.
When it fails (NOT running as administrator), the security log gets populated with 4656 event ID's.
Any idea what I can try? Been stumped on this for a while.
Here is the link on the Microsoft technet forums:
http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/70a5a870-b911-4b1a-9c68-e7d91142e511
Long story short - ensure the server has been patched to post SP1 (Server 2008 R2) at least if you are running into these problems.
By default, only administrators have access to the (default) runspace you are connecting to:
On the vm.fqdn, try running:
set-pssessionconfiguration -Name microsoft.powershell -ShowSecurityDescriptorUI
and grant full control to the service account. Restart the WinRM service (just confirm when asked).