pasUnity PowerShell Guidance - Part 1 - Remote Usage

Written By Sean Weston

Blogs pasUNITY Integrations

This article exists as an explanation for the different configuration options by providing an example of creating a pasUnity job that will extract text contents of a file from a server on an untrusted Active Directory domain taking advantage of double hop authentication.

We begin by adding a pasUnity Powershell Script job step we will call Gather Text Contents to a newly created pasUnity job, and configure its connection details.

We uncheck Use Default Host And Runspace, this option specifies that the PowerShell connection will be made using the default connection context for the security identity under which the step is processing. No other options on this tab are applied when this setting is checked.

Now we configure the Connection URL which is a URL used to construct the connection Web Services-Management  (WSMAN) endpoint URI (either local or remote) used to establish the PowerShell runspace connection.  If left blank the default runspace connection URL for the current host is used.

Since our goal is to connect across Active Directory Domains/Workgroups we must make a decision on how to configure the runspace connection to allow authentication to untrusted Activity Directory domains or to hosts on Workgroups by defining a valid HTTPS FQDN for the destination server or by defining trusted hosts on the pasUnity client server as to allow unencrypted extra domain connections.

    Configure the destination host to use WSMAN HTTPS, and define the job steps to use that hosts HTTPS endpoint.
    Alternatively you may configure a TrustedHosts value on the pasUnity client host initiating the connection that matches the destination computer’s name.  This can be done specifically or by wild card.  Configuration examples delineated blow.
        Set a wildcard that covers all destinations
            Set-Item wsman:localhost\client\trustedhosts -Value *
        Add a specific FQDN to TrustedHosts destination
            $TrustedHosts = (Get-Item WSMan:\localhost\Client\TrustedHosts).value
            $TrustedHosts += “trustedHostExample.trustedDomain.com”
            Set-Item WSMan:\localhost\Client\TrustedHosts -value $TrustedHosts

In this example we will connect to a WSMAN on an encrypted HTTPS runspace, which is not enabled by default.
Example Value: https://pasUnity.uat.corporate.com:5986/wsman

To enable WSMAN on default HTTPS port 5986 please enable this option by following the steps delineated below:

    Add a PKI certificate to that computer’s Personal store with the Server Authentication purpose that matches that host’s fully qualified domain name (FQDN) that will be used in the runspace connection details.  Be sure that is the only cert on the host that matches this criteria.
    Configure WINRM to use that cert for https
        winrm quickconfig -transport:https
    Enable a Windows Firewall exception to allow the default WSMAN https port.  Netsh syntax provided below as an example.
        netsh advfirewall firewall add rule name="WSMAN HTTPS" dir=in action=allow protocol=TCP localport=5986           

Connection Certificate Options: When the Connection URL uses the HTTPS scheme to connect these options determine how certificates are validated.

    Skip CA Check: When checked the server certificate is not validated to ensure that it is from a trusted certificate authority (CA).  This is useful for creating a self signed cert for testing WINRM HTTPS connections, but shouldn’t be used for production.
    Skip CN Check:When checked the certificate common name (CN) does not have to match that of the server name in the connection URL.  The primary reason to choose this option is if the host is using a wildcard cert which WINRM doesn’t specifically support.
    Skip Revocation Check: When checked the certificate authority is not contacted to ensure that the certificate has not been revoked since issuance even if it is otherwise valid.  Organizations that block egress Online Certificate Status Protocol (OCSP) checks to certificate issuers may need to enable this check.

We check all three Connection Certificate Options in this example since the certificate is on the server being connected to is issued by an untrusted CA and the CA cannot be reached via OCSP.

Shell URL is where common shell endpoint URL values can be selected from the drop-down list. We accept the default for this purpose.

Next we configure Authentication Mode which indicates the means by which the client authenticates.  You have 2 choices, Credentials or Certificate.  Credentials can either mean to execute as the pasUnity Processor service’s defined service security principal, or it can be overridden with a Username and Password combination to execute as a different security principal.
The second option, Certificate, allows pasUnity to authenticate to Active Directory using a defined PKI certificate and requires additional system level steps to enable, delineated below.

    Add a valid User Authentication PKI certificate containing the private and public key to the client system’s Personal store for the user principal that will be presenting the certificate as an authentication mechanism.
    Configure WSMAN to accept that client certificate as a credential for a specific user with a specific client certificate subject issued by a specific issuer’s certificate thumbprint.

New-Item -Path WSMan:\localhost\ClientCertificate -Credential (Get-Credential) -Subject 'aUser@validdomain.com' -URI * -Issuer '1234567890qwertyuiopasdfghjklzxcvbnm1234' -Force

    Identify the Certificate Thumbprint to be used in authentication by thumbprint in the pasUnity job step.


In this article we will use Credentials option so we can leverage the Authentication Mechanism Credssp that will allow secure double hop authentication to access resources outside of the pasUnity server we are connecting to.  We will provide a standard User Name and Password combination for an authorized user in the domain of the remote host to grant us access.

 We have multiple Authentication Mechanism choices available to determine the authentication method used to connect to the connection endpoint. Most Active Directory joined hosts will default to Kerberos authentication which allows for scenarios where credentials can be securely passed from one hosts to another (a double hop), to allow for things like a web server passing credentials onto a SQL server to retrieve data permissible to the user accessing a web site.  There are scenarios where double hop authentication is useful outside of a trusted Active Directory forest, and other Authentication Mechanisms can be leveraged by pasUnity to accomplish this if additional system configuration steps are taken.

    Basic Authentication:  Allows for actual credential data to be passed from one entity to another in clear text.  Do not enable unless you are using WINRM over HTTPS otherwise the credential exchange will be clearly readable.
        Follow examples below to enable WSMAN basic authentication.

winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'


    CredSSP:  Allows for the secure passing of NTLM like credentials to other CredSSP enabled hosts, allowing double hop authentication without access to a trusted Active Directory’s Kerberos Ticket Granting Service (TGS).
    On the pasUnity Server enable WSManCredSSP
        Enable-WSManCredSSP -Role "Server"
    On the pasUnity Client enable WSManCredSSP
        Enable Connection to Single Server:

Enable-WSManCredSSP -Role "Client" -DelegateComputer "pasUnityServer.TrustedDomain.com"

        Enable Connection to servers in domain by wildcard:

Enable-WSManCredSSP -Role "Client" -DelegateComputer "*.TrustedDomain.com"

    On the pasUnity client enable the delegation of CredSSP credentials.

New-Item -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation -Name AllowFreshCredentialsWhenNTLMOnly -Force
New-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowFreshCredentialsWhenNTLMOnly -Name 1 -Value * -PropertyType String


As stated prior, we will leverage Credssp over Basic.
The User Name and Password field will be supplied with a valid user in the destination untrusted Active Directory domain and the rest of the details in the Connection tab will be left default.

Now we use the Variables tab of our first Powershell job step to define the Variable Name that we will use this Powershell job step’s Script Code to store the contents of a text file in and an Output Parameter Name we will use to pass those contents we are retrieving to the next pasUnity job step.  We will use this functionality to export the contents of the retrieved text contents to the pasUnity server’s local disk.  Both Variable Name and Output Parameter Name are named TextContents in this sample for consistency.

The Script Code for this job step is a simple one line defined below.  The Get-Content Powershell commandlet stores each row of a text file as an element of an array.  We use the join syntax to preserve the new line in the document we export in the next step.
 

$TextContents = (get-content \\fileserver.uat.corporate.com\share\SampleTextFile.txt) -join "`r`n"


We now move onto the next Powershell pasUnity job step.  Named Export Text Contents in this sample.  Connection and Variables tabs are left default.  The script code for this last job step is another simple one liner.
 

"<PARAMETER|TextContents>"  | Out-File \\fileserver.corporate.com\share \sample2.txt


Now we open sample2.txt and fine a cleanly formatted text file extracted from one environment’s file server securely and deposited on a local trusted host for whatever purpose your job logic requires.

2024-04-24 20:34:51
© 2003 - 2024 pasUNITY, Inc. | Terms Of Use | Privacy Statement