Integrations

Sigma is designed to allow hollistic control of your environment. Through various Compute, ITSM and AI integrations, Sigma allows you to centrally manage your Infrastructure.

Credential Management

Sigma provides a comprehensive credential management system for securely storing and managing authentication credentials used to access guest operating systems on virtual machines and cloud instances. This system enables automated script execution, configuration management, and in-guest operations across your infrastructure.

Note

Current Scope: Credential management is currently used for VMware guest OS operations only. Cloud providers (Azure, AWS, OCI) use service principal authentication configured at the provider level. As Sigma expands support for guest OS automation on cloud platforms, the credential system will be extended to those environments.

Overview

Credentials in Sigma are organization-scoped secrets that provide authentication for accessing guest operating systems. Unlike provider connection credentials (which authenticate to cloud APIs or vCenter), guest credentials authenticate inside virtual machines to enable automation tasks such as script execution, software installation, and configuration management.

Key Concepts:

• Organization Isolation: All credentials are scoped to your organization and cannot be accessed by other tenants

• Hierarchical Resolution: Credentials can be assigned at provider level (applies to all instances) or instance level (overrides provider defaults)

• Permission-Based Access: Role-based access control ensures only authorized users can view, modify, or access credential secrets

• Secure Storage: All credential secrets are encrypted using KMS and stored separately from metadata

• Audit Logging: All credential operations, especially secret access, are logged for compliance and security tracking

Credential Types

Sigma supports two types of credentials for guest OS authentication:

Supported Credential Types

Type	Use Case	Fields
USERNAME_PASSWORD	Windows and Linux authentication with username and password	Username, Password (encrypted)
SSH_KEY	Linux authentication with SSH private key	Username, Private Key (encrypted, PEM format)

Note

SSH Key Format: SSH private keys must be in PEM format and can be RSA, OpenSSH, EC, or DSA key types. Maximum key size is 64KB.

Permission Levels

Credential access is controlled through hierarchical permission levels. Users must have permission levels equal to or greater than the credential’s required permission to access it.

Credential Permission Hierarchy

Permission Level	Level	Description
READ	40	Basic access for viewing credential metadata (name, type, username). Cannot view secrets or use for automation.
EXECUTE	60	Can use credentials for automation tasks and script execution. Cannot view plaintext secrets directly.

Important

Security Note: Viewing plaintext secrets requires the system-level CREDENTIAL:MANAGE permission (separate from credential-level permissions). All secret access operations are audit logged for compliance tracking.

Managing Credentials in Administration

The primary interface for credential management is located in Administration → Credentials. This centralized view allows you to create, edit, rotate, and manage all credentials across your organization.

Creating a Credential:

1. Navigate to Administration → Credentials

2. Click New Credential

3. Provide the following information:

   • Name: Descriptive name for the credential (e.g., “Domain Admin - Production”)

   • Description: Optional notes about the credential’s purpose

   • Credential Type: Select USERNAME_PASSWORD or SSH_KEY

   • Username: The account username

   • Password or Private Key: The secret value (encrypted automatically)

   • Required Permission Level: Set access control (READ or EXECUTE)

4. Click Create to save the credential

Viewing Credentials:

The credentials list displays:

• Name, type, and username

• Required permission level

• Associated providers and instances

• Inline actions: View Details, Edit, Rotate Secrets, Delete

Rotating Secrets:

To rotate a credential’s password or private key:

1. Click Rotate next to the credential

2. Enter the new secret value

3. Click Rotate to update

Warning

Audit Logging: Secret rotation operations are logged. All systems using this credential will immediately use the new secret on their next authentication attempt.

Viewing Secrets:

To view plaintext secrets (requires system-level CREDENTIAL:MANAGE permission):

1. Click View Secrets on the credential details page

2. Review the security warning about audit logging

3. Click to reveal the secret values

4. Secrets are automatically cleared from clipboard after 30 seconds

Danger

Security: Viewing credential secrets is a privileged operation that is audit logged. Only users with the system-level CREDENTIAL:MANAGE permission can access plaintext secrets. Perform this action only when absolutely necessary.

Assigning Credentials at Provider Level

Credentials can be assigned at the provider level to apply as the default guest OS credentials for all instances managed by that provider. This is useful for environment-wide service accounts.

Assignment Methods:

Method 1: During Provider Setup

After successfully connecting a provider (e.g., VMware vCenter), Sigma prompts you to configure default credentials:

1. Choose Assign Existing Credential to select from already-created credentials

2. Or choose Create New Credential to define a new credential and auto-assign it

3. Or Skip for Now to configure credentials later

Method 2: From Provider Credentials Tab

1. Navigate to Compute → [Provider] (e.g., VMware)

2. Select the provider connection

3. Click the Credentials tab

4. Click Assign Credential to associate existing credentials

5. Or click Create Credential to create and assign a new credential

Method 3: From Credential Details Page

1. Go to Administration → Credentials

2. Select a credential

3. In the Associations section, click Add Providers

4. Select the providers to associate

5. Click Assign

Note

Provider-Level Scope: Credentials assigned at the provider level apply to all instances managed by that provider, unless overridden at the instance level.

Assigning Credentials at Instance Level

Instance-level credential assignments override provider-level defaults, allowing you to use different credentials for specific virtual machines or instances.

Assignment Methods:

Method 1: From Instance Details

1. Navigate to Compute → [Provider]

2. Expand an instance row to view details

3. Expand the Credentials section

4. Click Assign Credential (link icon) to select existing credentials

5. Or click Create Credential (plus icon) to create and auto-assign

Method 2: From Credential Details Page

1. Go to Administration → Credentials

2. Select a credential

3. In the Associations section, click Add Instances

4. Select the instances to associate

5. Click Assign

Viewing Instance Credentials:

The instance credentials section displays:

• Instance-specific credentials (marked with green “INSTANCE” badge)

• Provider-inherited credentials (marked with gray “PROVIDER” badge)

• Username and required permission level

• Actions: Edit, Unassign (for instance-level), View Provider (for inherited)

Tip

Visual Hierarchy: Instance-level credentials are displayed first and marked with a green “INSTANCE” badge. Provider-level credentials show a gray “PROVIDER” badge and link to the provider for management.

Credential Resolution Hierarchy

When executing automation tasks on an instance, Sigma resolves credentials using the following hierarchy:

Resolution Priority (highest to lowest):

1. Action-level override (one-time credential specified when running an action)
2. Instance-level assignment (credential directly assigned to the instance)
3. Provider-level assignment (credential assigned to the provider managing the instance)
4. No credential (action may fail if guest OS access is required)

How Resolution Works:

• Sigma first checks if an action override was specified (see next section)

• If not, Sigma queries for instance-specific assignments

• If none exist, Sigma falls back to provider-level assignments

• Within each level, credentials are sorted by permission level (EXECUTE > READ)

• The highest-permission credential is selected

Note

Flexibility: This hierarchy allows you to set organization-wide defaults at the provider level while maintaining the flexibility to override for specific instances or individual actions.

Credential Override System for Actions

When running automation actions (e.g., script execution, software installation), you can override the default credential resolution with three options:

1. Use Default Credential (Recommended)

Uses the standard resolution hierarchy (instance → provider). No action-level override is specified.

2. Use Another Credential

Select a different credential from your credential store for this specific action:

1. When configuring an action, select Use Another Credential

2. Choose from available credentials you have access to

3. The selected credential applies only to this action execution

4. Future actions revert to the default resolution hierarchy

3. Use Custom Credential (One-Time)

Provide a username and password for this action only:

1. When configuring an action, select Use Custom Credential

2. Enter a username and password

3. These credentials are never stored in the credential system

4. Used once for this action execution and discarded

Warning

Temporary Credentials: Custom credentials are ephemeral and not saved. They are suitable for one-time operations or testing scenarios. For repeated use, create a permanent credential in the Administration section.

Use Cases:

• Use Default: Normal operations using standard organizational credentials

• Use Another Credential: Elevated privileges for specific actions (e.g., domain admin for AD operations)

• Use Custom Credential: Testing, troubleshooting, or one-time operations with temporary accounts

Security and Audit Logging

Sigma implements comprehensive security controls and audit logging for credential management:

Encryption:

• All credential secrets (passwords, private keys) are encrypted using KMS (Key Management Service)

• Secrets are stored separately from metadata in an encrypted key-value store

• Encryption keys are rotated automatically by the KMS provider

Access Control:

• Permission-based access ensures only authorized users can view, modify, or access credentials

• Constant-time permission checks prevent timing-based enumeration attacks

• Failed access attempts return “Credential Not Found” (same as successful denials) to prevent credential enumeration

Audit Logging:

The following credential operations are audit logged:

Audited Operations

Event Type	Description
RESOURCE_CREATE	New credential created (includes creator, timestamp, credential type)
RESOURCE_UPDATE	Credential modified or assignments changed (includes what changed)
RESOURCE_DELETE	Credential deleted (includes secret count, cascade deletions)
SENSITIVE_DATA_ACCESS	Plaintext secret retrieved (includes user, IP address, timestamp, success/failure)

Note

Audit Retention: Audit logs are stored with hash-chain integrity for tamper detection. Logs are retained according to your organization’s compliance requirements.

Rate Limiting:

Sigma enforces API rate limits to prevent abuse:

• List/Read operations: 100 requests/minute

• Create/Update/Delete: 30 requests/minute

• Secret access (view plaintext): 10 requests/minute

• Credential resolution: 30 requests/minute

Best Practices

Security:

• Use dedicated service accounts for guest OS automation (e.g., SVC_SIGMA_OS)

• Assign the minimum required permission level to credentials (use READ for view-only access, EXECUTE for automation)

• Rotate credentials regularly (recommended: every 90-180 days)

• Use instance-level assignments sparingly; prefer provider-level defaults with exceptions only where needed

• Limit the system-level CREDENTIAL:MANAGE permission to security and operations teams who need secret access

• Enable audit logging alerts for sensitive credential access

Organization:

• Use descriptive names that indicate environment and purpose (e.g., “VMware Prod - Domain Admin”, “VMware Dev - Local Admin”)

• Add descriptions to document credential purpose, rotation schedule, and owner contact

• Tag credentials with metadata (if supported) for easier filtering and reporting

• Review unused credentials quarterly and remove them to reduce attack surface

Operational:

• Test credential changes in non-production environments first

• When rotating secrets, update the credential in Sigma before changing it in Active Directory or the guest OS

• Use provider-level credentials for consistent access across similar environments

• Use instance-level credentials only for exceptions (elevated access, isolated systems, testing)

• Document credential owners and ensure knowledge transfer during team changes

Compliance:

• Review audit logs regularly for unusual access patterns

• Implement alerting on credential secret access events

• Ensure credential rotation aligns with your organization’s password policy

• Grant system-level CREDENTIAL:MANAGE permission only to roles that require plaintext secret access

• Document credential approval workflows and change control processes

Troubleshooting

Issue	Resolution
Cannot view credential secrets	Ensure your user account has the system-level CREDENTIAL:MANAGE permission. Contact your Sigma administrator to request elevated access.
Script execution fails with authentication error	Verify the credential is assigned at the instance or provider level. Check that the username/password are correct and the account has not been locked or expired in Active Directory.
Credential not appearing in action dropdown	Ensure the credential’s required permission level is equal to or less than your user permission level. Credentials with higher permission requirements won’t appear in your list.
“Credential not found” error	This error appears for both non-existent credentials and credentials you lack permission to access (prevents enumeration). Verify the credential exists and check your permissions.
Instance-level credential not being used	Verify the credential is assigned to the specific instance (not just the provider). Check the instance’s Credentials section and confirm the green “INSTANCE” badge is present.
Provider-level credential applies to wrong instances	Provider-level credentials apply to all instances under that provider. Use instance-level assignments to override for specific VMs.
Custom credential not working for action	Ensure the username and password are correct. Custom credentials are not stored and must be re-entered for each use. For repeated use, create a permanent credential instead.
SSH key authentication failing	Verify the private key is in PEM format and matches one of the supported key types (RSA, OpenSSH, EC, DSA). Check that the public key is authorized in the target VM’s ~/.ssh/authorized_keys file.

---

Compute

Depending on your license, you can integrate Sigma with various Compute environments. Each Compute environment has unique API requirements and parameters required for a successful Simga integration.

Supported Compute environments:

• AWS (Amazon Web Services)

• OCI (Oracle Cloud Infrastructure)

• Microsoft Azure

• VMware

AWS (Amazon Web Services)

Sigma requires an API key generated from the AWS console with sufficient AWS IAM permissions to view and manage AWS resources. Below are instructions on how to set up the AWS IAM permissions.

AWS IAM Permissions

1. If you don’t already have a user account to be used for the Sigma integration, create a new AWS user account.

2. For Sigma to view and manage AWS resources, add the following AWS IAM permissions:

   - EC2:
       - DescribeInstances:      Allows Sigma to describe instances in the various regions.
       - DescribeRegions:        Allows Sigma to describe AWS regions.
       - DescribeVpcs:           Allows Sigma to describe VPCs.
       - DescribeSecurityGroups: Allows Sigma to describe security groups.
       - StartInstances:         Allows Sigma to start instances.
       - StopInstances :         Allows Sigma to stop instances.
       - RebootInstances :       Allows Sigma to reboot instances.
       - TerminateInstances :    Allows Sigma to terminate instances.
   - S3:
       - ListAllMyBuckets:       Allows Sigma to list S3 buckets.
   - CloudWatch:
       - GetMetricData:          Allows Sigma to retrieve utilization metrics.
   - Systems Manager:
       - SendCommand:            Allows Sigma to execute scripts on EC2 instances.
       - GetCommandInvocation:   Allows Sigma to get command status on EC2 instances.

   Alternatively, you may copy the below JSON to configure the required IAM policies using the AWS Policy editor:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "VisualEditor0",
               "Effect": "Allow",
               "Action": [
                   "ec2:RebootInstances",
                   "ssm:SendCommand",
                   "ec2:DescribeInstances",
                   "ec2:TerminateInstances",
                   "ec2:StartInstances",
                   "s3:ListAllMyBuckets",
                   "cloudwatch:GetMetricData",
                   "ec2:DescribeVpcs",
                   "ec2:DescribeRegions",
                   "ec2:StopInstances",
                   "ec2:DescribeSecurityGroups",
                   "ssm:GetCommandInvocation"
               ],
               "Resource": "*"
           }
       ]
   }
   

   Note

   Important: The above permissions apply to all resources. If you wish to limit the scope of resources, use the AWS console to manually select the resources that Sigma will be authorized to manage.

Creating AWS Access Key

1. Sign in to the AWS Management Console and open the IAM Console.

2. In the navigation pane, choose Users.

3. Choose the user account whose AWS IAM permissions were set up for the Sigma connection, and then choose the Security credentials tab.

4. In the Access keys section, choose Create access key. If you already have two access keys, this button is deactivated and you must delete an access key before you can create a new one.

5. On the Retrieve access keys page, choose either Show to reveal the value of your user’s secret access key, or Download .csv file. This is your only opportunity to save your secret access key. After you’ve saved your secret access key in a secure location, choose Done.

6. For the Sigma connection, you will need the AWS Access Key ID as well as the Secret Access Key.

Adding AWS Environment

1. Login to your Sigma instance.

2. In the navigation bar, click Administration > Environments.

3. Select the Compute tab (Default).

4. Select the “Click to add” button on the bottom of the Compute tab.

5. Select AWS from the Compute product dropdown.

6. Provide a Connection Name. This will be used to identify this specific AWS connection.

7. Provide the Access key ID and the Secret Access Key in the specific fields and select Connect.

8. If the connection is successful, the AWS connection will display in the environments page, as well as under the Compute > AWS tab.

OCI (Oracle Cloud Infrastructure)

Sigma requires an API key generated from the OCI console with sufficient IAM policies to view and manage OCI resources. Below are instructions on how to set up the OCI IAM policies.

OCI IAM Policies

1. If you don’t already have a user account to be used for the Sigma integration, create a new OCI user account.

2. Add the user to a group that has the below required IAM permissions:

   - manage instance-family in tenancy:                          Allows Sigma to manage instance-related resources across the tenancy.
   - use instance-family in tenancy:                             Allows Sigma to use instance-related resources within the tenancy.
   - manage instances in tenancy:                                Allows Sigma with management capabilities specifically on instances within the tenancy.
   - use instances in tenancy:                                   Allows Sigma to utilize instances within the tenancy.
   - manage virtual-network-family in tenancy:                   Allows Sigma management capabilities for virtual network resources within the tenancy.
   - use virtual-network-family in tenancy:                      Allows Sigma to use virtual network resources within the tenancy.
   - read app-catalog-listing in tenancy:                        Allows Sigma to read app catalog listings within the tenancy.
   - manage app-catalog-listing in tenancy:                      Allows Sigma to manage capabilities for app catalog listings within the tenancy.
   - manage app-catalog-listings in tenancy:                     Allows Sigma with management capabilities for app catalog listings within the tenancy.
   - use volume-family in tenancy:                               Allows Sigma to use volume-related resources within the tenancy.
   - use instance-agent in tenancy:                              Allows Sigma to use instance agent resources within the tenancy.
   - manage object-family in tenancy:                            Allows Sigma to manage object-related resources within the tenancy.
   - manage instance-agent-command-family in tenancy:            Allows Sigma with management capabilities for instance agent commands within the tenancy.
   - manage instance-agent-command-execution-family in tenancy:  Allows Sigma to manage instance agent command executions within the tenancy.
   - use instance-agent-command-execution-family in tenancy:     Allows Sigma to use instance agent command executions.
   - manage all-resources in tenancy:                            Allows Sigma management capabilities for all resources within the tenancy.
   - manage compute-capacity-reports in tenancy:                 Allows Sigma to manage compute capacity reports within the tenancy.
   - use dedicated-vm-hosts in tenancy:                          Allows Sigma to use dedicated VM hosts within the tenancy.
   - inspect instance-images in tenancy:                         Allows Sigma to inspect instance images within the tenancy.
   - manage objects in tenancy:                                  Allows Sigma management capabilities for objects (files) within the tenancy.
   - inspect marketplace-listings in tenancy:                    Allows Sigma to inspect marketplace listings within the tenancy.
   - {INSTANCE_IMAGE_READ} in tenancy:                           Allows Sigma to read image details.
   - read marketplace-listings in tenancy:                       Allows Sigma to read marketplace listings within the tenancy.
   - read marketplace-community-listings in tenancy:             Allows Sigma to read community marketplace listings within the tenancy.
   - use marketplace-listings in tenancy:                        Allows Sigma to use marketplace listings within the tenancy.
   - use marketplace-community-listings in tenancy:              Allows Sigma to use community marketplace listings within the tenancy.
   - inspect compartments in tenancy:                            Allows Sigma to inspect compartments (organizational units) within the tenancy.
   - manage repos in tenancy:                                    Allows Sigma management capabilities for repositories within the tenancy.
   - manage orm-stack in tenancy:                                Allows Sigma to manage ORM (Object-Relational Mapping) stacks within the tenancy.

   Alternatively, you may copy the below policy block to configure the required IAM policies using the OCI Policy Builder:

   Note

   Important: Please ensure to replace ‘Default’/’My Group’ with the name of your group that contains the Sigma user account, and ensure to replace ‘VMGroup’ with your dynamic group that contains the virtual machines that Sigma will manage.

   Allow group 'Default'/'My Group' to manage instance-family in tenancy
   Allow group 'Default'/'My Group' to use instance-family in tenancy
   Allow group 'Default'/'My Group' to manage instances in tenancy
   Allow group 'Default'/'My Group' to use instances in tenancy
   Allow group 'Default'/'My Group' to manage virtual-network-family in tenancy
   Allow group 'Default'/'My Group' to use virtual-network-family in tenancy
   Allow group 'Default'/'My Group' to read app-catalog-listing in tenancy
   Allow group 'Default'/'My Group' to manage app-catalog-listing in tenancy
   Allow group 'Default'/'My Group' to manage app-catalog-listings in tenancy
   Allow group 'Default'/'My Group' to use volume-family in tenancy
   Allow group 'Default'/'My Group' to use instance-agent in tenancy
   Allow group 'Default'/'My Group' to manage object-family in tenancy
   Allow group 'Default'/'My Group' to manage instance-agent-command-family in tenancy
   Allow group 'Default'/'My Group' to manage instance-agent-command-execution-family in tenancy
   Allow dynamic-group 'VMGroup' to use instance-agent-command-execution-family in tenancy where request.instance.id=target.instance.id
   Allow group 'Default'/'My Group' to manage all-resources in tenancy
   Allow group 'Default'/'My Group' to manage compute-capacity-reports in tenancy
   Allow group 'Default'/'My Group' to use dedicated-vm-hosts in tenancy
   Allow group 'Default'/'My Group' to inspect instance-images in tenancy
   Allow group 'Default'/'My Group' to manage objects in tenancy
   Allow group 'Default'/'My Group' to inspect marketplace-listings in tenancy
   Allow group 'Default'/'My Group' to {INSTANCE_IMAGE_READ} in tenancy
   Allow group 'Default'/'My Group' to read marketplace-listings in tenancy
   Allow group 'Default'/'My Group' to read marketplace-community-listings in tenancy
   Allow group 'Default'/'My Group' to use marketplace-listings in tenancy
   Allow group 'Default'/'My Group' to use marketplace-community-listings in tenancy
   Allow group 'Default'/'My Group' to inspect compartments in tenancy
   Allow group 'Default'/'My Group' to manage repos in tenancy
   Allow group 'Default'/'My Group' to manage orm-stack in tenancy
   Allow group 'Default'/'My Group' to manage orm-job in tenancy
   

Creating OCI API Key

1. Sign in to the OCI Console with the username that has the required OCI IAM Policies.

2. Click on your profile icon in the top-right corner of the console.

3. Click My Profile at the top-right corner.

4. Under Resources at the bottom-left, select API Keys and click Add API Key.

5. The Add API Key dialog is displayed. Select Generate API Key Pair to create a new key pair.

6. Click Download Private Key. A .pem file is saved to your local device. You will need this later.

7. Click Add.

8. Copy the API fingerprint of the generated key. You will need this later.

9. Copy the User OCID under User infmormation. You will need this later.

10. Click on your profile icon in the top-right corner of the console.

11. Select “Tenancy: <your_tenancy_name>” from the dropdown menu.

12. Copy the tenancy OCID under Tenancy infmormation. You will need this later.

Adding OCI Environment

1. Login to your Sigma instance.

2. In the navigation bar, click Administration > Environments.

3. Select the Compute tab (Default).

4. Select the “Click to add” button on the bottom of the Compute tab.

5. Select OCI from the Compute product dropdown.

6. Provide a Connection Name. This will be used to identify this specific OCI connection.

7. Provide the Tenancy ID, Region (example: Ashburn), User Id and the API Fingerprint in the specific fields.

8. Click inside the PEM File Upload zone, and upload the previously saved .pem file, then select Connect.

9. If the connection is successful, the OCI connection will display in the environments page, as well as under the Compute > OCI tab.

Microsoft Azure

Sigma provides comprehensive integration with Microsoft Azure, enabling centralized management of compute resources, virtual desktops, custom image creation, and automated operations across your Azure environment.

Azure Services Supported

Sigma integrates with the following Azure services:

- Azure Compute (Virtual Machines): Full VM lifecycle management, power operations, script execution, metrics monitoring, and tagging
- Azure Virtual Desktop (AVD): Host pool management, session host monitoring, user session tracking, application groups, workspaces, and FSLogix profile management
- Azure Image Builder: Custom image creation with PowerShell/Shell customizers, Windows Update integration, and build monitoring
- Azure Blob Storage: Automatic script storage for large automation scripts (>200KB)
- Azure Monitor: Historical metrics (CPU, network, disk, memory), health checks, and performance monitoring
- Azure File Share: FSLogix profile storage and quota tracking for AVD environments

Prerequisites

Before connecting Sigma to Azure, ensure you have:

• An Azure subscription with appropriate permissions

• Access to create applications in Microsoft Entra ID (formerly Azure Active Directory)

• Appropriate role assignments at the subscription or resource group level

Registering Azure Application

1. Log in to the Microsoft Entra Admin Center.

2. Under Application, select App registrations.

3. Click on New registration.

4. Enter a name for the application (e.g., “Sigma Integration”).

5. Select the Accounts in this organizational directory only option.

6. Click Register.

7. After registering the application, navigate to Certificates & secrets.

8. Click on New client secret.

9. Add a description and select an expiry period.

10. Click Add.

11. Copy the Value of the client secret. You will need this later.

12. Under Overview, copy the application ID. You will need this later.

Required Azure Permissions

Sigma requires specific Azure role assignments to manage resources across your subscription. The permissions vary based on which Azure services you want to integrate.

Minimum Permissions (Basic Integration)

For basic Azure VM management, assign the following built-in roles:

- Virtual Machine Contributor: Manage virtual machines (power operations, configuration, deletion)
- Monitoring Reader: Read metrics and health data from Azure Monitor

Extended Permissions (Full Integration)

For complete functionality including AVD, Image Builder, and storage operations, assign these additional roles:

- Desktop Virtualization Contributor: Manage AVD host pools, session hosts, application groups, and workspaces
- Storage Blob Data Contributor: Upload/download scripts to blob storage (required for scripts >200KB)
- Storage File Data SMB Share Contributor: Read FSLogix profile data from Azure File Shares (required for AVD profile management)
- Reader: List resources, resource groups, and subscriptions

Note

Custom Role Alternative: If your organization requires tighter permission scoping, you can create a custom role that combines only the specific actions Sigma needs. See the Azure custom roles documentation for details.

Assigning Permissions

1. Log in to the Microsoft Azure portal.

2. Select the Subscriptions service.

3. Select the subscription you wish to grant Sigma access.

4. Click on Access control (IAM).

5. Click Add > Add role assignment.

6. Select the roles listed above based on your integration needs.

7. Click Next then under Assign access to, select User, group, or service principal.

8. Under Select, search for your application by name and select it.

9. Click Review + assign.

10. Repeat steps 5-9 for each required role.

11. Go back to the Microsoft Azure portal homepage.

12. Select the Tenant Properties service.

13. Copy the Tenant ID. You will need this later.

Adding Azure Environment

1. Login to your Sigma instance.

2. In the navigation bar, click Administration > Environments.

3. Select the Compute tab (Default).

4. Select the “Click to add” button on the bottom of the Compute tab.

5. Select Azure from the Compute product dropdown.

6. Provide a Connection Name. This will be used to identify this specific Azure connection.

7. Provide the Tenant ID, Application ID and the Secret Access Key in the specific fields and select Connect.

8. If the connection is successful, the Azure connection will display in the environments page, as well as under the Compute > Azure tab.

Managed Identity for Image Builder

Azure Image Builder requires a user-assigned managed identity with specific permissions to create and publish images. This identity is separate from the application registration used for Sigma’s general Azure access.

1. Log in to the Microsoft Azure portal.

2. Search for Managed Identities and select the service.

3. Click Create to create a new user-assigned managed identity.

4. Select the Subscription and Resource Group where the identity will reside.

5. Enter a Name for the identity (e.g., “sigma-image-builder”).

6. Click Review + create, then Create.

After creating the managed identity, assign the following permissions at the subscription or resource group level:

Required Permissions:

Gallery Operations:
- Microsoft.Compute/galleries/read
- Microsoft.Compute/galleries/images/read
- Microsoft.Compute/galleries/images/versions/read
- Microsoft.Compute/galleries/images/versions/write

Image Operations:
- Microsoft.Compute/images/read
- Microsoft.Compute/images/write
- Microsoft.Compute/images/delete

Note

For script execution during image builds, the managed identity also needs the Storage Blob Data Reader role on the storage account configured in Administration > Storage.

You can create a custom role with these permissions using the following JSON definition:

{
  "Name": "Sigma Image Builder",
  "Description": "Custom role for Sigma Image Builder Azure Image Builder operations",
  "Actions": [
    "Microsoft.Compute/galleries/read",
    "Microsoft.Compute/galleries/images/read",
    "Microsoft.Compute/galleries/images/versions/read",
    "Microsoft.Compute/galleries/images/versions/write",
    "Microsoft.Compute/images/read",
    "Microsoft.Compute/images/write",
    "Microsoft.Compute/images/delete"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<your-subscription-id>"
  ]
}

To create this role using Azure CLI:

az role definition create --role-definition sigma-image-builder-role.json

Then assign it to your managed identity:

az role assignment create \
  --assignee <managed-identity-principal-id> \
  --role "Sigma Image Builder" \
  --scope /subscriptions/<your-subscription-id>

For more details on Azure Image Builder permissions, see the Microsoft documentation.

Azure Compute (Virtual Machines)

Sigma provides comprehensive management capabilities for Azure Virtual Machines, including power operations, script execution, metrics monitoring, and resource tagging.

Supported Operations

• Power Management: Start, stop, restart, and delete virtual machines

• Script Execution: Execute PowerShell scripts (Windows) or shell scripts (Linux) directly on VMs

• Metrics Monitoring: Retrieve historical performance metrics (CPU, memory, network, disk I/O)

• Guest OS Monitoring: Query running processes and real-time utilization data

• Resource Tagging: Get and set Azure tags for resource organization

• Configuration Retrieval: View VM specifications (memory, CPU, disk capacity, IP addresses)

Script Execution

Sigma supports two execution strategies for running scripts on Azure VMs:

1. Inline Execution (scripts ≤200KB): Scripts are executed directly via the Azure Run Command API

2. Blob Storage Execution (scripts >200KB): Large scripts are automatically uploaded to Azure Blob Storage, downloaded by the VM, and executed

Note

OS Compatibility: Sigma automatically validates script types against VM operating systems. PowerShell scripts require Windows VMs, while shell scripts require Linux VMs.

Windows Encoding Support

For Windows VMs, Sigma includes automatic encoding fallback:

• Primary encoding: UTF-8

• Fallback encoding: CP1252 (Windows-1252) for legacy systems

Script Execution Phases

When executing scripts, Sigma reports progress through distinct phases:

1. CONNECTING: Establishing connection to Azure VM
2. UPLOADING: Uploading script to blob storage (large scripts only)
3. EXECUTING: Running script via Azure Run Command
4. PROCESSING: Collecting output and error streams

Metrics and Monitoring

Available metrics via Azure Monitor:

Azure Monitor Metrics

Metric	Description	Aggregation
CPU Percentage	Percentage of CPU utilization	Average, Min, Max
Network In/Out	Bytes transferred over network interfaces	Total, Average
Disk Read/Write Bytes	Disk I/O operations	Total, Average
Available Memory	Free memory in bytes (requires Azure Monitor Agent)	Average, Min, Max

Note

Memory metrics require the Azure Monitor Agent to be installed on the VM. Without the agent, memory metrics will be unavailable.

Health Checks

Sigma integrates with Azure Resource Health to track service health events:

• Filters for active health events (ignores resolved incidents)

• Maps severity levels to status indicators (Critical/Error → ERROR, Warning → WARNING)

• Provides detailed failure reasons and recommended actions

• Gracefully handles unavailable metrics (e.g., deallocated VMs)

Azure Virtual Desktop (AVD)

Sigma provides comprehensive management and monitoring for Azure Virtual Desktop environments, including host pools, session hosts, user sessions, application groups, and FSLogix profile storage.

AVD Resources Managed by Sigma

AVD Resource Types

Resource Type	Description	Operations
Host Pools	Multi-session or personal desktop environments	List, Get Details
Session Hosts	Individual VMs within a host pool	List, Get Details, Health Status, Tagging
User Sessions	Active user connections to session hosts	List, Get Details, Track State
Application Groups	Collections of published applications	List, Get Details
Workspaces	User-facing abstractions of application groups	List, Get Details
Applications	Individual apps within application groups	List, Get Details
FSLogix Profiles	User profile containers in Azure File Shares	List, Calculate Storage, Track Quotas

Session Host Health Status

Sigma tracks session host health with the following states:

- Available: Session host is online and accepting connections
- Unavailable: Session host is offline or unreachable
- Disconnected: Session host lost connection to AVD control plane
- NeedsAssistance: Session host requires manual intervention
- Shutdown: Session host is powered off
- Upgrading: Session host is being upgraded
- NoHeartbeat: Session host hasn't reported status recently
- DomainTrustRelationshipLost: VM lost trust with domain controller

User Session States

User sessions are tracked with the following states:

- Active: User is actively connected and using the session
- Disconnected: User session is disconnected but preserved
- Pending: Session is being established
- LogOff: User is logging off
- UserProfileDiskMounted: FSLogix profile disk is mounted

Session Host Tagging

Session hosts support Azure resource tagging through their underlying VM:

• Tags applied to session hosts are synchronized with the backing Azure VM

• Tags can be used for resource organization, cost tracking, and automation

• Sigma automatically retrieves tags when listing or getting session host details

FSLogix Profile Management

Sigma provides comprehensive FSLogix profile management for Azure Virtual Desktop environments, including storage tracking, quota management, and profile organization.

FSLogix Profile Storage

FSLogix profiles are stored in Azure File Shares and accessed via SMB. Sigma integrates with Azure Storage to:

• Calculate per-user profile storage consumption

• Track profile quotas (default: 30 GiB per user, configurable)

• Generate deep links to Azure Storage Explorer for profile management

• Parse profile naming patterns (supports SID_Username, Username_SID, Username, SID-only)

Profile Naming Patterns

Sigma supports multiple FSLogix profile naming conventions:

- SID_Username: S-1-5-21-..._jdoe (Active Directory SID with username)
- Username_SID: jdoe_S-1-5-21-... (Username with SID)
- Username: jdoe (Username only)
- SID: S-1-5-21-... (SID only)

Note

Sigma uses regex-based Windows SID validation to accurately parse profile directories regardless of naming convention.

Profile Quota Management

Profile Quota Configuration

Setting	Description	Default
Profile Size Limit	Maximum storage per user profile	30 GiB
Quota Warning Threshold	Percentage of quota to trigger warning	80%
Quota Calculation Method	Recursive directory size calculation	Real-time

Storage Performance Metrics

Sigma tracks Azure File Share performance characteristics:

File Share Performance Tiers

Tier	IOPS Characteristics	Throughput
Standard	Baseline IOPS based on capacity	Up to 60 MiB/s per share
Premium	Provisioned IOPS (1 IOPS per GiB)	Up to 10,000 MiB/s per share

Note

Performance metrics are calculated based on the Azure File Share tier and capacity. Actual performance may vary based on workload patterns.

Azure Image Builder Integration

Sigma leverages Azure Image Builder to create custom Windows and Linux images with automated customization, configuration management, and build monitoring.

Image Customization Types

Sigma supports four types of image customizers:

Image Customizer Types

Customizer Type	Description	Supported OS
PowerShell	Execute PowerShell scripts with optional elevation	Windows
Shell Script	Execute shell scripts	Linux
File	Download and place files on the image	Windows, Linux
Windows Update	Install Windows updates with security filtering	Windows

PowerShell Customizer

Execute PowerShell scripts during image build:

• Supports inline scripts or script URIs (blob storage)

• Optional elevated execution (Run As Administrator)

• Automatic script validation and encoding handling

• Output and error stream collection

Shell Script Customizer

Execute shell scripts on Linux images:

• Supports inline scripts or script URIs

• SHA256 checksum validation for script integrity

• Standard output/error collection

• Compatible with all Linux distributions

File Customizer

Download files from URIs and place them on the image:

{
  "type": "File",
  "name": "Download Config File",
  "sourceUri": "https://storage.blob.core.windows.net/files/config.json",
  "destination": "C:\\ProgramData\\MyApp\\config.json",
  "sha256Checksum": "abc123..."
}

Forbidden File Destinations

Sigma enforces security restrictions on file destinations to prevent system compromise:

Windows Forbidden Paths:
- C:\Windows\* (system directory)
- C:\Program Files\* (program files)
- C:\Program Files (x86)\* (32-bit program files)
- Reserved device names (CON, PRN, AUX, NUL, COM1-9, LPT1-9)

Linux Forbidden Paths:
- /etc/* (system configuration)
- /root/* (root home directory)
- /boot/* (boot files)
- /sys/* (system files)
- /proc/* (process files)

Windows Update Customizer

Install Windows updates with granular filtering:

{
  "type": "WindowsUpdate",
  "searchCriteria": "IsInstalled=0",
  "filters": [
    "exclude:$_.Title -like '*Preview*'",
    "$_.MsrcSeverity -in @('Critical', 'Important')"
  ],
  "updateLimit": 100
}

Allowed Filter Criteria (Security Allowlist):

- MsrcSeverity: Filter by Microsoft Security Response Center severity (Critical, Important, Moderate, Low)
- Classification: Filter by update classification (Security Updates, Critical Updates, etc.)
- Title: Basic string matching (no complex regex or execution)

Warning

Sigma enforces a strict allowlist for Windows Update filters to prevent code injection. Only MSRC severity and classification metadata filtering is permitted.

Image Build Workflow

1. Template Creation: Define image source, customizers, and distribution targets

2. Configuration Drift Detection: Verify template matches desired state

3. Build Start: Submit build request to Azure Image Builder

4. Progress Monitoring: Poll build status every 5 minutes with Socket.IO updates

5. Checkpoint Persistence: Save build state every 5 minutes for crash recovery

6. Completion: Image published to Azure Compute Gallery or Managed Image

Build Timeouts and Recovery

Build Configuration

Setting	Description	Default
Build Timeout	Maximum build duration before cancellation	4 hours
Poll Interval	Frequency of build status checks	5 minutes
Checkpoint Interval	Frequency of recovery checkpoint saves	5 minutes
Socket.IO Throttle	Rate limit for frontend progress updates	Every 5 minutes

Crash Recovery

Sigma implements checkpoint-based recovery for long-running image builds:

• Checkpoints saved every 5 minutes with build state (template ID, status, start time)

• On service restart, Sigma automatically resumes polling for in-progress builds

• Build cancellation supported via Azure Image Builder API

• Failed builds provide detailed error messages from Azure

Configuration Drift Detection

Before starting a build, Sigma compares the existing template against the desired configuration:

• Source Image: Platform image (Marketplace) or custom image

• Customizers: Ordered list of customization steps

• Distribution Targets: Azure Compute Gallery destinations

If drift is detected, Sigma updates the template before starting the build to ensure consistency.

Storage Configuration

Sigma uses Azure Blob Storage for script execution and FSLogix profile management. Storage configuration occurs at two levels:

Organization-Level Storage (Script Execution)

Configure in Administration > Storage:

• Storage Account: Azure storage account for script uploads

• Container Name: Blob container for storing scripts (auto-created)

• Access Method: Service principal with Storage Blob Data Contributor role

Note

Scripts ≤200KB execute inline via Run Command. Scripts >200KB are automatically uploaded to blob storage, downloaded by the VM, and executed.

Provider-Level Storage (FSLogix Profiles)

Configure in Environment Settings for each Azure provider:

• FSLogix Storage Account: Storage account containing AVD profile file shares

• FSLogix Share Name: Azure File Share name for profile storage

• Access Method: Storage Account Key or service principal with Storage File Data SMB Share Contributor

Storage Account Key Caching

Sigma caches Azure Storage Account keys for performance:

• Cache duration: 1 hour (Redis)

• Automatic regeneration on cache expiration

• Secure key retrieval via Azure Management API

SAS URL Generation

For script uploads and downloads, Sigma generates pre-signed SAS URLs:

• Default expiration: 60 minutes

• Configurable via SAS_URL_EXPIRY_MINUTES environment variable

• Read-only default permissions (writable for script output collection)

Monitoring and Health

Sigma provides comprehensive monitoring and health tracking for Azure resources using Azure Monitor and Azure Resource Health.

Available Metrics

Azure Monitor Metrics

Metric Name	Description	Azure Metric ID	Unit
CPU Percentage	Percentage of allocated CPU in use	Percentage CPU	Percent
Network In	Bytes received by the VM	Network In Total	Bytes
Network Out	Bytes sent by the VM	Network Out Total	Bytes
Disk Read Bytes	Bytes read from disk	Disk Read Bytes	Bytes
Disk Write Bytes	Bytes written to disk	Disk Write Bytes	Bytes
Available Memory	Free memory (requires Azure Monitor Agent)	Available Memory Bytes	Bytes

Metric Query Configuration

Sigma supports flexible metric queries:

• Time Range: ISO 8601 format (e.g., PT1H for last hour, P1D for last day)

• Interval: 5-minute, hourly, daily granularity

• Aggregation: Average, Minimum, Maximum, Total, Count

• Default Metrics: Pre-configured set for quick VM utilization queries

Health Check Integration

Sigma integrates with Azure Resource Health to provide service health monitoring:

Health Event Types

Event Type	Description	Status Mapping
Platform-Initiated	Azure infrastructure maintenance or issues	Maps to ERROR/WARNING
User-Initiated	Changes caused by user actions	Informational
Resolved	Previously active events now resolved	Filtered out (not shown)

Service Dependency Filtering

Sigma filters health events to show only relevant services:

- COMPUTE: Azure Virtual Machines
- VDESKTOP: Azure Virtual Desktop

Unrelated service health events (e.g., Azure SQL, App Service) are excluded to reduce noise.

Graceful Degradation

Sigma handles metric unavailability gracefully:

• Deallocated VMs: Metrics unavailable, status shown as “stopped”

• Missing Azure Monitor Agent: Memory metrics unavailable, other metrics still collected

• API rate limiting: Automatic retry with exponential backoff

• Timeout handling: 15-second default timeout for health checks

Troubleshooting

Authentication Errors

If you encounter authentication failures:

1. Verify the Tenant ID matches your Microsoft Entra ID tenant

2. Confirm the Application ID is correct from App Registration

3. Check the Client Secret hasn’t expired (secrets expire based on configuration)

4. Ensure the service principal has been granted the required role assignments

Permission Errors (HTTP 403)

If Sigma cannot access resources:

1. Verify role assignments are at the subscription or resource group level

2. Confirm the service principal is assigned to the correct subscription

3. Check that role assignments have propagated (can take 5-10 minutes)

4. Use Azure CLI to validate: az role assignment list --assignee <application-id>

Script Execution Failures

If scripts fail to execute:

1. Verify the OS matches the script type (PowerShell for Windows, Shell for Linux)

2. Check the VM has the Azure VM Agent installed and running

3. Confirm blob storage is configured for scripts >200KB

4. Review script output in Sigma for detailed error messages

5. Ensure the VM can reach Azure services (check NSG rules, firewall)

Image Builder Errors

If image builds fail:

1. Verify the managed identity has required permissions

2. Confirm the source image exists and is accessible

3. Check customizer scripts are valid and accessible (blob storage)

4. Review build logs in Azure Image Builder for detailed errors

5. Ensure the virtual network (if specified) allows outbound connectivity

FSLogix Profile Issues

If FSLogix profiles aren’t detected:

1. Verify FSLogix Storage Account and Share Name are configured in provider settings

2. Confirm the service principal has Storage File Data SMB Share Contributor role

3. Check the Azure File Share exists and contains profile directories

4. Validate profile naming convention matches supported patterns (SID_Username, etc.)

Metrics Unavailable

If metrics aren’t showing:

1. Confirm the VM is powered on (metrics unavailable for stopped VMs)

2. Verify Monitoring Reader role is assigned to the service principal

3. For memory metrics, install the Azure Monitor Agent on the VM

4. Check time range isn’t too far in the past (Azure retains metrics for 93 days)

Best Practices

Security

• Rotate client secrets regularly (recommended: every 6-12 months)

• Use resource group-scoped role assignments instead of subscription-wide when possible

• Enable Azure AD Conditional Access for service principal authentication

• Store client secrets in Azure Key Vault instead of plaintext configuration

• Review audit logs regularly for unusual service principal activity

Performance

• Configure active regions in provider settings to limit resource enumeration overhead

• Use active resource groups filter to scope Sigma to specific workloads

• Enable blob storage for large script execution (>200KB)

• Leverage cached storage account keys for faster file operations (1-hour TTL)

• Set appropriate metric intervals (shorter intervals = more data points = higher cost)

Cost Optimization

• Use Standard File Shares for FSLogix profiles unless high IOPS required

• Configure lifecycle management on blob storage to delete old scripts

• Limit metric queries to necessary time ranges and intervals

• Use Azure Hybrid Benefit for Windows AVD session hosts

• Implement auto-shutdown schedules for non-production session hosts

Reliability

• Configure checkpoint-based recovery for long-running image builds (default: enabled)

• Set appropriate build timeouts based on image complexity (default: 4 hours)

• Use configuration drift detection to ensure templates match desired state

• Enable Socket.IO updates for real-time build progress monitoring

• Implement health checks to detect session host failures early

FSLogix Profile Management

• Set appropriate profile quotas (default: 30 GiB, adjust based on workload)

• Enable profile container compaction to reclaim unused space

• Use Premium File Shares for large AVD deployments (>500 users)

• Implement Azure Backup for profile containers

• Monitor profile growth trends to prevent quota exhaustion

VMware

Sigma Automate can connect directly to VMware environments using either a vCenter Server or an individual ESXi host. This integration provides full visibility and lifecycle control over virtual machines, clusters, datastores, and compute resources — while maintaining a strict separation between infrastructure-level access (vCenter/ESXi) and in-guest OS-level access (for configuration, script execution, and orchestration).

Connection Overview

When integrating Sigma with VMware, you must configure two separate accounts, each serving a distinct purpose:

Credential Types

Credential Type	Used For	Authenticates Against	Example	Description
Infrastructure Integration Account	VM lifecycle, provisioning, snapshot, and datastore control	vCenter Server or ESXi API	sigma@vsphere.local	Grants Sigma permission to manage VMware resources via the vSphere API layer.
OS-Level Service Account	In-guest script execution, configuration, and orchestration	Active Directory Domain (guest OS)	SVC_SIGMA_OS	Provides Sigma secure access inside virtual machines to perform automation tasks.

Important

These accounts are completely separate. The Infrastructure Integration Account connects Sigma to the VMware API, while the OS-Level Service Account operates inside guest VMs. Do not reuse or share credentials between these two layers.

Prerequisites

Before connecting:

• Ensure network connectivity between Sigma and your vCenter Server or ESXi host (port 443/TCP).

• Verify the VMware API account has the required privileges (see section below).

• Create a dedicated Active Directory service account for OS-level automation within guest systems.

VMware Infrastructure Account (vCenter)

If you don’t already have a dedicated VMware account for Sigma integration, create one (for example, sigma@vsphere.local) and assign the following permissions.

Create the Custom Role

1. Open the vSphere Client and connect to your vCenter Server.

2. Click Menu → Administration → Access Control → Roles.

3. Select Add to create a new role, name it Sigma_Automate_VM_Integration, and keep the dialog open while you configure the permissions below.

Required Permission Categories

- Datastore (Allows Sigma to allocate storage and access ISO files)
    - Allocate space
    - Browse datastore
- Global (Allows Sigma to view vSphere objects and manage tags)
    - Diagnostics
    - Global tag
    - Manage custom attributes
    - Set custom attribute
- Cryptographic operations (Required for VMs with TPM enabled)
    - Direct Access
- vSphere Tagging (Allows Sigma to manage vSphere tags and categories)
    - Assign or Unassign vSphere Tag
    - Assign or Unassign vSphere Tag on Object
    - Create vSphere Tag
    - Create vSphere Tag Category
    - Delete vSphere Tag
    - Delete vSphere Tag Category
    - Edit vSphere Tag
    - Edit vSphere Tag Category
- Network (Allows Sigma to assign virtual network adapters)
    - Assign network
- Resource (Allows Sigma to assign VMs to resource pools)
    - Assign virtual machine to resource pool
- Storage views (Allows Sigma to view storage information)
    - View
- Virtual machine (Allows Sigma to manage virtual machines)
    - Change Configuration (Modify VM hardware)
        - Add existing disk
        - Add new disk
        - Add or remove device
        - Change CPU count
        - Change Memory
        - Change settings
        - Change resource
        - Extend virtual disk
        - Remove disk
        - Rename
        - Set annotation
    - Edit Inventory (Create, clone and remove VMs)
        - Create new
        - Create from existing
        - Remove
    - Guest operations (Execute commands inside VMs)
        - Guest operation alias modification
        - Guest operation alias query
        - Guest operation modifications
        - Guest operation program execution
        - Guest operation queries
    - Interaction (Control VM power state, access console, remote connect recording)
        - Console interaction
        - Inject USB HID scan codes
        - Install VMware Tools
        - Power on
        - Power off
        - Reset
    - Provisioning (Deploy and manage VM templates)
        - Customize guest
        - Deploy template
        - Read customization specifications

Required Scope: The role must be assigned at the Datacenter level with “Propagate to children” enabled. This ensures permissions apply to all child objects (folders, VMs, hosts) within the datacenter and is required for proper operation.

Recommended Role Name: Sigma_Automate_VM_Integration

Example Permission Path: vCenter → Datacenter → Permissions → Add → sigma@vsphere.local → Role: Sigma_Automate_VM_Integration (with "Propagate to children" enabled)

Restricting Permissions to Specific VMs or Folders

For environments requiring tighter access control, permissions can be scoped to specific folders or individual VMs rather than the entire datacenter. This limits Sigma’s visibility and management to only the designated objects.

To assign a role to a folder:

1. In the vSphere Client, navigate to the VMs and Templates inventory view.

2. Right-click the target folder and select Add Permission.

3. Click Add to select the Sigma service account (e.g., sigma@vsphere.local).

4. From the Role dropdown, select Sigma_Automate_VM_Integration.

5. Check Propagate to children to apply the role to all VMs within the folder.

6. Click OK to save.

To assign a role to a single VM:

1. In the vSphere Client, navigate to the target VM.

2. Right-click the VM and select Add Permission.

3. Click Add to select the Sigma service account.

4. From the Role dropdown, select Sigma_Automate_VM_Integration.

5. Leave Propagate to children unchecked (VMs have no children).

6. Click OK to save.

Note

When scoping permissions below the datacenter level, ensure Sigma has at least read-only access at the datacenter level to discover inventory structure. Without this, Sigma may not be able to locate the restricted VMs or folders.

Important

A Second Account is Required for In-Guest Operations

The VMware Infrastructure Account (above) only manages VM infrastructure (power, hardware, creation/deletion). To execute scripts and perform automation inside the guest operating systems, Sigma requires a separate domain service account with administrative privileges within the VMs themselves. This separation ensures proper security boundaries between infrastructure management and guest OS operations.

OS-Level Service Account (Active Directory)

Sigma requires a domain-based service account for in-guest automation and configuration tasks. This account enables Sigma to perform PowerShell or SSH operations inside virtual machines via VMware Tools Guest Operations.

Recommended Account Name: SVC_SIGMA_OS

Create the account in Active Directory Users and Computers (ADUC) under your organization’s Service Accounts OU.

Required Account Configuration:

• Domain Account: Create SVC_SIGMA_OS as a standard domain user

• Password Policy: Strong password (≥20 characters), rotated every 90–180 days per IT policy

• Group Membership: Add to a domain group (e.g., GG_Sigma_OS_Automation) for scoping and audit control

• Login Rights: - Grant Log on as a service and Log on as a batch job - Deny interactive and RDP logon rights to prevent manual sign-in

• Local Rights: Ensure the service account is part of the Administrators group inside target VMs (via GPO or template)

• Protocol Access (Optional): - Windows: Allow WinRM over HTTPS - Linux: Allow SSH key or password authentication

PowerShell Execution Policy (Windows Guests)

Sigma uses PowerShell remoting for in-guest Windows automation. To ensure script execution works properly, the execution policy for the SVC_SIGMA_OS account must be configured as RemoteSigned.

Configuration Steps (Run as Administrator on a guest VM):

# Verify current policy
Get-ExecutionPolicy -List

# Set RemoteSigned for the Sigma OS account
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

# Verify the change
Get-ExecutionPolicy -List

The output should show:

Scope          ExecutionPolicy
-----          ---------------
MachinePolicy       Undefined
UserPolicy          Undefined
Process             Undefined
CurrentUser         RemoteSigned
LocalMachine        Restricted

Alternative (via GPO):

To enforce this for the SVC_SIGMA_OS account or group:

1. Open Group Policy Management.

2. Create or edit a GPO linked to the OU containing target VMs.

3. Navigate to:

   User Configuration → Administrative Templates → Windows Components → Windows PowerShell

4. Enable Turn on Script Execution and select:

   Allow local scripts and remote signed scripts

WSUS & Third-Party Patch Management Requirements

For Sigma to fully manage Windows patching, target VMs must not be controlled by WSUS or any other external patch management platform. If WSUS or third-party tools manage updates, they override Sigma’s ability to control patch selection, scheduling, and compliance reporting.

Unsupported Configurations

The following must not be actively managing Windows Updates:

• WSUS (Windows Server Update Services)

• Altiris / Symantec ITMS

• Tanium Patch

• SCCM / MECM

• Any other agent-based patch orchestration platform

Required GPO State (No WSUS)

In:

Computer Configuration
  → Administrative Templates
    → Windows Components
      → Windows Update

Specify intranet Microsoft update service location → Must be Disabled or Not Configured

Required Registry State

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
WUServer → Must not exist

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
UseWUServer → Must be 0 or not present

Security Recommendations

- Least Privilege: Assign only the minimal rights required for each account.
- Credential Rotation: Rotate every 90–180 days and store securely (Sigma Secrets, Vault, or CloudTruth).
- Audit Logging: Review vCenter API and AD authentication logs regularly.
- Encryption: Require HTTPS/TLS for vCenter and WinRM/SSH encryption for guest access.
- Segregation of Duties: Store VMware API credentials and OS service credentials separately.

Configuration Steps in Sigma

1. Log in to your Sigma instance.

2. Navigate to: Administration → Environments.

3. Under Compute, click “Click to add”.

4. From the Select Provider dropdown, choose VMware.

5. Fill out the connection form: - Connection Name: Friendly name for the environment. - vCenter/ESXi Hostname or IP: Management endpoint. - Username / Password: VMware Integration Account (e.g., sigma@vsphere.local). - Click Connect to validate and register the connection.

6. Once connected, Sigma discovers clusters, hosts, and datastores.

7. To enable in-guest orchestration, configure guest OS credentials:

   See the Credential Management section for comprehensive instructions on creating and assigning credentials. Quick steps:

   • Navigate to Administration → Credentials and create a credential for your OS-Level Service Account (e.g., SVC_SIGMA_OS)

   • Assign the credential at the provider level (applies to all VMs) or instance level (specific VMs only)

   • Credentials support hierarchical resolution: instance-level assignments override provider-level defaults

   For detailed information on credential types, permission levels, assignment methods, and the credential override system, refer to the dedicated Credential Management section above.

Troubleshooting

Issue	Cause	Resolution
Invalid credentials	OS-level account used for VMware API authentication	Use the correct vCenter or ESXi account (sigma@vsphere.local).
Permission denied (NoPermission errors)	Missing Global.View or Global.Read permissions, or role scope not propagated to child objects	Ensure the role includes Global → Diagnostics and Global → Global tag permissions. The role must be assigned at the Datacenter level with “Propagate to children” enabled to ensure all child objects (folders, VMs) inherit the permissions.
Failed script execution	Missing AD rights or incorrect PowerShell policy	Ensure SVC_SIGMA_OS has admin/sudo rights and PowerShell execution policy set to RemoteSigned.
Connection timeout	Network port 443 blocked or firewall restrictions	Allow HTTPS access between Sigma and the vCenter/ESXi management network.
Certificate warning	Self-signed or untrusted VMware SSL certificate	Import the vCenter SSL certificate into Sigma or trusted CA store.

Next Steps

Once the VMware connection is established:

• Browse to Compute → VMware and confirm the inventory tree populates with clusters, hosts, datastores, and VM data.

• Assign the OS-Level Service Account to enable in-guest automation (script execution, configuration, software install).

• Save the configuration for reuse across environments or workflows.

ITSM

ServiceNow

Sigma integrates directly with ServiceNow through its REST API, allowing the platform to read, update, and attach files to change records automatically.

Overview

This integration enables Sigma automation workflows to: - Create or update change records in ServiceNow. - Attach configuration logs, deployment results, or compliance reports to a change ticket. - Synchronize build status and change approval metadata for audit purposes.

Connection Steps

1. Log in to ServiceNow as an administrator Navigate to System OAuth → Application Registry → New → Create an OAuth API endpoint for external clients.

2. Generate API credentials - Record the Client ID and Client Secret. - If using a user token, generate a personal access token (PAT) via the REST API Explorer → OAuth Token.

3. Set access permissions Ensure the integration user or token has the following roles: - itil (for incident/change access) - personalize_dictionary (optional, for extended field mapping) - attachment_admin (for file uploads)

4. Allow file attachment updates Go to System Properties → Attachments, and verify that “Allow attachments for change_request table” is enabled.

5. Copy the API credentials to Sigma In Sigma → Integrations → ITSM → ServiceNow, enter: - Instance URL: https://yourinstance.service-now.com - Client ID / Secret or API Token - Username / Password (if basic auth is used)

6. Test and save the connection Sigma will validate the ServiceNow API credentials and confirm access to the change_request endpoint. A success message indicates the integration is active.

Notes

• The ServiceNow user configured here becomes the “automation service account” for all ITSM change updates.

• Ensure the API user is excluded from human MFA policies.

• Logs and attachments uploaded by Sigma will appear with the configured ServiceNow username in the “Attachments” tab of each change request.

---

Jira

Sigma can integrate with both Jira Cloud and Jira Server using REST API authentication. This connection enables Sigma to automatically create or update issues, post deployment summaries, and attach audit files for traceability.

Overview

Typical use cases: - Auto-create Jira tickets for new Sigma automation events. - Update ticket status when a Sigma workflow completes successfully or fails. - Attach configuration reports and logs for review by ITSM teams.

Connection Steps

1. Log in to Jira (as a project admin) Navigate to your Atlassian profile (for Jira Cloud): Profile → Manage your account → Security → Create and manage API tokens.

2. Generate an API token - Click Create API token, name it “Sigma Integration”, and copy the generated token. - Store it securely; it will only be shown once.

3. Assign necessary permissions The integration account must have at least: - Browse Projects - Create Issues - Edit Issues - Add Comments - Attach Files

4. Copy API details to Sigma In Sigma → Integrations → ITSM → Jira, provide: - Jira Base URL: https://yourorg.atlassian.net (for Jira Cloud) - Username or Email Address used to create the token - API Token

5. Map issue types and fields (optional) Under Advanced Settings, you can map Sigma build types or orchestration tasks to Jira issue types (e.g., Deployment → Change, Alert → Incident).

6. Test and activate integration Click Test Connection. Sigma will perform a lightweight API call to verify authentication. Once validated, all Sigma-generated tickets will automatically include links to the associated Sigma job ID.

Notes

• Jira Cloud tokens do not expire unless revoked. Rotate periodically for compliance.

• For self-hosted Jira Server, you can instead configure basic authentication using an API user.

• Attachments larger than 10 MB are compressed automatically before upload.

---

Best Practices

• Use dedicated service accounts in ServiceNow and Jira to avoid accidental MFA or permission issues.

• Store credentials securely in Sigma’s encrypted secrets manager.

• Test connectivity after credential rotation or ServiceNow/Jira version upgrades.

• Tag all automated tickets (e.g., Sigma-Automate) for quick filtering in your ITSM dashboards.

AI

OpenAI

Sigma includes an optional integration with OpenAI to provide AI-assisted automation features such as script generation, configuration intelligence, and resource optimization insights.

Overview

This integration allows Sigma to leverage large-language-model intelligence for accelerating or augmenting IT automation workflows — for example: - Generating PowerShell, Bash, or Python scripts from plain-language task descriptions. - Summarizing configuration states, environment health, or log outputs. - Providing recommendations for cost right-sizing, automation templates, or runbook efficiency improvements.

Important — This Integration Is Optional

• The OpenAI connection is not required for normal Sigma operation.

• No data is shared with OpenAI unless you explicitly enable the feature and perform an AI-assisted action (e.g., “Generate Script” or “Explain Workflow”).

• You can disable the integration at any time in Sigma → Integrations → AI.

Connection Steps

1. Obtain an OpenAI API Key - Visit https://platform.openai.com/account/api-keys. - Click Create new secret key and copy the generated token. - Keep it secure — you won’t be able to view it again.

2. Configure the Integration in Sigma - Navigate to Integrations → AI → OpenAI. - Paste your API key into the provided field. - Choose your default model (e.g., gpt-4-turbo, gpt-4o-mini) if applicable. - Save and validate the connection.

3. Usage Examples Once connected, Sigma can use the OpenAI API to: - Generate automation scripts: convert natural-language tasks into executable PowerShell, Bash, or Python snippets. - Explain processes: summarize long logs or workflows in human-readable form. - Provide recommendations: suggest configuration or cost optimizations based on environment data.

4. Security and Privacy - Sigma transmits only the minimal contextual text needed for AI assistance — never credentials or secrets. - API keys are stored encrypted within Sigma’s secure key vault. - All data exchanged with OpenAI is processed over HTTPS using TLS 1.2 or higher.

Notes

• Enabling the AI integration enhances productivity and situational awareness but is not part of core automation.

• Organizations that prefer to keep all automation offline can leave this integration disabled with no impact on system functionality.

• Usage may incur costs according to your OpenAI account billing plan.