See the sections in this document for more information about the supported entity types for Microsoft Azure:

User Risk Information

Veza can collect and display risk information for users in your Azure AD tenant. This includes the user's risk level, risk state, risk details, and when the risk status was last updated. This feature requires a Microsoft Entra ID P2 license and the IdentityRiskyUser.Read.All permission for the Microsoft Graph API.

The following risk-related properties are collected:

• riskLevel: Indicates the level of risk for the user (low, medium, high, hidden, none)

• riskState: Shows the current state of the user's risk (none, confirmedSafe, remediated, dismissed, atRisk, confirmedCompromised)

• riskDetail: Provides detailed information about the risk state

• riskLastUpdatedDateTime: Indicates when the user's risk status was last updated

This information can help identify and monitor potentially compromised or risky user accounts in your Azure AD environment.

Azure CosmosDB Support

The integration supports Azure CosmosDB NoSQL databases, for visibility into database accounts, role assignments, and access patterns. The integration discovers:

• CosmosDB Account Services

• Database Accounts

• SQL Role Definitions and Assignments

• Effective Permissions

• Database Instances

CosmosDB extraction is disabled by default. To enable this functionality:

1. When configuring the Azure integration, select "Limited services" under Limit Services

2. In the services selection list, choose "Azure CosmosDB" along with all other services you want to extract.

Authorization & Access

CosmosDB uses three authorization mechanisms:

• Role-Based Access Control (RBAC) with Azure Active Directory

• Primary/Secondary Keys

• Resource Tokens

Veza focuses on RBAC permissions to show connections between Azure AD identities and CosmosDB resources. This provides visibility into:

• Which users and groups have access to CosmosDB accounts and databases

• How these permissions are assigned through role memberships

• The effective permissions users have on CosmosDB resources

Scope & Limitations

• Only CosmosDB NoSQL (core) API accounts are supported at present

• Container-level resources and permissions are not included in extraction

• Database-level users and permissions typically used for application end-users are not extracted

Required Permissions

The Veza service principal needs the Cosmos DB Account Reader role for extraction, which provides access to:

• Microsoft.DocumentDB/databaseAccounts/read

• Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions/read

• Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments/read

• Microsoft.DocumentDB/databaseAccounts/databases/read

These permissions allow Veza to discover core CosmosDB resources. No additional Microsoft Graph API permissions are required beyond the standard set used for Azure integration.

Azure RBAC

• Azure Subscription

• Azure Tenant

• Azure Management Group

• Azure Resource Group

• Azure Managed Identity

• Azure Role

• Azure Classic Administrator

• Azure Deny Assignment

• Azure Role Assignment

• Azure RBAC Effective Permission

• Azure Key Vault

Azure Cloud Infrastructure

• Azure Infrastructure Service

• Azure Virtual Machine

• Azure Virtual Network

• Network Security Group

• Network Interface Card

• Azure Subnet

Azure AD

AzureAD entities appear on left in Authorization Graph results, and can have federated access (cross-service connections) to external resources such as Snowflake tables or AWS S3 buckets.

• Azure AD Domain

• Azure AD User

• Azure AD Group

• Azure AD Role

• Azure AD Enterprise Application

• Azure AD App Role

• Azure AD Effective Permission

An Azure AD Premium P1/P2 license is required to gather Azure AD User last login dates. The Veza integration must also have the AuditLog.Read.All graph permission.

SharePoint Online

• SharePoint Online (service)

• SharePoint User

• SharePoint Group

• SharePoint Site

• SharePoint Library

• SharePoint Folder

• SharePoint Effective Permission

Storage

• Azure Blob Service

• Azure Blob Container

• Datalake Filesystem

• Datalake Directory

Azure Data Lake

No additional configuration is needed to discover Azure Data Lake Storage (ADLS). You can enable or disable ADLS as a data source using the provider configuration menu for the Azure tenant Select Services to Enable.

• ADLS Gen. 1 is not supported. The max directory extraction depth is 2 levels.

• Storage accounts have new properties: allowBlobPublicAcccess, allowSharedKeyAccess (default value null is equivalent to false), is_adls_gen2_enabled

• Storage containers now indicate if publicAccess is enabled

• If a filesystem or directory has an access control list, the full ACL string is shown as a property when viewing node details

Azure SQL

• SQL Server Service

• SQL Server Instance

• SQL Server Login

• SQL Server Role

Microsoft Intune

• Intune Managed Device

• Intune Role Assignment

• Intune Role

• Intune Resource Action

Microsoft Teams

The Azure integration can discover teams, channels, and guest users for Microsoft Teams, providing visibility into your Azure AD user and group permissions on shared resources, and access for external organization users.

Required permissions:

• Team.ReadBasic.All

• TeamMember.Read.All

• Channel.ReadBasic.All

• ChannelMember.Read.All

• User.Read.All

Supported entities:

• Team

• Channel

• External Organization User

  • Represents a team or channel member from an external organization, which might not exist as a discovered Azure AD User.

Note that the following metadata is not available from the current version of Graph API:

• Membership Settings For Shared And Private Channels

• Public Channel Moderators

Veza's integration with Microsoft Dynamics 365 ERP allows you to discover and visualize permissions data from your Dynamics 365 ERP environments, including Users, Groups, Application Users, and Security Roles. This integration shows connections between Azure AD Users, Groups, and Service Principals, and the roles they can assume within Dynamics 365 ERP.

Prerequisites

Before setting up the Dynamics 365 ERP integration:

Finding the Dynamics 365 ERP Environment URL

When configuring the Dynamics 365 ERP integration, you must provide the correct URL for your environment:

For ERP environments, use the operations URL in the format: https://xxx.operations.dynamics.com

Important: URLs must include the https:// protocol and must NOT include any trailing slashes at the end. For example, use https://company.operations.dynamics.com not https://company.operations.dynamics.com/.

Grant Azure AD Enterprise Application access to Dynamics 365 ERP

In order for Veza to extract Dynamics 365 ERP data, you need to grant your Azure AD Enterprise Application access to the Dynamics 365 ERP environments. To enable access to ERP:

2. In Dynamics ERP, go to Modules > System administration > Microsoft Entra ID applications and add an entry that matches your Entra ID Enterprise App ID

Enabling Enterprise App to access your Dynamics 365 ERP Environment does not use a paid license.

Configure Dynamics 365 ERP in Veza

1. Log in to Veza and navigate to Integrations

2. Edit your existing Microsoft Azure integration (or add a new one)

3. In the Dynamics 365 ERP Environments field, enter a comma-separated list of environments to discover

   • Example: https://company1.operations.dynamics.com,https://company2.operations.dynamics.com

   • Addresses must include the https:// protocol and omit any trailing /

4. Save the configuration.

5. Monitor the extraction progress in the Integrations dashboard

6. Verify successful extraction by checking that Dynamics 365 ERP entities appear in search results

Integration Architecture

The Dynamics 365 ERP integration operates as part of the Microsoft Azure integration rather than as a standalone connector. It leverages the same Enterprise Application credentials used for the Azure integration to access Dynamics 365 ERP environments.

The integration discovers organizational structure and security role assignments within Dynamics 365 ERP environments and maps them to Azure AD identities. This allows you to visualize which Azure AD users, groups, and applications have access to Dynamics 365 ERP security roles.

Supported Entities and Attributes

Veza discovers the following entities in Dynamics 365 ERP:

Environment

The Dynamics 365 ERP environment serves as the top-level container for all ERP resources.

• Type: DynamicsERPEnvironment

• Key Properties:

  • environment_url - The URL used to access the environment

  • azure_deployment_id - Azure deployment ID associated with the environment

  • aos_instance_name - Name of the AOS (Application Object Server) instance

  • tenant_id - Azure AD tenant ID associated with the environment

Users

Users represent people who access the Dynamics 365 ERP system, mapped to Azure AD accounts, with permissions defined by their security roles.

• Type: DynamicsERPUser

• Key Properties:

  • workflow_line_item_notification_format - Format for workflow line item notifications

  • document_handling_active - Whether document handling is active for the user

  • network_domain - Network domain for the user

  • company - Company the user belongs to

  • sqm_guid - SQM GUID for the user

  • alias - User's alias

  • email_provider_id - ID of the email provider

  • email - User's email address

  • default_country_region - Default country/region for the user

  • nickname - User's nickname

  • is_active - Whether the user is active

  • preferred_time_zone - User's preferred time zone

  • user_info_language - User's preferred language

  • auto_log_off - Auto log-off time for the user

  • account_type - User's account type

  • external_user - Whether the user is an external user

Groups

Groups (Teams) are collections of users who share common access permissions.

• Type: DynamicsERPGroup

• Key Properties:

  • Standard group properties (name, description, etc.)

Entra ID Applications

Entra ID Applications represent Azure Entra ID applications that have programmatic access to Dynamics 365 ERP resources.

• Type: DynamicsERPEntraIDApplication

• Key Properties:

  • user_id - User ID associated with the application

  • is_active - Whether the application is active

Security Roles

Security Roles define permission sets that control what actions users can perform within Dynamics 365 ERP.

• Type: DynamicsERPSecurityRole

• Key Properties:

  • context_string - Context string for the security role

  • description - Description of the security role

  • user_license_type - License type required for the role

  • access_to_sensitive_data - Whether the role provides access to sensitive data

Relationship Types

The Dynamics 365 ERP integration discovers the following relationship types:

Technical Limitations

• The integration currently does not support custom entity types in Dynamics 365 ERP

• Field-level security permissions are not currently extracted

• Limited to API-accessible security metadata; does not include permissions managed through custom code

Veza connects to Azure tenants using an App Registration granted read-only permissions for the Microsoft Graph API. You will need an app client ID, client secret, and the Azure tenant ID to enable the connection in Veza.

Adding an Azure tenant will parse all its services, including Azure AD as an Identity Provider (IdP), and Microsoft SharePoint Online as an additional data source.

See Notes & Supported Entities for more details and supported Microsoft services.

Integrating with Microsoft Azure

To integrate with Microsoft Azure, you will need to create an App Registration with read-only permissions for the services to discover. You will enter the App Registration's credentials when adding the Veza integration:

1. Register a new application for Veza

1. From your Azure tenant profile, navigate to App Registrations > New Registration

2. Name the new application (for example Veza Integration)

3. Select Accounts in this organizational directory only (tenantname only - Single tenant), and click "Register" to save your changes.

2. Grant permissions for the new app

1. With the new app registration selected, choose Manage > API Permissions and click "Add a Permission"

2. Select Microsoft Graph. Click "Application Permissions" and add the permissions:

   • Application.Read.All

   • AuditLog.Read.All (Required to collect last login date for users)

   • CustomSecAttributeAssignment.Read.All (Required to gather custom security attributes)

   • DeviceManagementManagedDevices.Read.All (Required to collect Intune devices)

   • DeviceManagementRBAC.Read.All (Required to collect Intune roles)

   • Device.Read.All (Required to collect Entra ID devices)

   • Directory.Read.All

   • Files.Read.All

   • Group.Read.All

   • GroupMember.Read.All

   • IdentityRiskyUser.Read.All

   • PrivilegedAccess.Read.AzureAD (Required for PIM roles and groups)

   • Reports.Read.All (Required when connecting to SharePoint Online)

   • RoleManagement.Read.All (Required for PIM roles and groups)

   • Sites.Read.All

   • User.Read.All

3. Enable "Grant Admin Consent" on the API permissions screen.

The delegated User.Read permission should be granted automatically. If it isn't present, add the permission from Add a Permission > Microsoft Graph > Delegated Permissions.

3. Enable SharePoint integration (optional)

Additional API permissions are required if you plan to connect to SharePoint Online. To grant read-only access for Veza, choose SharePoint on the app registration "Add a Permission" screen, and grant the application permissions:

• User.Read.All

• Sites.Read.All

The app registration will also need the Reports.Read.All Microsoft Graph permission from the previous step.

Enable audit log parsing for activity-based extraction

Audit log extraction for SharePoint is provided as an Early Access feature. Please contact your support team to enable this configuration option.

Enabling activity-based scheduling should help reduce lag between extractions, reducing the total time required to ingest large SharePoint environments. Please see below for the requirements and optional steps to enable:

1. 1. Go to https://compliance.microsoft.com and sign in. Click Audit.

   2. If auditing isn't enabled, a banner will prompt to Start recording user and admin activity.

   3. Click the banner to enable auditing, and wait for the changes to propogate.

   4. 1. Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

2. The Enterprise App used by Veza must have ActivityFeed.Read permission on the Office 365 Management API:
3. After you finish integrating the Azure tenant, enable audit log extraction under Veza Configuration → Cloud Providers. The audit log status column should update to show that extraction is enabled:

4. Generate a Client Secret

1. From Certificates & Secrets, click "New Client Secret" and select an expiration date. Click "Add" to generate a new client secret value and ID.

2. Copy the client secret Value, which you'll use to configure the integration within Veza.

5. Get the Application and Directory unique identifier

1. Open the Overview screen for the new application. Copy the Application (client) ID.

2. Copy the value for Directory (tenant) ID. You will need both values when adding the provider to Veza.

6. Assign the Reader role for the Veza app

1. From the Azure Subscription, select Access control (IAM)

2. Click on "+ Add" -> "Add role assignment"

3. Select "Reader" as the role

4. Select User, Group, or Service Principal" under Assign Access To

5. Select or search for the Veza app, and assign it the "Reader" role

6. (Optional) Assign the "Reader and Data Access" role to discover storage accounts and keys.

7. Save your changes

(Optional) Assign the Cosmos DB Account Reader role

To discover Azure CosmosDB resources, assign the Cosmos DB Account Reader role to the Veza app:

1. Navigate to your CosmosDB account in Azure Portal

2. Select Access control (IAM)

3. Click "+ Add" -> "Add role assignment"

4. Select "Cosmos DB Account Reader" as the role

5. Choose "User, Group, or Service Principal" under Assign access to

6. Search for and select the Veza app

7. Save the role assignment

7. Add Key Vault Permissions (Optional)

1. On the Key Vaults services page, choose the vault Veza will discover.

2. Select Access policies.

3. Click + Create.

4. Select List under Key Permissions, Secret permissions, and Certificate permissions.

5. Click Next.

6. Search and select the Veza app as the Authorized Application.

7. Click Next, Next, and Create to save the policy.

8. Add the Azure tenant to Veza

After completing the steps above, you can add the credentials and enable discovery by navigating to Veza Integrations > Add Integration. Choose Azure as the Integration Type.

Limit Services

Troubleshooting

Connecting to SharePoint

Custom Security Attributes

To enable custom property extraction:

1. Add or edit a new Azure cloud provider configuration.

2. On the provider configuration modal, click + Add Custom Property.

3. Provide the type and name of the custom property.

   1. For Azure AD, the name is the attribute name of the custom security attribute. The data type is a property of the custom security attribute (Boolean, Integer, or String).

   2. For example: (EngineeringCertification, Boolean), (MarketingLevel, String).
4. Save the configuration. The custom attributes will be collected the next time the data source is parsed.

Enable Privileged Identity Management (PIM)

To enable PIM extraction:

1. Ensure the required permissions are granted to the Veza app:

   • RoleManagement.Read.All

   • PrivilegedAccess.Read.AzureAD

   • Group.Read.All

2. When configuring the Azure integration, set the "Extract PIM Eligibility" option to "Yes"

3. Save the configuration. PIM assignments will be collected during the next extraction

Enable Dynamics 365

The Microsoft Azure integration includes optional support for Microsoft Dynamics 365. This integration allows Veza to discover connections between Azure AD Users, Groups, and Service Principals, and the permissions they can assume within Dynamics 365 environments.

Veza supports both Dynamics 365 CRM and Dynamics 365 ERP environments:

For full setup instructions and supported entities, see the specific integration guides.

Enable Microsoft Intune

The Microsoft Azure integration includes optional support for Intune, including Managed Devices and Role Definitions. Veza discovers and shows connections between Azure AD Users and Groups, and the Devices and Roles to which they are assigned in Intune.

In order to extract Intune, Veza requires the following Application Permissions for the Microsoft Graph API:

• DeviceManagementManagedDevices.Read.All

• DeviceManagementRBAC.Read.All

Enable Microsoft Teams

• Team.ReadBasic.All

• TeamMember.Read.All

• Channel.ReadBasic.All

• ChannelMember.Read.All

• User.Read.All

The Azure integration includes built-in support for PostgreSQL on Azure Database. After enabling the feature, you can use search, insights, and workflows to:

• Find principles with permissions on PostgreSQL Servers, Databases, Tables, and Schemas.

• Identify principles with privileged permissions (such as Delete) on PostgreSQL entities

Configuring Azure Database for PostgreSQL

To enable the connection between Veza and Azure PostgreSQL, you will need to:

• • Using an Insight Point is recommended when connecting to production environments. For testing purposes, you can use the internal Insight Point, assuming that firewall rules allow communication with Veza.

• Create local PostgreSQL user(s) Veza can use to log in.

• Enable PostgreSQL discovery by creating an Azure integration or editing an existing configuration.

Create a PostgreSQL user for Veza

For each server you want to discover, create a local user with read-only permissions on the required system tables. All Veza PostgreSQL users for different servers within a single Azure tenant must share the same username and password.

Log in as an administrator using your client of choice, and create a user with the required permissions. Replace [db_user] with the desired username:

CREATE USER [db_user] WITH LOGIN PASSWORD '[password]';
GRANT SELECT ON
  pg_catalog.pg_user,
  pg_catalog.pg_group,
  pg_catalog.pg_namespace,
  pg_catalog.pg_class,
  pg_catalog.pg_database,
  pg_catalog.pg_auth_members,
  pg_catalog.pg_attribute,
  pg_catalog.pg_roles,
  pg_catalog.pg_trigger,
  pg_catalog.pg_proc,
  pg_catalog.pg_collation,
  pg_catalog.pg_conversion,
  pg_catalog.pg_type,
  pg_catalog.pg_event_trigger,
  pg_catalog.pg_extension,
  pg_catalog.pg_foreign_data_wrapper,
  pg_catalog.pg_foreign_table,
  pg_catalog.pg_language,
  pg_catalog.pg_largeobject_metadata,
  pg_catalog.pg_operator,
  pg_catalog.pg_opclass,
  pg_catalog.pg_opfamily,
  pg_catalog.pg_policy,
  pg_catalog.pg_publication,
  pg_catalog.pg_sequence,
  pg_catalog.pg_foreign_server,
  pg_catalog.pg_statistic_ext,
  pg_catalog.pg_subscription,
  pg_catalog.pg_tablespace,
  pg_catalog.pg_ts_config,
  pg_catalog.pg_ts_dict,
  pg_catalog.pg_parameter_acl
TO [db_user];

Explicitly granting the pg_catalog permissions is required for Single server deployments. When configuring the user for Azure Flexible Servers, new users will already have access to pg_catalog tables, and a no privileges were granted warning will appear.

You will enter the local username and password when configuring the Azure integration on the Veza platform.

Troubleshooting

To verify that new user can read the required tables, you can log in as the new user ( \c postgres [db_user] in psql) and run the following script:

DO $$
DECLARE
    result integer;
BEGIN
    SELECT 1 FROM pg_catalog.pg_user LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_group LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_namespace LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_class LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_database LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_auth_members LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_attribute LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_roles LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_trigger LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_proc LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_collation LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_conversion LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_type LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_event_trigger LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_extension LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_foreign_data_wrapper LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_foreign_table LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_languageLIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_largeobject_metadata LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_operator LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_opclass LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_opfamily LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_policy LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_publication LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_sequence LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_foreign_server LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_statistic_ext LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_subscription LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_tablespace LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_ts_config LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_ts_dict LIMIT 1 INTO result;
    SELECT 1 FROM pg_catalog.pg_parameter_acl LIMIT 1 INTO result;
    RAISE NOTICE 'All queries were successful';
EXCEPTION
    WHEN OTHERS THEN
        RAISE NOTICE 'A read query failed';
END $$;

Enable PostgreSQL for the Azure integration

Log in to Veza as an administrator to finish configuring the integration. You can enable PostgreSQL for an existing integration, or when creating one.

1. In Veza, open the Integrations page..

   2. To modify an existing integration, find the provider on the main list and click Edit.

2. From the Insight Point dropdown, pick the one you created for connecting to the PostgreSQL server.

6. Optionally, enter a comma-separated list of databases and schema to allow or deny. If the allow list is populated, only those resources are discovered. If the deny list is populated, the specified resources are skipped.

Notes and Supported Entities

The integration supports flexible server and single server deployments. Azure Arc enabled PostgreSQL is not supported.

Veza discovers the following PostgreSQL entities and attributes:

PostgreSQL User

An individual account or identity, assigned specific permissions to control access to databases, schemas, tables, and other database objects.

• ID

• Provider ID

• Datasource ID

• Is Super User

• Can Create DB

• Can Initiate Streaming Replication

• Can Bypass All Row Level Security

• External Account Type

PostgreSQL Database

A logical container within an Azure PostgreSQL service instance that stores data, organized into tables. Several databases can exist within a single PostgreSQL instance, each serving a distinct purpose or application.

• Name

• ID

• Provider ID

• Datasource ID

• Owner

• Server ID

PostgreSQL Group

Represents a logical grouping of database users or roles. Groups manage access control and permissions by assigning specific privileges to several users with common roles.

• Name

• ID

• Provider ID

• Datasource ID

PostgreSQL Instance

A PostgreSQL instance in Azure represents a dedicated, managed PostgreSQL database server hosted on Azure infrastructure. Each instance has its own connection endpoint, configurations, and access controls.

• Name

• ID

• Provider ID

• Datasource ID

• Server ID

• Azure Tenant ID

PostgreSQL Schema

A container within a PostgreSQL database that helps organize database objects, such as tables and views. Schemas logically group and manage database objects, making it easier to maintain and navigate a complex database structure.

• Name

• ID

• Provider ID

• Datasource ID

• Owner

PostgreSQL Table

A fundamental database object that stores structured data in rows and columns, allowing for efficient querying and manipulation of data.

• Name

• ID

• Provider ID

• Datasource ID

• Owner

PostgreSQL Procedure

A fundamental database object that allowing user to write and execute functions written in supported languages, such as C.

• Name

• ID

• Provider ID

• Datasource ID

• Owner

PostgreSQL Trigger

A fundamental database object that automatically executes a particular function whenever a certain type of operation is performed.

• Name

• ID

• Provider ID

• Datasource ID

• Owner

PostgreSQL Permissions

Veza creates additional entities to represent capabilities users can have on PostgreSQL resources:

• PostgreSQL Privilege: Configured permissions, shown in System query mode.

• PostgreSQL Effective Permission: Effective permissions, shown in Effective query mode.

To collect complete authorization metadata for each database, you will need to create a local database user that the app registration can connect as to execute read-only queries.

• You will need access to Azure SQL Database(s) and permission to create the local user.

Create a local database user the Veza service principal can assume

Connect to your database and create a user, updating db_user in the examples to match the name of the Veza app registration:

CREATE USER [db_user] FROM EXTERNAL PROVIDER

Grant select permissions to the sys schema:

GRANT VIEW DEFINITION TO [db_user]

Grant Reader role to the Azure subscription

3. Review and assign the role. You can verify the subscription's role assignments from the main Access control panel.

The next time Veza conducts discovery of your Azure tenant, the new data source will be registered and appear on the Configuration > Apps and Data Sources panel.

Veza's integration with Microsoft Dynamics 365 CRM allows you to discover and visualize permissions data from your Dynamics 365 CRM environments, including Business Units, Users, Teams, Application Users, and Security Roles. This integration shows connections between Azure AD Users, Groups, and Service Principals, and the permissions they can assume within Dynamics 365 CRM.

Prerequisites

Before setting up the Dynamics 365 CRM integration:

Finding the Dynamics 365 CRM Environment URL

When configuring the Dynamics 365 CRM integration, you must provide the correct URL, which can be found on the organizations page:

2. Click on Environments

3. Select the Environment you are integrating

4. Locate the URL shown under the Environment URL field (the top field)

5. Copy the full URL which should look like: https://orgXXXXXXX.crm.dynamics.com

Important: URLs must include the https:// protocol and must NOT include any trailing slashes at the end. For example, use https://org1.crm.dynamics.com not https://org1.crm.dynamics.com/.

Grant Azure AD Enterprise Application access to Dynamics 365 CRM

In order for Veza to extract Dynamics 365 CRM data, you need to grant your Azure AD Enterprise Application access to the Dynamics 365 environments:

2. Go to Settings > Users + Permissions > Application Users and click New app user

3. Select the Microsoft Azure AD enterprise application you created during Azure integration setup

4. Pick the Business unit and assign a Service Reader security role to enable read access

5. Optionally add other security roles necessary for accessing the Dynamics 365 environment

6. Confirm with Create

Enabling Enterprise App to access your Dynamics 365 CRM Environment does not use a paid license.

Configure Dynamics 365 CRM in Veza

After setting up the necessary permissions:

1. Log in to Veza and navigate to Integrations

2. Edit your existing Microsoft Azure integration (or add a new one)

3. In the Dynamics 365 CRM Environments field, enter a comma-separated list of environments to discover

   • Example: https://org1.crm.dynamics.com,https://org2.crm.dynamics.com

   • Addresses must include the https:// protocol and omit any trailing /

4. Save the configuration.

5. Monitor the extraction progress in the Integrations dashboard

6. Verify successful extraction by checking that Dynamics 365 CRM entities appear in search results

Integration Architecture

The Dynamics 365 CRM integration operates as part of the Microsoft Azure integration rather than as a standalone connector. It leverages the same Enterprise Application credentials used for the Azure integration to access Dynamics 365 CRM environments.

The integration discovers organizational structure, security roles, and permission assignments within Dynamics 365 CRM environments and maps them to Azure AD identities. This allows you to visualize which Azure AD users, groups, and applications have access to Dynamics 365 CRM resources.

Supported Entities and Attributes

Veza discovers the following resources and permissions in Dynamics 365 CRM:

Environment

The Dynamics 365 CRM environment serves as the top-level container for all CRM resources.

• Type: Dynamics365Environment

• Key Properties:

  • environment_url - The URL used to access the environment

  • environment_id - Unique identifier for the environment

  • environment_region - Geographic region where the environment is hosted

  • datacenter_id - Identifier for the datacenter hosting the environment

  • organization_version - Version of the Dynamics 365 organization

  • organization_id - Unique identifier for the organization

  • tenant_id - Azure AD tenant ID associated with the environment

Business Units

Business Units are organizational divisions that structure a company within Dynamics 365, separating access to business data while sharing core information.

• Type: Dynamics365BusinessUnit

• Key Properties:

  • cost_center - Cost center associated with the business unit

  • description - Description of the business unit

  • disabled_reason - Reason for disabling the business unit (if applicable)

  • division_name - Name of the business division

  • website_url - URL of the business unit's website

  • workflow_suspended - Whether workflows are suspended for this business unit

  • is_disabled - Whether the business unit is disabled

  • created_at - When the business unit was created

  • updated_at - When the business unit was last updated

Users

Users represent people who access the Dynamics 365 system, mapped to Azure AD accounts, with permissions defined by their security roles and business unit assignments.

• Type: Dynamics365User

• Key Properties:

  • access_mode - User's access mode (read-write, admin, etc.)

  • application_id - Associated application ID (if applicable)

  • azure_ad_object_id - Azure AD object ID for the user

  • user_license_type - Type of license assigned to the user

  • on_prem_license_type - On-premises license type (if applicable)

  • disabled_reason - Reason for disabling the user (if applicable)

  • display_in_service_views - Whether the user appears in service views

  • domain_name - Domain name for the user

  • primary_email_status - Status of the user's primary email

  • employee_id - Employee ID for the user

  • invitation_status - Status of the user's invitation

  • integration_user_mode - Whether the user is an integration user

  • is_licensed - Whether the user has a license

  • is_synced_with_directory - Whether the user is synced with Azure AD

  • job_title - User's job title

  • outgoing_email_delivery_method - Method for delivering outgoing emails

  • owner_id - ID of the owner of this user record

  • personal_email - User's personal email address

  • setup_user - Whether the user is a setup user

  • windows_live_id - Windows Live ID for the user

  • business_unit_id - ID of the business unit the user belongs to

  • hierarchy_position - User's position in the organizational hierarchy

  • parent_user_id - ID of the user's parent in the hierarchy

  • organization_id - ID of the organization the user belongs to

  • email - User's primary email address

  • first_name - User's first name

  • last_name - User's last name

Teams

Teams are groups of users who share common access permissions, providing a way to manage access across business functions or project boundaries.

• Type: Dynamics365Team

• Key Properties:

  • azure_ad_object_id - Azure AD object ID for teams mapped to Azure AD groups

  • administrator_id - ID of the team administrator

  • description - Description of the team

  • email - Team's email address

  • is_default - Whether this is a default team

  • is_sas_token_set - Whether a SAS token is set for the team

  • membership_type - Type of team membership

  • business_unit_id - ID of the business unit the team belongs to

  • organization_id - ID of the organization the team belongs to

  • owner_id - ID of the team owner

  • is_system_managed - Whether the team is system-managed

  • team_type - Type of team

  • created_at - When the team was created

  • updated_at - When the team was last updated

Application Users

Application Users represent non-interactive service accounts or applications that need programmatic access to Dynamics 365 data using service principals.

• Type: Dynamics365ApplicationUser

• Key Properties:

  • application_user_id - Unique identifier for the application user

  • application_type - Type of application

  • business_unit_id - ID of the business unit the application user belongs to

  • can_impersonate_system_user - Whether the application can impersonate system users

  • component_state - State of the application component

  • is_managed - Whether the application user is managed

  • solution_id - ID of the solution associated with the application

  • state_code - Code representing the application state

  • status_code - Code representing the application status

  • created_at - When the application user was created

  • updated_at - When the application user was last updated

Security Roles

Security Roles define permission sets that control which actions users can perform on different record types, determining create, read, write, and delete access levels.

• Type: Dynamics365SecurityRole

• Key Properties:

  • is_inherited - Whether the security role is inherited

  • is_managed - Whether the security role is managed

  • solution_id - ID of the solution associated with the role

  • business_unit_id - ID of the business unit the role belongs to

  • organization_id - ID of the organization the role belongs to

  • created_at - When the security role was created

  • updated_at - When the security role was last updated

Relationship Types

The Dynamics 365 CRM integration discovers the following relationship types:

Technical Limitations

• The integration currently does not support custom entity types in Dynamics 365 CRM

• Field-level security permissions are not currently extracted

• Limited to API-accessible security metadata; does not include permissions managed through custom code

Troubleshooting

If you encounter issues connecting to your Dynamics 365 CRM environment:

1. Verify the URL is formatted correctly with https:// and no trailing /

2. Confirm the Azure AD Enterprise Application has been properly set up as an Application User in Dynamics 365

3. Ensure the Application User has at least the Service Reader security role

4. Check the extraction logs for any specific error messages

5. Verify that the Enterprise Application has all required permissions for Microsoft Graph API

6. Ensure that there are no network restrictions preventing access to the Dynamics 365 CRM environment

For more details about managing application users in Power Platform, see the Microsoft documentation: