Guest Accounts vs External Accounts in Microsoft Entra ID

Summary Table

Detailed Differences

Conceptual Explanation

All guest accounts are external, but not all external users are guests.
A guest account is like giving someone a visitor badge to your office—they exist in your directory, but aren’t fully internal.
An external account might never show up in your directory at all if they’re only accessing through cross-tenant trust or identity federation.

Examples

• Guest (B2B): You add alex@gmail.com as a guest to your tenant to access a shared Power BI dashboard. They appear in your directory as alex_gmail.com#EXT#@yourcompany.onmicrosoft.com.
• External (Federated): Your company has a federation with partnercorp.com. When jane@partnercorp.com logs into your app, she authenticates through her own company’s Entra ID, without being added as a guest.

The post Guest Accounts vs External Accounts in Microsoft Entra ID appeared first on Azure Security Architect.

When granting external vendors access to your corporate Azure environment, it’s important to understand the key differences between using Azure AD Guest Accounts and Corporate Accounts (with SSO). Each approach has implications on security, user experience, compliance, and manageability.

1. Azure AD Guest Accounts (B2B Collaboration)

Example Email Address: jane.vendor_corp.com#EXT#@yourcompany.onmicrosoft.com
(This format shows a guest from another domain, such as jane@vendor-corp.com, invited into your tenant.)

Key Features:

• Created through invitation: You invite a user by email; they receive a redemption link to access your tenant.
• Authentication is external: They sign in using their own organization’s identity provider (or Microsoft account).
• Lives in your Azure AD: A shadow account is created in your tenant to manage access.
• Can be governed: Azure AD Conditional Access policies, MFA enforcement, and access reviews can be applied.
• Supports RBAC: Guests can be assigned roles (e.g., Reader, Contributor) in Azure Portal.

Pros:

• No need to manage credentials.
• Centralized governance via Azure AD B2B.
• Scales well for short-term or multiple vendors.

Cons:

• Slightly fragmented UX; user is redirected across tenants.
• May be blocked by vendor-side tenant policies.
• Auditing may be complex if user has multiple guest invitations.

2. Corporate Accounts with SSO (Federated Identity or Internal Accounts)

Example Email Address: john.doe@yourcompany.com
(This format represents an internal or federated corporate identity managed by your organization.)

Key Features:

• SSO Integration: The user’s identity is federated or natively authenticated via your IdP.
• Supports seamless experience: Especially when vendor users already use a federated system.
• Internal accounts are treated as first-class users: Subject to all native policies.

Pros:

• Better user experience with SSO.
• Full policy enforcement as for internal employees.
• Improved auditing, logging, and compliance tracking.

Cons:

• Requires deeper setup (e.g., federation configuration).
• Needs account lifecycle management (provisioning/de-provisioning).
• Higher management overhead for short-term vendors.

3. Security and Governance Comparison

4. Best Practices

• Use guest accounts for short-term or multi-vendor collaboration.
• Use corporate accounts with SSO for long-term partners, high-privilege roles, or regulated workloads.
• Always enforce MFA and Conditional Access.
• Automate lifecycle via Access Packages or Entitlement Management (Azure AD Identity Governance).

Conclusion

Both guest accounts and corporate accounts have their place in a secure Azure ecosystem. The choice should be guided by your organization’s compliance posture, duration of vendor engagement, and administrative capabilities. Using the right model for the right use case enhances productivity without compromising security.

Tip: For high-risk roles or access to sensitive data, prefer corporate accounts with full identity lifecycle control.

Author: Anuj Varma, Tech Consultant

Tags: Azure B2B, Guest Access, Identity Management, Vendor Security, Azure AD, SSO

The post Guest Accounts vs Corporate Accounts for Vendor Access in Azure Portal appeared first on Azure Security Architect.

Moving a Virtual Network (VNet) from one Azure subscription to another is a common requirement during subscription restructuring, consolidations, or billing changes. Thankfully, Azure provides a built-in service to facilitate this: Azure Resource Mover.

Use Azure Resource Mover

Azure Resource Mover enables you to move supported resources — including VNets — between regions or subscriptions.

Pre-Move Checklist:

• Unpeer the VNet: If your VNet is peered with other VNets, you must delete all peering connections before the move. Peering links are not transferable across subscriptions.
• Check dependencies: Ensure dependent resources (e.g., VMs, NICs, NSGs, route tables) are either moved along with the VNet or detached beforehand.
• Permissions: You need appropriate permissions (Owner or Contributor) in both the source and target subscriptions.

Steps to Move a VNet:

1. Navigate to Azure Resource Mover in the portal.
2. Select your source subscription and region.
3. Choose the VNet you want to move.
4. Review dependencies and select additional resources to include in the move.
5. Choose the target subscription and resource group.
6. Initiate the move by selecting “Start Move”.

Post-Move Considerations:

• Recreate VNet peering in the new subscription if needed.
• Update references in other resources (e.g., firewalls, service endpoints).
• Double-check NSGs and route tables for any issues post-migration.

Pro Tip:

Always test the move in a non-production environment first, especially if your VNet is part of a complex topology. Azure will perform a validation check, but manual review is wise.

The post How to Move an Azure VNet Between Subscriptions appeared first on Azure Security Architect.

When public access to a SQL Managed Instance is disabled but no Private Endpoint is configured, the DNS name still resolves — but to a private IP address (e.g., 10.0.10.210) within the VNET.

Pre-requisites for Connectivity

1. VPN or ExpressRoute Connection
   You must have a secure connection (VPN or ExpressRoute) into the same Azure VNET hosting the SQL MI.
2. DNS Resolution
   The DNS query for <yourservername>.database.windows.net should resolve to the private IP address of the SQL MI.
3. Correct Routing
   Your system or router must route traffic destined for the SQL MI’s private IP over the VPN/ExpressRoute.
4. Firewall and NSG Rules
   No network-level security rules (e.g., NSGs or firewalls) should block the traffic on required ports (especially port 1433).

Step-by-Step Troubleshooting

1. Verify DNS Resolution

From a Windows command prompt, run:

nslookup <yourservername>.database.windows.net

• If it resolves to a private IP, that’s correct.
• If it resolves to a public IP or fails, your DNS isn’t set up to resolve Azure private DNS zones.

2. Check DNS Configuration

If DNS is not resolving correctly:

• Determine what your client is using for DNS: local router, on-prem DNS server, or custom DNS.
• Configure Azure DNS forwarding for the database.windows.net zone:
  • Optionally, deploy an Azure Private DNS Resolver (note: this is a billable resource).
  • Set up conditional forwarding on your DNS server to forward *.database.windows.net queries to the Azure DNS Resolver.
  • Ensure your DHCP or static IP settings point clients to this DNS server.

3. Validate Routing

Make sure your network setup forwards traffic to the SQL MI private IP range over the VPN:

• Check your route tables (on-prem and in Azure).
• Confirm split-tunneling or forced tunneling rules support traffic to the SQL MI subnet.

4. Inspect NSGs and Firewall Rules

Each SQL Managed Instance creates its own subnet and often has an associated Network Security Group (NSG). Check the NSG:

• Allow inbound TCP port 1433 from your VPN or on-prem subnet.
• Ensure no deny rules are blocking traffic.

Refer to official guidance for required NSG configurations:
Azure SQL MI Connectivity Architecture

 Summary Checklist

The post Azure SQL Private Link Connectivity appeared first on Azure Security Architect.

Deploying Fortinet HA on Azure: Standard vs. Gateway Load Balancers Explained

Fortinet’s suite of security solutions — including FortiGate, FortiWeb, and FortiMail — is widely used to secure cloud environments. In Microsoft Azure, deploying Fortinet appliances in high availability (HA) mode requires careful planning, particularly in how traffic is distributed to these appliances.

One of the most critical architectural choices you’ll make is selecting the right Azure load balancer. Azure offers two primary options:

• The Standard Load Balancer
• The Azure Gateway Load Balancer

Both can support Fortinet HA deployments — but they serve distinct purposes. In this post, we’ll explain how each one works, when to use them, and provide practical examples for your Fortinet deployments on Azure.

Standard Load Balancer

The Standard Load Balancer is a general-purpose load balancer that operates at Layer 4 of the OSI model (transport layer). According to Microsoft’s documentation, this load balancer is designed to handle a wide range of workloads, including network virtual appliances (NVAs) like Fortinet appliances.

How It Works

• Distributes incoming TCP/UDP traffic across a backend pool of virtual machines.
• Supports both inbound and outbound scenarios.
• Integrated with Azure HA configurations.
• Works well with FortiWeb, FortiGate, FortiMail, and other Fortinet products.

When to Use It

Use the Standard Load Balancer when you need general HA and load balancing across Fortinet appliances such as:

• FortiWeb for web application firewall (WAF) protection.
• FortiMail for secure email gateway deployments.
• FortiGate VMs that do not require service chaining.

Example Scenario

If you deploy two FortiWeb VMs to protect a public-facing website, you can use a Standard Load Balancer to distribute incoming traffic evenly across both VMs while maintaining session persistence and failover.

Azure Gateway Load Balancer

The Azure Gateway Load Balancer is a more specialized load balancer, designed specifically for use cases involving service chaining with NVAs like FortiGate.

How It Works

• Operates transparently by inserting the FortiGate (or any NVA) into the traffic path.
• Uses VXLAN encapsulation to pass traffic between Azure’s Gateway Load Balancer and the FortiGate VM.
• Enables traffic inspection, modification, and advanced security without requiring application changes.
• Simplifies management of FortiGate VM as a service point in your Azure network.

When to Use It

Use Azure Gateway Load Balancer when you want to place FortiGate in the path of traffic flowing between:

• On-premises and Azure.
• Azure virtual networks.
• Azure public endpoints and backend resources.

This is ideal for east-west and north-south traffic inspection scenarios.

Example Scenario

If you want to deploy a FortiGate VM as a firewall for traffic entering or leaving your Azure network, you should use the Azure Gateway Load Balancer. It allows you to seamlessly insert FortiGate into the service chain and inspect all traffic at scale.

Summary: When to Use Which?

Architecture Diagram

Final Thoughts

Both Standard Load Balancer and Azure Gateway Load Balancer play critical roles in designing scalable, secure Azure environments with Fortinet.

• The Standard Load Balancer offers simplicity and broad flexibility across Fortinet products.
• The Azure Gateway Load Balancer enables deep traffic inspection and seamless service chaining with FortiGate.

Choosing the right one depends on your architecture and security goals. For complex environments where FortiGate needs to be transparently inserted into the traffic path, the Gateway Load Balancer is your best friend. For traditional HA scenarios with multiple Fortinet VMs, the Standard Load Balancer will likely meet your needs.

The post HA Firewall Appliances on Azure appeared first on Azure Security Architect.

Building an Azure Landing Zone in an Existing Hub-and-Spoke Architecture

As organizations scale their cloud infrastructure, a landing zone becomes a foundational construct for deploying workloads in a governed, secure, and scalable way.
But what happens when you already have an existing hub-and-spoke network topology in Azure?

Good news: you don’t need to redesign everything. You can integrate new landing zones into your current setup by adding new spokes and connecting them to the existing hub.

Quick Recap: What Is a Hub-and-Spoke Network?

The hub-and-spoke topology is a well-architected model where:

• The hub is a central VNet that hosts shared services (firewalls, DNS, VPNs, Azure Bastion, etc.).
• Spokes are VNets that host workloads or landing zones and connect to the hub using VNet peering.

Scenario: Adding a New Landing Zone

Let’s say your organization wants to provision a new environment (for example, for a new business unit or application workload) within your existing network.

Instead of creating a new isolated network, you’ll create a new spoke VNet and peer it with the existing hub.

Step-by-Step: Integrate a Landing Zone into the Hub-and-Spoke Model

1. Create a New Subscription or Use an Existing One

Landing zones are often deployed in separate subscriptions to isolate workloads, apply policies, and manage billing more effectively.

Tip: Use Management Groups and Azure Policy to apply guardrails at scale.

2. Create a Resource Group for the Landing Zone

az group create --name rg-landingzone-prod --location eastus

3. Provision the Spoke Virtual Network

az network vnet create \
  --resource-group rg-landingzone-prod \
  --name vnet-spoke-prod \
  --address-prefix 10.20.0.0/16 \
  --subnet-name snet-app \
  --subnet-prefix 10.20.1.0/24

4. Peer the New Spoke VNet to the Existing Hub VNet

Assuming your hub VNet is in a separate subscription, you’ll need to:

• Enable VNet peering from spoke to hub
• Then from hub to spoke

From Spoke to Hub:

az network vnet peering create \
  --name spoke-to-hub \
  --resource-group rg-landingzone-prod \
  --vnet-name vnet-spoke-prod \
  --remote-vnet /subscriptions/<hub-subscription-id>/resourceGroups/<hub-rg>/providers/Microsoft.Network/virtualNetworks/<hub-vnet-name> \
  --allow-vnet-access

From Hub to Spoke:

az network vnet peering create \
  --name hub-to-spoke \
  --resource-group <hub-rg> \
  --vnet-name <hub-vnet-name> \
  --remote-vnet /subscriptions/<landing-zone-subscription-id>/resourceGroups/rg-landingzone-prod/providers/Microsoft.Network/virtualNetworks/vnet-spoke-prod \
  --allow-vnet-access

5. Configure Route Propagation and Security

• Use User Defined Routes (UDRs) if necessary to route traffic through a firewall in the hub.
• Ensure Network Security Groups (NSGs) in the spoke allow required traffic.
• Integrate with Azure Firewall, Route Server, or NVAs for advanced scenarios.

6. Apply Policies and Blueprints

• Use Azure Policy to enforce rules (e.g., region restrictions, tag enforcement).
• Deploy Azure Blueprints or Bicep/Terraform templates for standardized environments.

Optional: Integrate with Shared Services

Once peered, the new landing zone (spoke) can access services in the hub:

• Private DNS zones
• Azure Bastion
• Firewalls and NVAs
• On-prem connectivity via ExpressRoute or VPN

Summary

Expanding an existing hub-and-spoke network to include new landing zones is not only possible — it’s the recommended approach to scale securely and efficiently.
By peering new VNets (spokes) to the hub, you retain centralized governance and shared services while giving teams autonomy within their landing zones.

Looking Ahead

For enterprise-scale deployments, consider automating with:

• Terraform or Bicep
• Azure Landing Zone Accelerator
• Azure DevOps Pipelines or GitHub Actions

Have questions or want a visual walkthrough of this architecture? Drop a comment or connect — happy to help!

The post Building an Azure Landing Zone in an Existing Hub-and-Spoke Architecture appeared first on Azure Security Architect.

In Azure, a DMZ (Demilitarized Zone) can be implemented using both a public subnet and a private subnet within a virtual network (VNet). This design allows segmentation of public-facing resources from internal components that require tighter security.

DMZ Subnet Responsibilities

• Public Subnet: Application Gateway, Azure Firewall DNAT targets, or public web servers accessible via public IP.
• Private Subnet: Backend services such as API servers or inspection appliances that should not be internet-facing.

Traffic Flow

1. User sends a request to the public IP (e.g., Application Gateway) in the Public Subnet.
2. Application Gateway routes traffic to VMs or services in the Private Subnet.
3. Backend services in the Private Subnet may query internal services (e.g., databases) in a separate internal subnet or VNet.

NSG Rules (Azure Network Security Groups)

1. DMZ Public Subnet → DMZ Private Subnet

2. DMZ Private Subnet → Internal Subnet (Separate VNet or Subnet)

Azure Firewall Rules (if using Azure Firewall)

If using Azure Firewall between DMZ and internal networks, rules would be configured in the Firewall Policy:

• Allow DNAT or Application rules from public IP to internal web service
• Allow network rules from Private Subnet IPs to DB or APIs in Internal Subnet
• Deny all other traffic not explicitly allowed

Best Practices

• Use NSGs to restrict traffic at the subnet or NIC level
• Inspect east-west traffic using Azure Firewall or NVA appliances
• Enable logging with NSG Flow Logs and Azure Monitor
• Use Azure Private Link to access PaaS services securely from Private Subnet

The post Azure DMZ Architecture appeared first on Azure Security Architect.

Setting up an ExpressRoute connection is just the beginning. To ensure high availability, performance, and fast incident response, configuring comprehensive monitoring and alerting is critical.

Types of Alerts: Circuit-Level vs. Gateway-Level

Azure Monitor supports alerts at both the ExpressRoute circuit level and the gateway level.

Circuit-Level Alerts

These focus on peering and protocol availability:

• ARP Availability Down: Alerts when Address Resolution Protocol traffic drops below 100% for a peering type.

• BGP Availability Down: Triggers when BGP peering sessions go inactive.

Use dimensions like Peering Type and Peer when defining these metrics to get precise and actionable data.

Gateway-Level Alerts

Set up alerts for ExpressRoute gateway connections to monitor overall connection health. To create one:

1. Navigate to Azure Monitor > Alerts > + Create Alert Rule.

2. Select the ExpressRoute Gateway as the resource.

3. Choose the signal type (metrics, activity logs, or resource health).

4. Set conditions, thresholds, and actions.

5. Assign an action group (email, webhook, ITSM, etc.).

:::image type=”content” source=”./media/expressroute-monitoring-metrics-alerts/signal.png” alt-text=”Azure Monitor signal selection for ExpressRoute”:::

Alerts by Peering Dimension

Azure lets you create alert rules scoped by peering or individual peers, so you can zero in on specific routes or VNETs for diagnostics.

:::image type=”content” source=”./media/expressroute-monitoring-metrics-alerts/alerts-peering-dimensions.png” alt-text=”Alert scoped by peering dimension”:::

Monitoring with Logs

• Activity Logs: Capture control plane events like route changes and BGP resets.

• Resource Logs: Set diagnostic settings to collect route metrics and session status.

• NSG Flow Logs: Useful for diagnosing network-level anomalies.

• Route Diagnostic Logs: Inspect BGP route advertisements and withdrawals.

Troubleshooting Tips

If ICMP works (ping) but no app-level connectivity (SSH, RDP, SQL), check:

• GatewaySubnet settings: No NSG or NAT gateway should be attached.

• Route Table (UDR): Set to None for GatewaySubnet.

• Connection state: Look for aged-out TCP sessions vs. proper FIN/CLOSE events.

The post Azure ExpressRoute Troubleshooting and Alerts appeared first on Azure Security Architect.

The post Azure Monitor Baseline Alerts for AVDs appeared first on Azure Security Architect.

Enable Azure Insights to capture RTT for the AVD Spin Up as well as RTT for the networking

VM LEvel

At the NIC level, Enable VM Accelerated Networking if the VM Type (and OS) supports it

FW LEvel

Ensure that Deep Packet Filtering is not causing the latency

Ensure that  the outbound route to the internet is not causing the latency (if it is via a PA FW for example)

The post AVD Latency Issues Troubleshooting appeared first on Azure Security Architect.