Elevating SMB Security: How Privileged Identity Management (PIM) Provides Maximum Protection

Small and Medium-sized Businesses (SMBs) often operate with limited IT resources, making them attractive targets for cyberattacks. One of the most critical areas to secure is privileged access – the permissions granted to users or accounts that allow them to perform administrative functions or access sensitive data. Compromise of these accounts can lead to devastating data breaches, financial losses, and reputational damage.

Microsoft Entra ID Privileged Identity Management (PIM) is a service designed to mitigate these risks by managing, controlling, and monitoring access to important resources. For SMBs leveraging Microsoft Entra ID (formerly Azure Active Directory), PIM offers a powerful yet manageable solution to significantly enhance their security posture without requiring extensive infrastructure or specialized staff.

How PIM Improves Security for SMB Customers

PIM addresses key security challenges faced by SMBs by implementing the principle of “just-in-time” and “just-enough” access. Instead of granting standing administrative privileges to users indefinitely, PIM allows organizations to:

Minimize the attack surface: By reducing the number of accounts with permanent, highly privileged access, the potential entry points for attackers are significantly reduced.
Lessen the impact of a breach: If a regular user account is compromised, the damage is limited because that account doesn’t hold excessive permissions. Privileged access is only granted when explicitly needed and for a limited time.
Gain visibility into privileged activity: PIM provides detailed logging and auditing of privileged role activations and actions, making it easier to detect suspicious activity and investigate security incidents.
Enforce accountability: With PIM, you can track who activated a privileged role, when they activated it, and for what purpose (if justification is required), creating a clear audit trail.
Support compliance efforts: Many regulatory requirements mandate strict control and monitoring of privileged access. PIM helps SMBs meet these obligations.
Reduce human error: By requiring activation and justification for privileged tasks, PIM encourages a more deliberate approach to administrative actions, reducing the likelihood of accidental misconfigurations or data deletion.

Essentially, PIM transforms standing access into eligible access, requiring users to activate their elevated permissions only when necessary, for a defined period.

PIM is part of the features of Entra ID P2, which means it is not natively available with Microsoft 365 Business Premium but is available as part of the E5 Security Add-on to Microsoft 365 Business Premium.

Configuring PIM for Maximum Protection: A Step-by-Step Guide for SMBs

Configuring PIM effectively is crucial to maximizing its security benefits. Here’s a step-by-step guide tailored for SMBs:

Phase 1: Initial Setup and Role Discovery

Identify and Inventory Privileged Roles:
- Navigate to the Microsoft Entra admin center (entra.microsoft.com).
- Go to Identity governance > Privileged Identity Management.
- Select Microsoft Entra roles or Azure resources (depending on the resources you want to protect).
- Review the list of available roles and identify which users are currently assigned to highly privileged roles (e.g., Global Administrator, Security Administrator, User Administrator). This step is critical to understand your current privilege landscape.
Assign Eligible Roles:
- For users who require privileged access for their duties, change their assignment type from “Active” (permanent) to “Eligible”.
- Select the role you want to configure and go to Assignments.
- Add assignments for users, selecting “Eligible” as the assignment type.
- Set an expiration date for the eligible assignment. While eligible assignments can be permanent, setting an expiration (e.g., 1 year) and requiring periodic review is a best practice for maximum security.

Phase 2: Configuring Role Settings for Enhanced Security

For each privileged role you’ve identified, configure the following settings to enforce strong controls during activation:

Access Role Settings:
- In the PIM portal, select the relevant resource type (Microsoft Entra roles or Azure resources).
- Select Roles, then choose the specific role you want to configure.
- Select Settings > Edit.
Activation Maximum Duration:
- Set the Activation maximum duration to the shortest possible time required to complete typical administrative tasks. For most SMBs, 1-4 hours is often sufficient. Avoid setting this to the maximum 24 hours unless absolutely necessary.
On activation, require multifactor authentication (MFA):
- Enable this setting for all privileged roles. This is one of the most effective controls to prevent unauthorized activation even if a user’s password is compromised. Ensure all eligible users are enrolled in Microsoft Entra multifactor authentication.
On activation, require justification:
- Enable this setting. Requiring users to provide a business justification for activating a privileged role creates an audit trail and encourages users to think critically before elevating their permissions.
Require approval to activate:
- For highly sensitive roles (e.g., Global Administrator, Security Administrator), enable this setting.
- Specify approvers (ideally, a small group of trusted administrators) who must approve activation requests before the user gains privileged access. This adds an extra layer of control and prevents a single compromised account from immediately gaining high-level access. Ensure your approvers understand their responsibility and the importance of timely responses.
Notification Settings:
- Configure notifications to alert administrators when privileged roles are activated. This provides near real-time awareness of privileged activity.

Phase 3: Implementing Access Reviews

Regularly reviewing who has eligible and active assignments is crucial to maintain a strong security posture.

Create Access Reviews:
- In the PIM portal, select the relevant resource type.
- Under Manage, select Access reviews.
- Click New to create a new access review.
Configure Access Review Settings:
- Name and Description: Give the review a clear name and description (e.g., “Quarterly Global Administrator Role Review”).
- Start and End Dates: Define the duration of the review.
- Frequency: Set the review to recur regularly (e.g., quarterly or semi-annually) to ensure ongoing oversight.
- Roles to Review: Select the privileged roles you want to include in the review.
- Reviewers: Assign appropriate reviewers. For SMBs, this might be a trusted IT administrator or a business owner who understands the need for specific roles. You can also configure users to review their own access, but this should be used with caution and ideally combined with another layer of review for critical roles.
- Upon completion settings: Configure what happens after the review. You can choose to automatically remove access for users who were denied or not reviewed.

Phase 4: Ongoing Monitoring and Maintenance

Monitor Alerts and Notifications: Regularly review the PIM alerts and notifications in the Microsoft Entra admin center and via email.
Audit Logs: Periodically review the PIM audit logs to understand who activated which roles and when.
Refine Settings: As your business evolves, periodically review and refine your PIM role settings and access review configurations to ensure they remain appropriate for your security needs.

By implementing Microsoft Entra ID Privileged Identity Management and following these configuration steps, SMBs can significantly enhance their security by moving away from standing administrative privileges and adopting a just-in-time approach. This proactive measure helps protect against the misuse of elevated access, reduces the impact of potential security incidents, and strengthens the overall security posture in an increasingly complex threat landscape.

A Guide to Microsoft Entra Private Access for On-Premise Servers

Microsoft Entra Private Access offers a modern, secure way to connect your users to on-premise applications and resources without the need for traditional VPNs. This service, part of Microsoft’s Security Service Edge (SSE) solution, Global Secure Access, allows you to grant granular access based on identity and context, enhancing your security posture.

Here’s a comprehensive guide to setting up and configuring Microsoft Entra Private Access to connect back to your on-premise servers:

I. Understanding the Core Components:

Before diving into the setup, it’s essential to understand the key elements involved:

Microsoft Entra ID: Your cloud-based identity and access management service. It will handle user authentication and authorization.
Global Secure Access (SSE): The overarching service in Microsoft Entra that includes Private Access and Internet Access. You’ll configure Private Access settings within this portal.
Microsoft Entra Private Network Connector: Lightweight agents installed on your on-premise Windows servers. These connectors establish a secure outbound connection to the Microsoft Entra Private Access service, acting as a reverse proxy to your internal applications. They do not require inbound firewall rules, enhancing security.
Connector Groups: Logical groupings of connectors. You can assign specific applications to particular connector groups for better organization, resilience, and traffic management.
Enterprise Applications in Entra ID: You will register your on-premise applications as Enterprise Applications in Entra ID. This allows you to configure Single Sign-On (SSO), assign users and groups, and apply Conditional Access policies.
Traffic Forwarding Profiles: Part of Global Secure Access, these profiles ensure that traffic destined for your private, on-premise resources is correctly routed through the Private Access service.

II. Prerequisites:

Ensure you have the following before you begin the configuration:

Licensing:

Microsoft Entra ID Premium P1 or P2 licenses are required for users accessing applications through Private Access.

Global Secure Access (preview) might have specific trial or preview licensing requirements. Check the latest Microsoft documentation.

Permissions:

Global Administrator or Private Access Administrator role in Microsoft Entra ID to configure Global Secure Access and Private Access settings.

Application Administrator role if you need to configure Enterprise Applications (if not a Global Administrator).

Local Administrator rights on the on-premise Windows servers where you will install the Private Network Connectors.

On-Premise Server Requirements for Connectors:

A Windows Server (check Microsoft documentation for supported versions, typically Windows Server 2012 R2 or later). The server must have .NET Framework (usually 4.7.2 or later) installed.

The server must have outbound connectivity to specific Microsoft URLs and ports. Refer to the official Microsoft documentation for the most up-to-date list of required URLs and ports. Proxies, if used, must be configured appropriately.

The server should have network connectivity to the on-premise applications you intend to publish.

TLS 1.2 should be enabled on the connector server.

Network Considerations:

Ensure your on-premise network allows outbound HTTPS (TCP port 443) traffic from the connector servers to the Microsoft Entra Private Access service endpoints.

Internal DNS resolution must be working correctly for the connector servers to find your on-premise applications.

III. Step-by-Step Configuration Guide:

Step 1: Prepare Your On-Premise Environment

Identify Connector Servers: Choose at least two Windows servers for installing the Private Network Connectors to ensure high availability. These servers should be dedicated to this role or have sufficient resources if shared.
Verify Network Connectivity: Confirm the chosen servers can reach your internal applications and have the necessary outbound internet access as per Microsoft’s requirements.
Disable IE Enhanced Security Configuration (Recommended during setup): This can sometimes interfere with the connector registration process. You can re-enable it afterward.

Step 2: Install and Register the Microsoft Entra Private Network Connector(s)

Access the Global Secure Access Portal:

Navigate to the Microsoft Entra admin center (entra.microsoft.com).

Go to Global Secure Access (Preview) > Connect > Connectors.

2. Download the Connector: Click on “Download connector service” and accept the terms.

3. Install the Connector:

Copy the downloaded installer to your chosen on-premise server(s).

Run the installer as a local administrator.

Follow the on-screen prompts.

4. Register the Connector:

During the installation, a pop-up window will prompt you to sign in to your Microsoft Entra ID. Use an account with Global Administrator or Private Access Administrator privileges.

Upon successful authentication, the connector will register with your Entra ID tenant and appear in the “Connectors” list in the Global Secure Access portal.

5. Repeat for High Availability: Install and register the connector on at least one more server for redundancy.

Step 3: Create and Configure Connector Groups (Recommended)

Navigate to Connector Groups: In the Global Secure Access portal, go to Connect > Connector groups.
Create a New Connector Group:

Click “+ Create connector group”.

Give the group a descriptive name (e.g., “OnPrem-App-Group”).

Assign the newly installed connectors to this group.

Click “Save”.

3. Purpose: Connector groups allow you to dedicate specific sets of connectors to particular applications, which is useful for large environments or if you need to isolate traffic. If you don’t create one, your connectors will reside in a “Default” group.

Step 4: Configure Quick Access or Global Secure Access Apps for Your On-Premise Application

This is where you define how users will access your on-premise resources. You have two main approaches within Global Secure Access:

Quick Access: This is the simplest way to enable access to all on-premise resources or a broad set of FQDNs/IP addresses.

In the Microsoft Entra admin center, go to Global Secure Access (Preview) > Applications > Quick access.
Click on “+ Add Quick Access app”.
Select the Connector group you created earlier.
Under Application segment, click “+ Add application segment”.
Choose the Destination type:

IP address: For specific server IPs.

Fully qualified domain name (FQDN): For accessing applications by their DNS names (e.g., sharepoint.internal.contoso.com). This is generally preferred.

IP address range: For a subnet.

6. Enter the Destination(s) and the Port(s) your application uses (e.g., intranet.mycompany.local on port 80 or 443).

7. Click “Apply” and then “Save”.

Global Secure Access App (Enterprise Application): This method involves creating or using an existing Enterprise Application in Entra ID for more granular control, including SSO and Conditional Access policies.

Create/Configure the Enterprise Application:

In the Microsoft Entra admin center, navigate to Identity > Applications > Enterprise applications.

Click “+ New application”.

Choose “Create your own application” (for non-gallery, on-premise apps).

Give your application a name (e.g., “OnPrem SharePoint”).

Select “Integrate any other application you don’t find in the gallery (Non-gallery)”.

Click “Create”.

2. Configure Private Access for the Enterprise App:

Once the application is created, go to its Properties.

Set Assignment required? to “Yes” if you want to control who can access it.

Configure Single sign-on (SSO) if desired (e.g., Kerberos Constrained Delegation, SAML, or password-based). Header-based SSO is also a common option for on-premise web apps. The specifics depend heavily on your on-premise application’s authentication capabilities.

Assign Users and groups who should have access to this application.

3. Link the Enterprise Application in Global Secure Access:

Go to Global Secure Access (Preview) > Applications > Enterprise applications.

Click “+ Add app”.

Search for and select the Enterprise Application you configured.

Select the Connector group.

Under Application segment, click “+ Add application segment”.

Enter the Internal FQDN or IP address and Port of your on-premise application as it’s accessible from the connector servers.

Click “Apply” and then “Save”.

Step 5: Configure Traffic Forwarding Profile

You need to ensure that traffic to your private resources is forwarded to the Global Secure Access service.

Go to Global Secure Access (Preview) > Connect > Traffic forwarding.
Ensure the Private access profile is enabled. This profile will automatically include the destinations you configured in Quick Access or your Global Secure Access Apps.

Step 6: Install and Configure the Global Secure Access Client (on end-user devices)

For users to access the on-premise applications through Entra Private Access, they need the Global Secure Access Client installed on their Windows devices.

Download the Client:

In the Microsoft Entra admin center, go to Global Secure Access (Preview) > Connect > Client download.

Download the client.

2. Deploy the Client: Deploy the client to your end-user devices using methods like Intune, SCCM, or manual installation.

3. Client Behavior: Once installed and the user is signed in, the client will route traffic for the configured private resources through the Microsoft Entra Private Access service based on the traffic forwarding profiles.

Step 7: Configure Conditional Access Policies (Highly Recommended)

Enhance security by applying Conditional Access policies to your newly published on-premise applications.

Go to Protection > Conditional Access in the Microsoft Entra admin center.
Create a new policy.
Under Assignments, select the users and groups you want this policy to apply to.
Under Cloud apps or actions, select your Enterprise Application (if using that method) or all traffic profiles if using Quick Access more broadly.
Define Conditions (e.g., device compliance, location, sign-in risk).
Under Access controls, configure Grant controls (e.g., require multi-factor authentication, require compliant device).

Step 8: Test Access

From a client device with the Global Secure Access Client installed and a user assigned the necessary permissions:

Try accessing the on-premise application using its external FQDN (if you configured one) or the internal FQDN/IP address you specified in the Quick Access or Enterprise Application configuration.

The traffic should be transparently routed through the Private Access service to your on-premise application.

Verify SSO functionality if configured.

IV. Important Considerations and Best Practices:

High Availability for Connectors: Always deploy at least two connectors in a connector group, installed on different servers, to avoid a single point of failure.
Connector Server Sizing: Ensure the connector servers have adequate CPU, memory, and network capacity based on the expected load.
Network Segmentation: Place connector servers in a network segment that has access to the required applications but is otherwise appropriately secured.
Least Privilege:

When configuring applications, only publish the specific FQDNs and ports required. Avoid overly broad rules.

Grant users the minimum necessary permissions to the applications.

Monitoring:

Monitor the status of your connectors in the Global Secure Access portal.

Review sign-in logs and audit logs in Microsoft Entra ID for access to these applications.

Utilize the Global Secure Access traffic logs.

Updates: Keep the Private Network Connector software and the Global Secure Access Client updated to the latest versions.
DNS: Ensure that the FQDNs of your on-premise applications are resolvable by the Private Network Connectors. If you are using private DNS names, these must be resolvable by your internal DNS servers that the connectors use. External users will typically access the application via a URL provided by Entra ID, which then proxies the connection.
SSL/TLS Certificates: For applications published with SSL, ensure the certificates are valid and trusted by the connector servers and, if applicable, by the end-user browsers (though typically the Private Access service handles the external SSL termination).
Application Compatibility: While Entra Private Access supports a wide range of TCP-based applications (and UDP in preview for some scenarios), thoroughly test your specific applications for compatibility.

By following these steps, you can effectively leverage Microsoft Entra Private Access to provide secure, modern access to your on-premise resources, simplifying user experience and strengthening your overall security infrastructure. Always refer to the latest official Microsoft documentation for any changes or more detailed guidance, especially as Global Secure Access services continue to evolve.

Setting Up Entra ID Secure Private Access for On-Premise Servers

Microsoft Entra Private Access offers a modern, secure way to connect users to your on-premise applications and resources without the need for traditional VPNs. This solution, part of Microsoft’s Global Secure Access (GSA) services, leverages the principles of Zero Trust Network Access (ZTNA) to provide granular, identity-centric access controls.

Here’s a comprehensive guide to setting up and configuring Entra ID Secure Private Access for your on-premise servers:

I. Prerequisites:

Before you begin, ensure you have the following:

Licensing: A Microsoft Entra ID Premium P1 or P2 license is required. Entra Private Access is often included in suites like the Microsoft Entra Suite.
Administrative Roles: You’ll need appropriate administrative roles in Microsoft Entra ID, such as Global Secure Access Administrator and Application Administrator.
On-Premise Server(s) for Connectors:

Operating System: Windows Server 2012 R2 or later.

.NET Framework: Version 4.7.1 or higher (latest recommended).

TLS 1.2: Must be enabled on the server.

Outbound Connectivity: Ports 80 and 443 must be open for outbound connections to Microsoft Entra services and other required URLs. Ensure your firewall or proxy allows this traffic.

No Inbound Ports Required: The connectors use outbound connections, enhancing security.

Server Resources: Allocate sufficient CPU and memory (e.g., 4+ cores, 8GB+ RAM recommended per connector for optimal performance, though minimums may be lower).

Domain Join (Recommended for Kerberos SSO): For Single Sign-On with Integrated Windows Authentication (IWA) or Kerberos Constrained Delegation (KCD), the connector server(s) should be in the same Active Directory domain as the application servers or in a trusting domain.

Client Devices:

Operating System: Windows 10/11 (64-bit).

Entra ID Status: Devices must be Microsoft Entra joined or Microsoft Entra hybrid joined (not just registered).

Global Secure Access (GSA) Client: This client software needs to be installed on user devices to direct traffic to the GSA service.

Network Configuration:

Ensure your internal DNS can resolve the on-premise resources you intend to publish.

If using firewalls, ensure they don’t block traffic to the necessary Microsoft URLs and that TLS inspection is not performed on traffic from the connectors to the Microsoft services, as this can interfere with the mutual TLS authentication.

II. Core Setup Steps:

Activate Global Secure Access (GSA):

Navigate to the Microsoft Entra admin center (https://entra.microsoft.com).

Under the “Global Secure Access (Preview)” section, go to the “Dashboard.”

If not already activated, click the “Activate” button to begin using Global Secure Access services, which include Entra Private Access.

2. Install and Configure Microsoft Entra Private Network Connector(s):

Download the Connector: In the Entra admin center, go to Global Secure Access (SSE) > Connect > Connectors. Select “Download connector service.” Accept the terms and download the installer.

Install on On-Premise Server(s):

Copy the installer to your designated on-premise Windows Server(s).

Run the MicrosoftEntraPrivateNetworkConnectorInstaller.exe as an administrator.

Follow the wizard. You will be prompted to authenticate with your Entra ID Application Administrator credentials.

Important for Windows Server 2019 and later: You might need to disable HTTP/2 in WinHttp for Kerberos Constrained Delegation to function correctly if you plan to use it. This can be done via a registry setting or PowerShell command:
PowerShell
Set-ItemProperty ‘HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\’ -Name EnableDefaultHTTP2 -Value 0
A server restart might be required after this change.

High Availability: Install at least two connectors on different servers for redundancy and load balancing.

Connector Groups:

Connectors are automatically assigned to a default group. You can create custom connector groups for better organization and to assign specific applications to specific sets of connectors. This is useful for isolating traffic or managing access to applications in different network segments.

Navigate to Global Secure Access (SSE) > Connect > Connectors. Select “New connector group” to create and assign connectors.

Verify Installation: After installation, check the “Connectors” page in the Entra admin center to ensure your connectors are listed and show an “Active” (green) status. Also, verify that the “Microsoft Entra private network connector” and “Microsoft Entra private network connector updater” services are running on the connector servers.

3. Configure Traffic Forwarding for Private Access:

In the Entra admin center, go to Global Secure Access (SSE) > Connect > Traffic forwarding.

Ensure the “Private access profile” is enabled. This tells the GSA client on end-user devices to forward traffic destined for your private resources through the Entra Private Access service.

III. Publishing On-Premise Applications:

You have two main approaches to publishing your on-premise applications:

Quick Access (Broad Network Access):

This method allows you to quickly provide access to entire network segments (IP ranges, FQDNs) rather than individual applications. It’s a simpler way to start, especially when migrating from traditional VPNs.

Configuration:

Navigate to Global Secure Access (SSE) > Applications > Quick Access.

Provide a name for your Quick Access configuration.

Click “+ Add Quick Access application segment.”

Define the destination type (IP address, FQDN, IP range, or Subnet).

Enter the details (e.g., IP address and port(s) like 192.168.1.10:3389 for RDP or fileserver.corp.local:445 for SMB).

Assign users or groups who should have access to this Quick Access application.

Use Case: Useful for scenarios like accessing internal file shares, RDP to servers, or internal websites where per-app granularity isn’t immediately required.

2. Per-App Access (Enterprise Applications – Zero Trust Approach):

This is the recommended approach for a Zero Trust security posture, providing granular access control to specific applications. This method is similar to the traditional Entra Application Proxy setup but integrated within the Global Secure Access framework.

Configuration:

Navigate to Global Secure Access (SSE) > Applications > Enterprise applications.

Click “+ New application.”

Select “Add an on-premises application” (or “Create your own application” if it’s not a pre-integrated template).

Basic Settings:

Name: A user-friendly name for the application.

Internal URL: The URL or FQDN/IP address used to access the application on your internal network (e.g., http://intranet.corp.local or 10.0.0.50:8080).

External URL: This will be automatically generated (usually https://<yourtenant>-<appname>.msappproxy.net) or you can configure a custom domain. This is the URL users will access from the internet.

Pre-Authentication: Choose “Microsoft Entra ID” to enforce authentication before users reach the application. “Passthrough” is an option but less secure.

Connector Group: Assign the application to a specific connector group (or the default).

Additional Settings (Optional but Recommended):

Single Sign-On (SSO): Configure SSO (e.g., Kerberos, SAML, header-based, password-based) for a seamless user experience. This might require additional configuration on your on-premise application and in Entra ID.

Backend Application Timeout.

Translate URLs in Headers/Application Body (for web apps): Useful if your application has hardcoded internal links.

Assign Users and Groups: After creating the application, assign users or groups who are permitted to access it.

Use Case: Ideal for publishing web applications, APIs, and even non-HTTP applications (by specifying TCP/UDP ports) with fine-grained access control.

IV. Client-Side Setup (Global Secure Access Client):

Download and Deploy: The Global Secure Access client needs to be installed on end-user Windows devices. You can find the client download in the Entra admin center under Global Secure Access (SSE) > Connect > Client download.
Installation: Install the client. Users will typically need local admin rights for installation.
Sign-in: Users sign into the GSA client with their Entra ID credentials.
Connectivity: Once signed in and the traffic forwarding profiles are active, the client will automatically route traffic destined for the configured private resources through the Entra Private Access service. Users should then be able to access the on-premise applications using their internal FQDNs or IPs (for Quick Access) or the External URL (for Enterprise Applications).

V. Security and Management:

Conditional Access Policies:

Leverage Entra ID Conditional Access policies to enforce additional security controls for accessing your on-premise applications.

You can require Multi-Factor Authentication (MFA), compliant devices, specific locations, or limit session risk before granting access.

Enable “Global Secure Access signaling in Conditional Access” under Global Secure Access (SSE) > Global settings > Session management > Adaptive Access to use GSA-specific conditions in your policies.

Monitoring and Logging:

Utilize Entra ID sign-in logs and audit logs to monitor access attempts.

Global Secure Access provides its own traffic logs (NetworkAccessTraffic table) which can be ingested into Log Analytics/Azure Sentinel for detailed analysis and reporting.

Privileged Identity Management (PIM): For highly sensitive applications, integrate with Entra ID PIM to provide just-in-time (JIT) access.
Regularly Update Connectors: The connector updater service should keep your connectors up-to-date automatically. However, monitor their status and version.
DNS Configuration for FQDNs in App Segments: For Entra Private Access app segments configured with FQDNs, name resolution is typically redirected to the connector, allowing internal DNS resolution.

VI. Key Differences and Considerations (Entra Private Access vs. Entra Application Proxy):

Foundation: Entra Private Access is built upon the foundation of Entra Application Proxy but is part of the broader Security Service Edge (SSE) solution, Global Secure Access.
Protocols: While Application Proxy traditionally focused on web applications (HTTP/S), Entra Private Access is designed to be more protocol-agnostic, tunneling TCP/UDP traffic. This makes it suitable for a wider range of applications, including RDP, SMB, and other client-server applications.
Client Requirement: Entra Private Access generally requires the Global Secure Access client on end-user devices. Traditional Application Proxy for web apps might not always require a dedicated client beyond a web browser (though the GSA client enhances this).
Access Model: Entra Private Access strongly aligns with ZTNA principles, allowing for both broad “Quick Access” and granular “Per-App Access.”
B2B/BYOD: Historically, Application Proxy had more established support for B2B guest users. Entra Private Access capabilities for these scenarios are evolving. For now, accessing devices typically need to be Entra ID joined/hybrid joined.

Troubleshooting:

Connector Status: Always check the connector status in the Entra admin center and the services on the connector server.
Logs: Review Entra ID logs, GSA traffic logs, and event logs on the connector server (e.g., MicrosoftEntraPrivateNetworkConnectorService.exe.config can be modified for more detailed connector logging).
Network Connectivity: Verify outbound connectivity from connector servers to Microsoft services and from connector servers to the internal application servers.
Client Health: Check the GSA client status on the end-user device.

By following these steps, you can effectively set up and configure Microsoft Entra Private Access to provide secure, modern access to your on-premise servers and applications, reducing reliance on traditional VPNs and strengthening your overall security posture. Remember to consult the latest Microsoft documentation for any updates or changes to the service.

Sources

1. https://github.com/changeworld/azure-docs.pt-br

Minimum Viable Configuration for Microsoft Sentinel

What is the the Minimum Viable Configuration (MVC) for Microsoft Sentinel aimed at protecting a small business (SMB), the setup steps, and the estimated costs.

Understanding the Goal of an MVC for Sentinel in an SMB Context

The goal isn’t to catch every sophisticated nation-state attack, but to provide fundamental visibility and detection for common threats targeting SMBs, such as:

Compromised Credentials: Detecting suspicious sign-ins, impossible travel, etc.
Malware/Ransomware: Leveraging endpoint protection alerts.
Phishing & Email Threats: Monitoring Office 365 activity.
Basic Cloud Misconfigurations/Anomalies: Using built-in cloud security alerts.

The MVC focuses on leveraging the security signals already generated by the Microsoft ecosystem (assuming the SMB uses Microsoft 365 and Azure AD).

Minimum Viable Configuration (MVC) Components

Azure Subscription: The foundation for all Azure services.
Log Analytics Workspace: The data repository where Sentinel stores and analyzes logs. Configured for Pay-As-You-Go pricing initially.
Microsoft Sentinel Instance: Enabled on top of the Log Analytics Workspace.
Core Data Connectors (Focus on Free/Included Tiers First):
- Azure Active Directory (Entra ID):
  - Sign-in Logs (Requires Azure AD P1 or P2 license) – Crucial for credential compromise detection.
  - Audit Logs (Free) – Tracks admin activity.
  - Azure AD Identity Protection Alerts (Requires Azure AD P2 license) – High-fidelity alerts for risky users/sign-ins. If P2 isn’t available, rely more heavily on Sign-in log analytics.
- Microsoft 365 Defender (Recommended if licensed): This single connector can ingest alerts from:
  - Microsoft Defender for Endpoint (if using MDE Plan 1/2 or Defender for Business)
  - Microsoft Defender for Office 365 (if using Plan 1/2)
  - Microsoft Defender for Identity (less common in pure SMB cloud setups)
  - Microsoft Defender for Cloud Apps
  - Benefit: Ingesting Alerts via this connector is often free.
- Office 365 (Alternative/Supplement to M365 Defender):
  - Exchange Online & SharePoint Online audit logs (Standard Audit is generally free to ingest). Essential for tracking file access, mail rule changes, etc.
- Azure Activity Log (Free): Tracks subscription-level events (creating VMs, changing settings). Important for basic Azure infrastructure security hygiene.
Essential Analytics Rules (Start with Templates):
- Enable built-in Microsoft Security templates related to the connected data sources. Focus on:
  - Suspicious Azure AD Sign-in activity (Impossible travel, unfamiliar locations, logins from known malicious IPs).
  - Anomalous Office 365 activity (e.g., mass file downloads/deletions, suspicious inbox rule creation).
  - Alerts forwarded from Microsoft Defender products (e.g., Malware detected, phishing email reported).
  - Basic Azure activity anomalies (e.g., unusual resource creation/deletion).
Incident Management: Rely on the built-in Sentinel Incident queue for manual review and investigation.

What’s NOT in this MVC (to keep it minimal):

Third-Party Data: No logs from non-Microsoft firewalls, servers, or applications initially.
Advanced Analytics: No custom rules, machine learning models (beyond built-in ones), or complex threat intelligence feeds initially.
SOAR/Automation: No automated response playbooks initially. Response is manual review and action.
Extensive Workbooks/Dashboards: Rely on default views.
Long Data Retention: Stick to the default or included retention (often 90 days free with Sentinel).

Setup Steps

Prerequisites:
- An Azure Subscription.
- Appropriate Permissions: Contributor or Owner on the Azure subscription/resource group; Global Administrator or Security Administrator role in Azure AD/Microsoft 365 to authorize connectors.
- Relevant Licenses: Microsoft 365 Business Premium (includes Defender for Business, Azure AD P1), M365 E3/E5, or standalone licenses (Azure AD P1/P2, Defender plans) are highly recommended for the data sources.
Step 1: Create a Log Analytics Workspace
1. Log in to the Azure portal (portal.azure.com).
2. Search for “Log Analytics workspaces” and click “Create”.
3. Choose your Subscription and Resource Group (create a new one if needed, e.g., RG-Security).
4. Provide a Name (e.g., LAW-CompanyName-Security).
5. Select a Region (choose one geographically close or with specific compliance needs).
6. Select the Pricing Tier: Start with Pay-as-you-go.
7. Review and Create.
Step 2: Enable Microsoft Sentinel
1. Search for “Microsoft Sentinel” in the Azure portal and select it.
2. Click “Add” or “Create”.
3. Select the Log Analytics Workspace you just created.
4. Click “Add Microsoft Sentinel”. Deployment takes a few minutes.
Step 3: Configure Data Connectors
1. Once Sentinel is deployed, navigate to your Sentinel workspace.
2. Go to Configuration -> Data connectors.
3. Find and configure the following connectors (prioritize based on your licenses):
  - Azure Active Directory: Connect Sign-in logs and Audit logs. Requires authorization. If you have Azure AD P2, also connect Azure AD Identity Protection.
  - Microsoft 365 Defender: If you have relevant Defender licenses, connect this. It streamlines alert ingestion. Requires authorization. Configure it to sync alerts. This is often the most cost-effective way to get Defender alerts.
  - Office 365: If not using the M365 Defender connector for O365 data, or if you want raw logs beyond alerts, connect this. Select Exchange and SharePoint. Requires authorization.
  - Azure Activity: Connect this. It’s straightforward and free.
4. For each connector, open its page, click “Open connector page”, and follow the specific prerequisites and configuration steps (usually involves ticking boxes and granting permissions).
Step 4: Enable Analytics Rules
1. In Sentinel, go to Configuration -> Analytics.
2. Go to the Rule templates tab.
3. Filter by Data Sources (e.g., Azure Active Directory, Office 365, Microsoft 365 Defender).
4. Look for rules tagged Microsoft Security. These are often high-quality and maintained by Microsoft.
5. Select relevant templates (e.g., “Sign-ins from IPs that attempt sign-ins to disabled accounts”, “Malware detection by Microsoft Defender Antivirus”, “Suspicious inbox manipulation rule”, “Impossible travel activity”).
6. For each chosen template, click “Create rule”.
7. Review the rule logic (you can accept defaults for MVC). Ensure it’s set to Enabled.
8. Configure Automated response later; leave it empty for MVC.
9. Create the rule. Start with 5-15 key rules covering identity, endpoint, and email threats.
Step 5: Monitor Incidents
1. Regularly (daily is recommended) check the Threat management -> Incidents blade in Sentinel.
2. Review new incidents, assign them, investigate the alerts and entities involved, and close them with appropriate classifications.

Expected Monthly Costs

This is highly variable, but let’s break it down:

Log Analytics Ingestion:
- Free Tier: Many security alerts ingested via the Microsoft 365 Defender connector and Azure Activity logs are free. Office 365 standard audit logs are also often free.
- Paid Data: The primary cost driver will be paid data sources ingested. Azure AD Sign-in logs are a common paid source. The volume depends heavily on user count and activity.
- Estimate: For a small business (e.g., 10-50 active users), ingesting only essential paid logs like Azure AD Sign-ins might result in 0.5 GB to 5 GB per month (this is a rough estimate). Some sources estimate ~1GB/month per 100 users for just sign-in logs, but activity varies hugely.
- Cost: Log Analytics Pay-As-You-Go ingestion is roughly $2.76 per GB (price varies slightly by region, check current Azure pricing).
Sentinel Analysis Cost (Pay-As-You-Go):
- Sentinel charges for analyzing the data ingested into Log Analytics. The PAYG rate is often similar to the Log Analytics ingestion rate, around $2.46 per GB (check current pricing).
- Important: Data sources that are free to ingest into Log Analytics (like M365 Defender alerts, Azure Activity) are typically also free to analyze in Sentinel. You only pay Sentinel analysis costs on the paid data ingested into Log Analytics.
Log Analytics Retention:
- The first 90 days of data retention are typically included free with Sentinel enabled.
- Storing data beyond 90 days incurs a small storage cost (e.g., ~$0.12 per GB per month). For an MVC, sticking to 90 days is recommended.

Cost Summary Estimate for MVC:

Scenario 1: Strict MVC using mostly FREE alert sources: If you rely heavily on the free ingestion from the M365 Defender connector (for endpoint/email alerts), Azure Activity, and standard Office 365 audit logs, and don’t ingest Azure AD Sign-in logs (or have very low volume), your direct Sentinel/Log Analytics costs could be very low, potentially $0 – $20 per month.
Scenario 2: MVC including Azure AD Sign-in Logs: If you add Azure AD Sign-in logs (highly recommended for security), assuming 1-5 GB/month ingestion:
- Log Analytics Ingestion: 1-5 GB * ~$2.76/GB = $2.76 – $13.80
- Sentinel Analysis: 1-5 GB * ~$2.46/GB = $2.46 – $12.30
- Total Estimated Direct Cost: Roughly $5 – $30 per month.

Crucial Caveats on Cost:

Licensing Costs: This estimate does not include the cost of Microsoft 365 licenses (e.g., Business Premium, E3, E5) or standalone Azure AD P1/P2 licenses required to generate the security signals in the first place. These are often the larger part of the overall security spend.
Data Volume Variance: Actual data volume can vary significantly based on user activity, configured logging levels, and enabled features.
Pricing Changes: Azure pricing can change. Always refer to the official Azure pricing calculator for the most current information.
Commitment Tiers: If data volume grows significantly (e.g., consistently over 100 GB/day, which is unlikely for this SMB MVC), Commitment Tiers for Sentinel and Log Analytics offer discounts but require upfront commitment.

In conclusion, a minimum viable Sentinel setup focusing on free alert ingestion and essential paid logs like Azure AD Sign-ins can be quite affordable for an SMB, likely falling in the $5 – $30 per month range for direct Azure consumption costs, plus the necessary Microsoft 365/Azure AD licensing costs. Remember that someone needs the time and basic knowledge to monitor the incidents generated.

How to manage multiple M365 tenants using inbuilt Microsoft tools

Okay, let’s break down how to effectively and securely manage multiple Microsoft 365 (M365) tenants using Microsoft’s integrated and add-on tools, especially when multiple employees need access.

The cornerstone solution for this scenario is Azure Lighthouse. It’s specifically designed for service providers (like MSPs) or enterprise IT teams managing multiple tenants.

Here’s a breakdown of the tools and strategies:

1. Azure Lighthouse (The Foundation)

What it is: Azure Lighthouse allows you to manage customer (or subsidiary) Azure and M365 resources from within your own management tenant. It uses Azure Delegated Resource Management.
How it works:
- You (the managing organization) define access roles and permissions for your employees (organized into Microsoft Entra ID groups) within your tenant.
- You create an “offer” (either a Managed Service offer in the Azure Marketplace or an ARM template deployment) that specifies these roles and the scope (subscriptions, resource groups, or entire tenant for some M365 workloads).
- The customer/managed tenant accepts this offer, delegating the defined permissions to your specified groups/users in your tenant.
Key Benefits:
- Centralized Management: Your employees log in only to your primary management tenant. They don’t need separate accounts or guest accounts in each customer tenant.
- Enhanced Security:
  - Reduces credential sprawl (fewer accounts to manage/compromise).
  - Enables consistent application of security policies (like MFA, Conditional Access) from your tenant for your employees accessing customer resources.
  - Uses least privilege principles by assigning specific Azure built-in roles with appropriate permissions.
  - Activity logs in the customer tenant clearly show actions performed by users from your managing tenant.
- Scalability: Easily onboard new customer tenants and assign permissions to your employee groups.
- Cross-Tenant Visibility: View resources and alerts across multiple delegated tenants in unified dashboards (e.g., Azure Portal, Microsoft Sentinel).

2. Key Integrated Tools Leveraged with Lighthouse:

Azure Portal (portal.azure.com):
- Directory + Subscription Filter: Your employees can easily switch context between different customer directories/subscriptions they have delegated access to.
- Azure Resource Management: Manage Azure resources (VMs, networking, storage, etc.) within delegated subscriptions.
- Microsoft Entra ID Management: Perform delegated Entra ID tasks in customer tenants (user management, group management, etc., depending on assigned roles like User Administrator, Helpdesk Administrator).
- Service Health: Monitor the health of Azure services across delegated subscriptions.
Microsoft 365 Admin Centers (Accessed via Delegation):
- While Lighthouse primarily delegates Azure roles, many M365 services are managed via Azure RBAC or have corresponding Azure AD roles that grant access.
- Your employees, using their single login, can often access customer M365 admin centers (like admin.microsoft.com, Exchange Admin Center, SharePoint Admin Center, Teams Admin Center, security.microsoft.com, compliance.microsoft.com) if they have been assigned appropriate delegated Entra ID roles (e.g., Global Reader, Exchange Administrator, Teams Administrator, Security Administrator). The context switching happens within the respective admin portals.
Microsoft Sentinel:
- Cross-Workspace Incident Viewing: If you deploy Sentinel workspaces in customer tenants, Lighthouse allows you to view and manage incidents across multiple workspaces from your managing tenant’s Sentinel instance.
- Centralized SIEM: You can configure data connectors in each managed tenant to forward logs (Entra ID, M365 Defender, etc.) to a central Sentinel workspace in your management tenant for unified threat detection and response. This often requires specific permissions or configurations within the managed tenant.
Microsoft Defender Portals (security.microsoft.com / Microsoft 365 Defender & compliance.microsoft.com / Microsoft Purview):
- Lighthouse delegation (with appropriate roles like Security Administrator/Reader, Compliance Administrator) allows your employees to access these portals for managed tenants.
- While full cross-tenant unified views within these specific portals are still evolving, delegation significantly simplifies access compared to managing separate accounts. Some multi-tenant views are emerging, particularly for MSPs using Defender for Endpoint.
Microsoft Defender for Cloud:
- Assess the security posture of Azure resources across delegated subscriptions.
- Manage security policies and recommendations centrally.

3. Essential Supporting Tools & Practices:

PowerShell (Microsoft Graph SDK, Azure Az, Exchange Online, etc.):
- Automation: Crucial for performing tasks at scale across multiple tenants (e.g., applying a standard configuration, running reports, user management).
- Authentication: Use your managing tenant credentials combined with the delegated tenant ID to connect and manage resources programmatically. Service Principals in your managing tenant can also be granted delegated permissions via Lighthouse for automated tasks. Use secure authentication methods (certificates, managed identities where applicable) instead of interactive logins or stored credentials for scripts.
Microsoft Graph API:
- The underlying API for Azure and M365. Use it directly or via SDKs (like the PowerShell SDK) for complex automation and integration scenarios across tenants. Again, authentication leverages the Lighthouse delegation.
Microsoft Entra ID Features (in your Managing Tenant):
- Security Groups: Create groups for different support tiers or roles (e.g., “Tier 1 Support”, “Exchange Admins”, “Security Analysts”). Assign Lighthouse delegated permissions to these groups, not individual users. Managing group membership is easier than managing individual permissions across many tenants.
- Conditional Access Policies: Enforce MFA, device compliance, location restrictions, etc., for your employees when they access any resources, including delegated customer tenants. This is a major security benefit.
- Privileged Identity Management (PIM): Use PIM in your managing tenant to provide just-in-time (JIT) access to the Azure AD groups that hold the delegated Lighthouse permissions. This further enhances security by ensuring elevated privileges are only active when needed and for a limited time.
- Access Reviews: Regularly review who has access to the delegated permission groups in your tenant.

4. Implementation Strategy:

Design Your Management Structure: Define roles and responsibilities for your employees. Create corresponding Microsoft Entra ID security groups in your management tenant.
Define Lighthouse Offers: Determine the necessary Azure built-in roles (e.g., Reader, Contributor, User Access Administrator, specific service admin roles) needed for each employee group. Create ARM templates or Managed Service offers for delegation.
Onboard Customer Tenants: Deploy the ARM templates to or have customers accept the Managed Service offers in their respective tenants. This establishes the delegation.
Configure Security in Your Tenant: Implement robust Conditional Access policies and PIM for the groups assigned delegated permissions.
Train Your Staff: Ensure employees understand how to use the Azure Portal directory switcher, how delegated permissions work, and the security protocols (MFA, PIM activation).
Leverage Automation: Identify repetitive tasks and automate them using PowerShell/Graph API with delegated credentials or service principals.
Utilize Centralized Monitoring: Configure Sentinel or other monitoring tools to gain cross-tenant visibility.

In Summary:

Azure Lighthouse is the core Microsoft technology enabling secure and efficient multi-tenant management. By combining it with the Azure Portal, M365 admin centers, Sentinel, Defender, PowerShell, and robust Microsoft Entra ID security features (Groups, CA, PIM) within your managing tenant, you can provide your employees with streamlined, secure access to manage multiple customer environments effectively.

PowerShell script to report EntraID signin update

One the things that I have tasked myself with is to go back through my scripts and using AI (aka Github Copilot) to improve my code.

The latest script to get this treatment is:

https://github.com/directorcia/Office365/blob/master/graph-signins-get.ps1

which now has greater flexibility and speed. I also used Copilot to produce documentation for the script which is here:

https://github.com/directorcia/Office365/wiki/Get-tenant-signins

In my Visual Studio Code editor what I did was simply to open up the script.

I then set Copilot to operate in ‘agent’ mode, as shown above. I also selected an AI model to use. I have the default choices of:

I can also configure others like Gemini if I want. This time I selected Claude 3.7 and then basically told Copilot to ‘improve’ my code. After that I asked it to provide options for using paging to get more results as well as ensuring the output was in local time.

After one update to the time format it produced an error when it ran but I simply told Copilot to fix that error and it did so. The code once again executed.

Thus, the updated script and documentation is now available via the links above and I am amazed at how easy it was to make all these changes to get the result that I wanted without having to type any additional code myself into the script! I suppose he downside is that the code is more complex and I don’t intrinsically understand it as well as if I had written every line, but I have Copilot to help explain any part of the code to me if needed and the time savings getting to a result speak for themselves.

The functionality that AI provided for me via Github Copilot is enormous and should make short work of any PowerShell automation I do in the future. If you are using PowerShell (or any code) then you really need to be looking at the benefits AI will provide you.

SharePoint Agents PAYG costs

To get a better idea of the costs of using SharePoint Agents, I’d suggest you have a look at:

https://techcommunity.microsoft.com/blog/spblog/consumption-based-pricing-for-sharepoint-agents/4389591

with the highlight being:

Under the PAYGO model, customers are billed $0.01 per message. Each interaction with a SharePoint agent uses thirty-two (32) messages, so customers are billed at $0.32 per interaction with SharePoint agents. The PAYGO meter uses your Azure subscription as the payment instrument, ensuring seamless integration with existing billing processes. This meter is available worldwide.

and

There are no in-product feature differences between the PAYGO meter, and the SharePoint agent included in the Microsoft 365 Copilot license. Users have the same capabilities and benefits, regardless of the billing model they choose.

Thus, with each interaction being $0.32, let say that typically a user will interact with SharePoint agents three times during any inquiry. That makes it about $1 per enquiry. If we now say that an average user will make 20 inquiries per day, that is $20 per user per day. Multiply that across all the users in an organisation and you can see how it could get very expensive very quickly.

Clearly then, pay as you go SharePoint agents is for very low volume of usage across the organisation, typically one enquiry per day. Otherwise, it make more sense to buy a full license of Microsoft 365 Copilot for the user in question because they effectively get unlimited SharePoint agent enquiries as well as a personal AI assistant plus more.

If you combine any other pay as go usage of Copilot, such as with Copilot Studio as I have outlined before, then it make far more sense to get a full Microsoft 365 Copilot for those who need to use any AI tools. However, pay as you go billing does provide you the flexibility to mix and match with full Microsoft 365 Copilot licenses. If you have a business with 5 major users and 20 casual users then teh starting point is for those 5 users to have full Microsoft 365 Copilot license, while the rest simply use an Azure subscription to cover any incidental costs until the point when another person in the business needs a full license.

To keep control of any SharePoint or Copilot pay as you go, you shoudl always set up a budget in Azure as I have outlined before with Security Copilot

Pay as you SharePoint agents do provide a degree of flexibility of quickly and easily enabling AI across your SharePoint information for your whole organisation but if usage of AI starts to grow then so too will the costs, and potentially quite dramatically if appropriate limits are not configured. The best option with pay as you go SharePoint agents then is its use in combination with full Microsoft 365 Copilot licenses for users who need to use AI extensively in their jobs, while casual users can remain on the pay as you go option. The good news is that you do have the flexibility to mix and match with the two types of licenses as needed and Azure does give you the added benefit of being able to turn off immediately where Microsoft 365 Copilot licenses are typically an annual commitment.

Copilot Studio PAYG costs

Now that I have set up pay as you go (PAYG) Copilot Studio via an Azure subscription, the next big question is what are the costs likely to be? These are somewhat hard to quantify exactly because it ‘depends’ on a lot of factors.

Start with:

Copilot Studio licensing here:

https://learn.microsoft.com/en-us/microsoft-copilot-studio/billing-licensing

which says:

Pay-as-you-go: $0.01 per message

but then it isn’t a simple ratio of 1 question = 1 message, oh no. You need to look at this:

Message scenarios

which gives you this table:

The example Microsoft provides is:

Diagram illustrating various Copilot Studio events and their corresponding billing events.

Each interaction with an agent might utilize multiple message types simultaneously. For example, an agent grounded in a tenant Microsoft Graph could use 32 messages (30 messages for the Microsoft Graph grounding, and two for generative answers) to respond to a single complex prompt from a user.

Agent costs depend on an agent’s complexity and its usage.

Inside the Power Platform admin center, under licensing and Copilot Studio I see this:

if I drill into this a little more I find:

Ok, so 2,040 messages is the usage.

I then waited and checked my Azure billing for the period and it reports:

which is AU$20.30 for Copilot Studio usage across those 2,040 messages I suggest. If you divide the cost by the messages you come out to around that suggested $0.01 per message as expected.

How does that relate to usage? Again, hard to exactly quantify as I was the only user and I was building and testing an autonomous agent with Copilot Studio for around 8 hours roughly. Thus, that means an average of 255 AI message per hour or 4.25 messages per minute.

Based on that, the best estimate (rule of thumb) I could give you would be, based on ‘average use’ across a typical day (8 hours), for a single user using Copilot regularly throughout the day the cost is going you around AU$20 per user for that 8 hours of sustained usage.

I fully appreciate this is nowhere near exact but, so far it is the best average I can come up with for sustained daily usage.

If we assume that a ‘normal’ user is not going to using AI in the sustained manner across the whole day we could then apply say a 50% usage discount and settle on around AU$10 per user per day for an ‘average’ user using Copilot resources in an ‘average’ way per day. More intensive usage would be considered around AU$20 per user per day I suggest.

In summary then, via my imperfect observations and calculations I would suggest to you that if you do indeed implement Copilot service via Pay As You Go (PAYG) then the ‘typical’ costs you can expect would be around AU$10 per user per day up to AU$20 per user per day. If this was sustained across a full month then you would be looking at $300 per average user per month which is way above the cost of a full license of Microsoft 365 Copilot whih which would be a flat fee of around AU$45 per user per month.

This is the best estimate I can give you and your costs and usage will vary but I think $10 per user per day for average Copilot use on a PAYG plan is as good as any place to start.

Clearly then, if your users are planning on sustained Microsoft 365 Copilot usage a paid license of Microsoft 365 Copilot is a much more effective investment from what I can determine.

Need to Know podcast–Episode 341

In this episode I provide the benefits that become available once you add and Azure subscription to your Microsoft environment. From pay as you go options with Copilot and SharePoint all the way through adding more security to your environment, Azure contain a range of features that you should consider. I’ll also bring you up to date with all the latest news from the Microsoft Cloud, so listen along and enjoy.

Brought to you by www.ciaopspatron.com

you can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-341-why-add-azure/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

or Spotify:

https://open.spotify.com/show/7ejj00cOuw8977GnnE2lPb

Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show.

Resources

@directorcia

Join my shared channel

CIAOPS merch store