Difference between Win-PS and AD connector

[GauravJain]

Hi

i have gone through the documentation of both Win-PS and AD(single domain) connector but still not clear whats the difference between two and when one should use Win-PS instead of AD connector.

Can someone share some use cases which clearly explains Win-PS connector uses?

Also, is there any connector using which we can trigger VB / Power shell scripts present on any windows box with required input parameters from Saviynt objects like request, entitlement, dynamic attribute, users etc..?

Regards

Gaurav

[rushikeshvartak]

AD (Active Directory) Connector:

• Purpose: Specifically designed to connect to an Active Directory (AD) environment.
• Functions: Typically used for standard AD operations such as managing user accounts, groups, organizational units, and other AD objects. This includes creating, updating, and deleting user accounts and managing group memberships.
• Use Cases:
  • Automating the provisioning and deprovisioning of user accounts in AD.
  • Synchronizing user attributes and group memberships between Saviynt and AD.
  • Managing access rights and entitlements directly within AD.
  • Example: Automatically deactivating a user’s AD account upon termination.

Win-PS (Windows PowerShell) Connector:

• Purpose: Provides more generalized and flexible capabilities by using PowerShell scripts to perform operations on Windows systems.
• Functions: Allows execution of custom PowerShell scripts to perform a wide range of tasks, not limited to AD. This can include tasks such as file management, system administration, custom application integrations, and more.
• Use Cases:
  • Performing custom administrative tasks on Windows servers that are not limited to AD management.
  • Integrating with systems or applications that are managed via PowerShell scripts.
  • Managing local accounts and permissions on Windows servers.
  • Example: Executing a PowerShell script to configure a user’s environment settings on a Windows server during the onboarding process.

Specific Use Cases for Win-PS Connector

1. Custom Application Integration:

   • Scenario: An organization uses a custom-built application that provides PowerShell APIs for user management.
   • Implementation: Use the Win-PS connector to create scripts that interact with the application’s PowerShell APIs to manage users, roles, or other entities.

2. Advanced System Administration:

   • Scenario: Automate the setup and configuration of user environments, such as creating directories, assigning permissions, or installing software.
   • Implementation: Use the Win-PS connector to run scripts that carry out these tasks on Windows servers or workstations during user provisioning.

3. Local User Management:

   • Scenario: Manage local user accounts on Windows servers that are not part of an AD domain.
   • Implementation: Use PowerShell scripts to create, update, and delete local user accounts and manage their permissions.

Triggering Scripts from Saviynt

Saviynt does not have a direct out-of-the-box connector solely dedicated to running VB or PowerShell scripts on remote Windows machines, but you can achieve this functionality using the Win-PS connector or by leveraging custom workflows and APIs. Here’s how you can do it:

1. Using Win-PS Connector:

   • Scripts Execution: Write PowerShell scripts that accept input parameters from Saviynt objects like requests, entitlements, dynamic attributes, users, etc.
   • Connector Configuration: Configure the Win-PS connector to execute these scripts on the target Windows machine.
   • Example: A PowerShell script to create a home directory for a new user, where the directory path and user details are passed as parameters from Saviynt.

2. Custom Workflows:

   • Saviynt Workflows: Create custom workflows that include steps to trigger external scripts.
   • REST APIs: Use Saviynt’s REST API capabilities to call endpoints that trigger the execution of scripts on a remote system.
   • Example: A workflow step that makes an API call to a web service running on a Windows server, which then executes a VBScript or PowerShell script with the required parameters.

Example Workflow

1. User Request Submission: A user submits a request in Saviynt to gain access to a specific resource.
2. Workflow Trigger: The request triggers a workflow in Saviynt.
3. API Call to Windows Server: The workflow includes a step to make an API call to a custom web service running on a Windows server.
4. Script Execution: The web service executes a VBScript or PowerShell script with the parameters provided by the Saviynt request.