Announcing the SAVIYNT KNOWLEDGE EXCHANGE unifying the Saviynt forums, documentation, training, and more in a single search tool across platforms. Click HERE to read the Announcement.

Win PS Connector IIS Configuration Question

MattB
New Contributor
New Contributor

I recently built a new instance of WIN PS on Windows Server 2022 and noticed that the site is open to all users and the PowerShell is running as the AppPool user.  Any ideas on what is missing to lock the site down and to run PowerShell as specific users?

I used the following documentation to install the application: https://docs.saviyntcloud.com/bundle/WinPS-v231/page/Content/Understanding_the_Integration-between-E...

14 REPLIES 14

nimitdave
Saviynt Employee
Saviynt Employee

If you enable pass through authentication then specific user can connect and execute the PS Script. Steps below as per above document:

nimitdave_0-1679901727417.png

 

Thanks for the reply. 

I verified that the "Connect As" option is set to "Application user (pass-through authentication)" and when I test the connection, I get the following results:

  • Authentication: Pass-through Authentication is successful (running as the application pool user).  The application pool identity is valid.
  • Authorization: The specified user credentials are authorized to access the specified physical path.

timchengappa
Saviynt Employee
Saviynt Employee

Hi @MattB 

Wanted to follow up to see if there are any other open queries on this thread.

Also, below is another Forum post that has similar details about Win PS Connector IIS Configuration.
https://forums.saviynt.com/t5/identity-governance/win-ps-connector-more-questions/m-p/27913

Thanks for following up.  I'm still experiencing the issue even after I verified that the "Connect As" option is set to "Application user (pass-through authentication)." 

The problem I'm having is that any authenticated user can run a command against the WIN PS server and it executes as the App Pool account which is different that the error that the users were seeing in the post you sent.

timchengappa
Saviynt Employee
Saviynt Employee

Thanks for your response @MattB 
I am currently reviewing this and will get back as soon as I have an answer.

09
New Contributor III
New Contributor III

@timchengappa  any update on this, thanks.

timchengappa
Saviynt Employee
Saviynt Employee

Hi @09 

I have forwarded the query to our product team and awaiting their input. I will respond as soon as I an answer. Thanks

timchengappa
Saviynt Employee
Saviynt Employee

Hello @MattB @09 

Since one of the steps while deploying Saviynt App is as below, any logged-in user will be able to run scripts against the target application(provided they have the target app creds).
 
Step 11 in Win-PS connector Guide: In the Connect As window, select Application user (pass-through authentication) and click OK.
 
We will need an enhancement to restrict any logged-in user to be able to execute scripts using the App Pool account and also audit the correct account information about who executed the script.​

I have submitted EIC-I-4499 as an enhancement request. Request you vote on this idea to gain popularity and traction from our R&D team.

@Matt @09 In the interim, as recommended in the "Best Practices for Configuring PowerShell Scripts" guide, please avoid hosting any PS scripts on the Windows server. Instead, you can run the PowerShell commands directly from the request body please see the "Avoids" section of the document.
 
Also, even if you are hosting the scripts on the Windows server, please avoid storing any credentials in the scripts themselves. Instead, you can store credentials in an encrypted format on the Savint connector itself. Please see the below post for reference... 
 
 
Thank you

Hi @timchengappa,

Thanks for the update.  I'm not sure that the scope is fully understood. 

Anyone can run a powershell command on the server as the App Pool user from any endpoint by passing it in the body of the request.  For example, if the App Pool User has the correct permissions, I can issue a Restart-Computer and reboot the WIN PS Server by simply passing the command in the body of the request from a non-priviledged workstation and user.

The user that submits the request or the originating endpoint don't matter.

This is a security issue not an enhancement.

timchengappa
Saviynt Employee
Saviynt Employee

Hi @MattB 

I understand and acknowledge your concerns. This is currently being reviewed by our product team and I will give an update as soon as I have one.

Thank you.

timchengappa
Saviynt Employee
Saviynt Employee

Hello @MattB.

Below is how we are able to use a REST connector and configure IIS to use basic authentication to secure the setup and restrict any user from being able to run PS scripts directly on the Windows server...

1) Change IIS authentication configurations from anonymous/passthrough to basic authentication

2) Configure a REST connector instead of a Win-PS connector to achieve the use-case

3) In the connection JSON of the REST connector, we need to provide 2 sets of credentials

  3a) Credentials of IIS(Windows box) application: Using these creds, the REST connector will generate a token and use the token to authenticate against IIS(Windows box). Please refer to the 'properties' attribute within the sample connection JSON below. The token generated using these credentials is sore in the 'accessToken' variable which is then referenced in the createAccountJSON as "${access_token}".

  3b) Credentials of target application: This is to avoid passing the credentials of the target application such as exchange mailbox etc. in plain text within the PS scrips within the create/update account JSON attributes of the REST connector. Instead, we are able to define these parameters within the connection JSON, securely store them, and reference them in the JSONs such as create/update account JSON. Please refer to 'pass' attribute within the connection JSON which is later referenced as '${connection.pass}' in the createAccountJSON. Similarly, you can define the username of the target application as well...

Below is a sample of the connection as well as createAccountJSON...
Connection JSON

 

{
  "authentications": {
    "acctAuth": {
      "authType": "Basic",
      "url": "",
      "properties": {
        "userName": "UserName",
        "password": "XXXXXXXX"
      },
      "pass": "TargetAppPssword",
      "authError": [
        "InvalidAuthenticationToken",
        "AuthenticationFailed"
      ],
      "errorPath": "error",
      "maxRefreshTryCount": 5,
      "testConnectionParams": {
        "http": {
          "url": "https://XXXXXXXXXXXX:8088/FIMDemo/PS/ExecutePSScript",
          "httpContentType": "application/json",
          "httpMethod": "POST",
          "httpParams": "{\"script\":\"Test-NetConnection localhost\"}",
          
          "httpHeaders": {
            "Authorization": "${access_token}"
          }
        },
        "successResponses": {
          "response[0].PingSucceeded": [
            "True"
          ]
        }
      },
      "accessToken": "Basic XXXXXXXXXXXX"
    }
  }
}

 

Create Account JSON

 

{
  "accountIdPath": "accountName",
  "responseColsToPropsMap": {},
  "call": [
    {
      "name": "call1",
      "connection": "acctAuth",
      "url": "https://XXXXXXXXXXXX:8088/FIMDemo/PS/ExecutePSScript",
      "httpMethod": "POST",
      "httpParams": "{\"Script\":\"\\$pw = convertto-securestring '${connection.pass}' -asplaintext -force;\\$mycred = new-object -typename System.Management.Automation.PSCredential -argumentlist '<Target_App_Username>',\\$pw;Invoke-Command -ComputerName 'localhost' -Credential \\$mycred -ScriptBlock {C:/Scripts/CreateADUser.ps1 '${user.username}' '${user.firstname}' '${user.lastname}'}\"}",
      "httpHeaders": {
        "Authorization": "${access_token}"
      },
      "httpContentType": "application/x-www-form-urlencoded",
      "successResponses": {
        "response[0].Enabled": [
          "True"
        ]
      }
    }
  ]
}

 

Note: As for achieving the same via Win-PS connection, we are working on an improvement and the same can be tracked via the idea: EIC-I-4499.

Please let me know if you have any additional questions.

I updated the site to use Basic Authentication (and disabled Anonymous Authentication) but I'm getting a 404 error even when I pass Admin credentials.  Here's a PowerShell test I ran as an example:

PS C:\temp> Invoke-RestMethod -Uri https://xxxxxx/saviyntapp/PS/ExecutePSScript -Method Post -Body $Body -Credential $Cred -Verbose
VERBOSE: POST with -1-byte payload
Invoke-RestMethod :
404 - File or directory not found.
Server Error

404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.

At line:1 char:1
+ Invoke-RestMethod -Uri https://xxxxxxxx/saviy ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

Any thoughts?

@MattB ,

Per our quick connect, the issue was that PowerShell was not sending the Authorization (Basic XXXX) header and therefore IIS was redirecting to a URL that was not found. We confirmed there are no issues as long as the Authorization header is sent with correct credentials. 

Please let me know how it goes with your REST connector configuration. 

 

timchengappa
Saviynt Employee
Saviynt Employee

Hello @MattB 

Could you please refer to the below doc to cross-check if the basic auth was set up correctly and also cross-check the compatibility of the IIS, OS version, etc?

https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/authentication/basicau...