TSS Knowledges - Launchers, Proxy, Discovery, Dependencies, Remote Password Changing, Alerting, Recording, Check-In/Check-Out, etc - NETSEC

Latest

Learning, Sharing, Creating

Cybersecurity Memo

Saturday, June 26, 2021

TSS Knowledges - Launchers, Proxy, Discovery, Dependencies, Remote Password Changing, Alerting, Recording, Check-In/Check-Out, etc

 This post summarizes some Thycotic SS knowledges which considered as intermediate level. 



Launchers

Launcher Setup:

• Variety of options depending on needs

  • Chrome Extension
  • Web password filler
  • Protocol Handler

• Protocol Handler

  • Pings Secret Server on interval to ensure sessions is valid
  • Kills Session if check fails or callback times out

• Prompted at the first Launch


Launchers Types:

• Default Launchers

  • RDP
  • PUTTY
  • Web Password Filler/Launcher
  • Powershell
  • SQL Server
  • Sybase isql (SAP SQL Anywhere)
  • IBM z/os
  • IBM i-Series

• Custom Launchers

  • Process
  • Proxied SSH
  • Batch File

• Launchers can be configured with Secret Templates


Custom Launchers

You can configure SS with custom launchers to run arbitrary programs, which can then be recorded by session recording. To do so:

  1. Define a custom launcher:

    1. Go to Admin > Secret Templates > Configure Launchers. The Manage Launcher Types page appears.

    2. Click the New button.

    3. Leave the Launcher Type dropdown list set to Process.

    4. Type a name for the custom launcher in the Launcher Name text box.

    5. Type a process name in the Process Name text box.

    6. (optional) Type process arguments in the Process Arguments text box.

    7. Customize other Options as needed.

    8. Click the Save button.

  2. Associate the launcher with a secret template:

    1. Go to Admin > Secret Templates. The Manage Secret Templates page appears.
    2. Click the template dropdown list and select the desired template.
    3. Click the Edit button.
    4. Click the Configure Launcher button. The Secret Template Edit Launcher Configuration page appears.
    5. Click the Add New Launcher button.
    6. In the Launcher Type to use dropdown list, select your custom launcher.
    7. Customize any other options as needed.


When creating a custom launcher, a batch file on the user's machine can be used to start multiple processes using information from Secret Server.
 
Creating a custom batch launcher
 
1.  From the ADMIN menu, select Secret Templates.
2.  Click Configure Launchers, and then click +New.
3.  Select Batch File for the Launcher Type, and then type a name for the launcher.
4.  Select the batch file you would like to launch by clicking the Choose File to browse to the file location.
5.  If the batch file requires extra arguments, type them in the Process Arguments option. To reference a Secret field, type $ followed by the name of the relevant Secret field. For example, $USERNAME where Username is the name of a Secret field on the Secret template that will be used with this launcher. A corresponding % and a number can be placed in the batch file to obtain value from the Secret field in that order. An example for a batch launcher and the batch file for mapped drive could be similar to below:



 
6.  If you want the batch file to run as the credential that is on the Secret, select the Run Process As Secret Credentials check box.
7.  If the batch file requires UAC confirmation, select the Use Operating System Shell check box.
8.  Click Save.
 
Adding a custom launcher to a Secret template
 
1.  From the ADMIN menu, select Secret Templates.
2.  Select the Secret template you want to add the launcher to, and then click Edit.
3.  Click Configure Launcher (at the bottom of the page), and then click Add New Launcher.
4.  Select the name of your custom launcher, and then map Secret fields to those that will be used by the launcher. If you only see Domain, Password, and Username, map these to those same fields on the template. These will be used if you have chosen to run the launcher as the Secret credentials.
5.  Click Save.

Proxy

Proxy Benefits

• Without a Proxy

  • Session is established from client to the target
  • Credentials sent from Secret Server to the client
  • Possible to dump memory and compromise the credentials

• With a Proxy

  •  Session is established from Secret Server to the target
  • Credentials never transmitted to the client


Proxy Type

  • SSH Proxy
  • RDP Proxy
  • SSH Proxy Tunnel local RDP Session to remote server (Note recommended way since credential will be sent to client machine)

Troubleshooting Tips

  • Verify Remote Certificates are both Valid and Trusted
  • Check Firewall Ports - RDP Proxy default port is 3360, The Distributed Engine or Web Node default Port is 3389.
  • Credential on % Secret can be viewed by selecting More/Show Proxy Credentials and then choosing the Launcher
  • Verify the Latest Version of .NET framework is installed.


Discovery

Discovery finds Secrets in an IT environment and brings them into Secret Server
  • Secret Server is most effective when it covers all privileged accounts
  • Discovery helps to eliminate - Unknown Privileged Accounts, Backdoor Access and Gaps in Security
  • Auditors want automated processes to reduce human errors

Best Practice:


When to Run Discovery

Currently, you cannot set when discovery runs via a control or setting. You can, however, approximately set when it runs by disabling and enabling it at the desired time. It runs daily around the same time as when it was first enabled and then again according to whatever the discovery scan offset hours interval was set to. 


Secret Server Discovery Out-Of-Box vs Custom

Out-of-Box

  • Active Directory
  • Unix/Linux local accounts
  • Hypervisor ESXi accounts
  • Amazon Web Services
  • Google Cloud Platform

Custom (Extensible)

  • ANYTHING -Leverages PowerShell scripts
  • SQL Accounts & Database links
  • Networking equipment
  • Embedded passwords











Extensible Discovery Overview

  •  Extends Secret Server's Discovery capabilities
  •  Built-in and/or Custom Scanners
  •  Discovery Process Scans:
    •  Host Range Discovery
    •  Machine Discovery
    •  Local Account Discovery
    •  Dependency Discovery
  • Not required to use Discovery in Secret Server but needed for most environments


Why Use Extensible Discovery?

  • Discover configuration files containing passwords
  • Scan computers not joined to the domain
  • Dependencies that run a SQL, SSH, or PowerShell script
  • Bring information back to custom fields in a Secret Template
  • Discover SQL Server logins as "Local Accounts"



After discovery, you can search / filter the services for certain accounts, then import them to the right secret. You might have multiple secrets associating with one domain account. You will need to clean it up and make sure import the dependencies into the right secret. Also make sure other existing secret will not causing problems by using password change function. 


Default settings after you imported a group of dependencies into a secret. 




Remote Password Changing


Remote Password Changing Summary

Enable Globally: admin-> Remote Password Changing


  • Remote Password Changing - Yes
  • Heartbeat - Yes

Password Changers:

  • Review built-in Changers
  • Create Custom
  • Test Actions

Secret Template:



  • Configure Expiration
  • Configure Template RPC and Heartbeat Settings

Secret or Secret Policy:


  • On-Demand
  • Auto-Change
  • Auto-Change Schedule
  • Change when it is expired.


Dependency

Creating Custom Dependencies

If there are different dependency types that you want to manage that are not supported out of the box, new ones can be created based on a script. A custom dependency consists of two components:

  • Dependency Template: The dependency template defines how a dependency is matched to discovered accounts and how it updates the target after a password change occurs on the account. to create a new dependency template, go to Admin > Secret Templates and click the Dependency Templates button.
  • Dependency Changer: A dependency changer is a script and the associated parameters to be passed into the script. Dependency changers can be created and modified by going to Admin > Remote Password Changing > Configure Dependency Changers.

PowerShell, SSH, and SQL dependencies can have script arguments that derive their values from values on the dependency, the secret it belongs to, or any other secrets associated for remote password changing. Starting with Secret Server 10.0, tokens can also be used in ODBC connection string arguments. Script arguments are defined on dependency changers in Secret Server 10.0 and above and on the dependency in earlier versions of Secret Server.


Dependencies Tab for the secret

There are two actions you can execute on the dependencies. 

  • Run Dependency: This is to run the script on the selected dependency and set the password on the selected dependency to the current password for the secret
  • Test Connection: This is to test the dependency connection, the tests results are displayed afterward. You might get a API_AccessDenied error when test dependency result.

Go to admin - > configuration:
1. Make sure Enable Webservices  = Yes
2. Make sure Prevent Direct API Authentication = No


Note: Check this url for more settings information : https://docs.thycotic.com/ss/11.0.0/remote-password-changing/configuring-secret-dependencies-for-rpc/dependency-settings-and-information/index.md


Workflow


Secret Workflow Summary

Require Comment:

  • Justification that extends audit
  • Ticket Integration Optional

Request Access/Require Approval:

  • One-Step
  • Multi-Step (New IJI Only)
  • Enforces Tme and Approval
  • Ticket Integration Optional

Check-Out:

  • Enforces Sole Access
  • Enforces Tme
  • Enforces Rotation (Optional)
  • Hooks (Optional) — SSH, SQL, or PowerShell scripts that perform actions at check-out and/or check-in

Doublelock:

  • Additional Encryption
  • For your most sensitive Secrets
  • Cannot be exported or use RPC
  • Requires Doublelock Password



Event Pipelines

Overview of Event Pipelines:

  • Are created in Secret Server then assigned to
  • an Event Pipeline Policy
  • Can be in multiple EP Policies
  • Do nothing if not assigned to an EP Policy
  • Policies can target Folders or Secret Policies
  • Have no effect if it has no target (Folder or Policy)

Event Pipelines Filters:

  • Parameters that limit when an EP runs
  • Have settings and can be added to multiple times

Filter Examples:

  • Custom Variable
  • Group
  • Policy on a Secret
  • Role
  • Role Permission
  • Secret Access Role Permission
  • Secret Field
  • Secret has Field
  • Secret has RPC enabled
  • Secret Name
  • Secret Setting
  • Secret Template
  • Site

Event Pipelines Targets:

  • Folders — Secrets inside folders
    • Not recursive — only the secrets directly in the folder can trigger EP
  • Secret Policies (SP) — Secrets leveraging a specific SP

Event Pipelines Tasks:

  • Actions which are triggered in ap EP — over 30 built in
  • EP targets are NOT the receiveß of task actions — receivers are usually components of Secret Server
  • Event variable are used in EP tasks — Secret Field Tokens, Event Settings Tokens, Secret Setting Tokens, and some additional tokens
  • Example Tasks:
    • Change password remotely
    • Delete
    • Change Secret to require workflow
    • Etc.




Auditing



Introduction — Data Retention Policies
  • Automatically delete older audit and audit-like information
  • Two-data retention policies:
    • Personally Identifiable Information (PII)
    • Database Size Management
  • All records in each table older than the set max record age will be deleted from the database


Alerting and SIEM Integration

Alerting and SIEM Integration
Per Secret Alertieg
  • Set on the Secret
  • Set for the Individual User
Per User Alerting
  • Set per User
  • Set for all Secrets they have Access to
Event Subscriptions
  • Customizable alerts throughout Secret Server
  • E-Mail Notifications
SIEM Integration
  • Correlation with events outside of Secret Server


Session Recording and Connector

Record All Sessions

As of SS 10.6.26, you can configure the ASRA to record all sessions. This causes it to record video and metadata for anyone logging into the server, even when not using SS, including logging into the console. Since these recordings are not tied to any specific secret, you must go to the Admin > Session Monitoring page to view them.


Records Launched Sessions
Works with all Launchers Including
• Remote Desktop
• Putty SSH
• Microsoft SQL Management Studio
• Custom Launchers

Session Recording is Available
• From the Secret Audit
• Under Admin -> Session Monitoring

Can be Enabled
• Per Secret
• By Secret Policy


There are two options for custom launchers:
Record Multiple Windows Option

If this option is not checked, only the main window of the main launcher process will be recorded (this was always the behavior prior to Secret Server 10.8). If it is checked, multiple windows as well as child processes are recorded.

Without this enabled, the main window of the main process sometimes does not show anything useful, depending on the application, resulting in a blank recording. With this enabled, recordings are generally more accurate. This also applies to applications that can open or undock separate windows or those that launch additional processes, such as an application launching PowerShell and then launching other applications from the command prompt.

Record Additional Processes Option

Here you can type an optional comma-separated list of processes to record if found, running under your same user account, that are not started or terminated by the custom launcher. “Record Multiple Windows” must be enabled for this option to be available.

In the example above of launching PowerShell and then opening Notepad, if “Record Multiple Windows” is enabled, both PowerShell and Notepad would be recorded automatically, because the OS can tell that Notepad is a child process of PowerShell. This even works multiple levels deep—for example, launching PowerShell, then the command prompt, and then launching in PowerShell again, finally followed by Notepad.

In some cases, though, you may wish to record an additional process that was already running before the custom launcher was launched or may want to start running one later. To this end, any process names specified in this option are checked for periodically, and recording is attempted on them as well.

Example

If you wanted to run an X11 server such as Xming and then PuTTY with X11 forwarding, you could configure a custom lauchcher with these values:

Process Name: C:\Program Files\PuTTY\putty.exe Process Arguments: -X -ssh $MACHINE -l $USERNAME -pw $PASSWORD Record Additional Processes: Xming.exe

In this case, Xming should already be running before the launcher was used and would remain running after the session has ended. It would have no parent/child relationship with PuTTY at all. However, while the launcher session was active, any windows it spawns would still be recorded, allowing the X11-forwarded applications to be recorded, not only the PuTTY window.







Secret Server Session Connector Introduction
• Clientless session recording
• Launchers session through Microsoft remote desktop services (RDS)
  • Requires setup and configuration of MS RDS server
  • Requires Thycotic components installed on MS RDS Server
  • Provides an additional launcher type " Session Connector Launcher"
• No need for Connection Manager or Protocol Handler on endpoint
• Target server credentials are never sent to user's endpoint


Installing the Advanced Session-Recording Agent


The ASRA requires a 64-bit operating system with .NET Framework 4.5.1 or greater installed on the client machine. This is the version that ships with Windows 8.1 and Windows 2012 R2.

 Download the Advanced Session Recording Agent Installer

  1. Log on to Secret Server.

  2. Go to Admin > Configuration > Session Recording > Configure Advanced Session Recording.

  3. Click on an existing collection, or create a new one, as appropriate.

  4. Click the Download Session Recording Installer (64-bit) button. The installer is downloaded to your computer.


Check-in / Check-out


The Secret Server checkout feature forces accountability on secrets by granting exclusive access to a single user. If a secret is configured for check out, a user can then access it. If Change Password on Check In is turned on, after check in, Secret Server automatically forces a password change on the remote machine. No other user can access a secret while it is checked out, except unlimited administrators. This guarantees that if the remote machine is accessed using the secret, the user who had it checked out was the only one with proper credentials at that time.


Note: The exception to the exclusive access rule is unlimited administrators. If Unlimited Administration is enabled, users with Unlimited Administrator role permission can access checked out secrets.

Note: Secrets with a doublelock cannot be configured for check out.


From: https://docs.delinea.com/secrets/current/secret-checkout


Checking out Secrets

Each secret must be individually set to require check out:

  1. From the Secret View page, click the Security tab to modify a secret’s Check Out setting.

  2. You must configure RPC before Change Password on Check in can be set.

  3. Enable Require Check Out to force users to check out the secret before gaining access.

  4. Enable Change Password on Check In to have the password change after the secret is checked in.


Configuring Password Changing on Check-in

To configure password checking on check in, navigate to the Remote Password Changing Administration page and set Enable Password Changing on Check In. If RPC is turned off, enable it before configuring checkout. Once RPC and checkout are enabled, secrets can be configured for interval that specifies how long a user has exclusive secret access.

1557778261267




No comments:

Post a Comment