FAQ

Microsoft Entra ID (formerly Azure AD) is a cloud-based identity provider for applications, devices, and services. It does not replace on-prem Active Directory (AD DS) one-to-one, but complements or replaces it depending on the scenario: Microsoft Entra ID is central for SaaS/cloud apps, SSO, and Conditional Access; AD DS or alternative mechanisms remain relevant for Kerberos/LDAP/GPO. In modern target architectures, Microsoft Entra ID is used as the primary identity layer, while AD DS remains in operation for legacy workloads or transition phases.

Common challenges include inconsistent UPNs/SMTP addresses, duplicate/orphaned objects, non-standard OU and group structures, and an unclear source of authority. Also technically relevant are Microsoft Entra Connect / Microsoft Entra Cloud Sync design, password hash sync vs. pass-through authentication, device states (Microsoft Entra hybrid join, formerly Hybrid Azure AD Join), and clean lifecycle management (joiner/mover/leaver).

A proven approach is phased policy design: first a baseline (MFA for admins, block legacy auth), then risk-based policies (sign-in/user risk), followed by app- and group-specific rules. Break-glass accounts, minimal exclusions, consistent logging, and a report-only rollout with clear change windows are essential.

MFA adds factors, but is not automatically phishing-resistant (e.g., push-based MFA). Passwordless methods (FIDO2, Windows Hello for Business, passkeys) reduce dependency on passwords. Phishing-resistant MFA requires methods that are robust against token relay and prompt bombing (FIDO2, certificate-based methods, WHfB).

PIM enables just-in-time admin rights, time-limited and with approval/justification. This reduces standing privileges, improves auditability, and supports segregation of duties. Clean role models, emergency procedures, and integration into incident response are critical.

Zero Trust is operationalized across identity, devices, apps, and data: strong identities (CA, PIM), managed devices (Intune compliance), app protection (Defender, app governance), data controls (Purview DLP/labels), and continuous monitoring (Sentinel/Defender XDR). A pragmatic approach prioritizes the biggest risks (admin accounts, email, exfiltration) instead of a big-bang rollout.

Core building blocks are: disabling legacy auth, consistent MFA/CA, clean SPF/DKIM/DMARC, Defender for Office 365 policies (anti-phish, Safe Links/Attachments), restrictive Exchange Online transport rules, and a clear process for allow/block lists and false positives.

Defender for Endpoint protects endpoints (EDR, vulnerability management), Defender for Office 365 focuses on email/collaboration threats, and Defender XDR correlates signals across workloads (identity, endpoint, Office, cloud apps) for consolidated incidents and response.

Sentinel is worthwhile when you want to centrally correlate log sources, automate use cases (SOAR), and leverage cloud scalability. Typical drivers are increasing compliance requirements, heterogeneous security tools, and the need for faster incident response. A cost/ingestion design (data tiers, filters, sampling) and a prioritized use-case backlog are essential.

First define security and operational use cases, then select the minimum required data sources. Typical examples: Entra sign-in/audit, Defender, Azure Activity, Key Vault, Storage, Firewall, and workload logs. Use retention/archive, basic logs/data tiers, and avoid “log everything” without analysis. Cost control is implemented through DCRs, filters, and clear retention rules.

A landing zone is a standardized foundation (management groups, subscriptions, networking, policies, identity, logging). It reduces sprawl, accelerates rollouts, and makes governance easier. Typical mistakes are premature over-complexity or missing guardrails (naming, RBAC, policies).

A proven pattern is hub-spoke with centralized shared services (firewall, VPN/ER, DNS). Private endpoints reduce public exposure, but require clean DNS zones (privatelink.*) and routing. Common problems arise from split-horizon DNS, unclear UDRs, and missing egress controls.

Use RBAC/access policies consistently, disable public network access where possible, and use private endpoints, key rotation, and separate vaults per environment. For apps, use managed identities instead of secrets, and implement logging/alerts for secret reads and key operations.

Azure Policy enforces or audits configurations (guardrails). Blueprints were historically used for packaging; in many target architectures, policy initiatives, Terraform/Bicep, and landing-zone frameworks are preferred. The key distinction is: Policy for compliance enforcement, IaC for provisioning.

Intune is a good fit when you want to centralize modern device management (Windows, macOS, iOS, Android), tie compliance to Conditional Access, and use zero-touch provisioning (Autopilot). Challenges include app packaging, replacing legacy GPOs, and a clean role/scope design.

Typical issues include incorrect device states (hybrid join timing), unclear assignment of profiles/apps, driver/BIOS dependencies, and overly heavy ESP phases. Remedies: a lean baseline, phased app rollouts, clear device groups, and a test-ring model.

Start with a controls mapping (security baseline, hardening), identify GPOs without an MDM equivalent, and define replacements (scripts, CSP, ADMX ingest). Roll out via pilot rings, with a coexistence phase (GPO/MDM), conflict rules, and measurable compliance KPIs.

Azure Virtual Desktop (AVD) offers flexible, scalable multi-session host pools and fits well for variable workloads or specialized applications. Windows 365 is more SaaS-like, with predictable SKUs and simpler operations. Decision criteria include cost profile, operating model, application compatibility, network latency, and security (Conditional Access, MFA, Defender).

Define policies for team creation (self-service with templates), naming conventions, expiration/recertification, guest access, and external federation. Also important: sensitivity labels, DLP, and clear responsibilities (owner duties). Without governance, data sprawl and shadow IT emerge quickly.

Usually, an information architecture concept is missing: site structure, permission model, naming scheme, retention, and archiving. Technically problematic are too many individual permissions, missing sensitivity labels, and unclear rules for external sharing.

Start with a simple classification model (public/internal/confidential), use sensitivity labels including encryption, and define DLP policies for core channels (Exchange, SharePoint/OneDrive, Teams). Roll out in audit mode first, then enforce step by step. Important: model exceptions/business flows cleanly, otherwise adoption drops.

First clarify regulatory retention periods, then implement Purview retention labels/policies and hold processes. eDiscovery requires roles, case workflows, and documented export chains. Clear scope definitions and coordination with backup/archive are critical.

Azure SQL (PaaS) offers the highest level of operational abstraction and scaling, ideal for modern apps. Managed Instance is close to SQL Server compatibility (e.g., Agent, cross-database scenarios) and suits lift-and-shift with less refactoring. SQL on VM is IaaS—maximally flexible, but with full operational overhead (patching, HA, backup).

AKS makes sense for containerized microservices, scaling requirements, and GitOps/IaC. Failures often happen due to missing platform standards (ingress, observability, secrets, RBAC), unclear responsibilities (“you build it, you run it”), and weak cost/capacity management. Start with a reference platform and clear guardrails.

Azure Arc extends Azure governance, policies, inventory, and in some cases services to on-prem/edge and other clouds. It creates value when you need consistent management, compliance, and automation across heterogeneous environments. Success factors are clean tagging/resource models and a clear operating target model.

Consistency is crucial: one toolset, modular patterns, code reviews, environments, and a release process. Bicep integrates tightly with ARM; Terraform offers broad provider ecosystems. GitOps complements Kubernetes. The decisive factor is not the tool itself, but standards (naming, tags), secrets handling, and drift control.

The biggest risks are data exposure (overly open SharePoint/Teams permissions), missing classification/labels, and unclear usage rules. Technically, you need identity/CA, Purview controls, logging, and an enablement program (use cases, prompt guidelines, governance).

Run regular access reviews, reduce the number of global admins, use PIM, and implement role-based groups instead of individual permissions. In SharePoint/Teams, sensitivity labels, standardized site templates, and owner recertification help.

Plan in phases: identity/domain preparation, mail (Exchange), collaboration (Teams/SharePoint/OneDrive), devices (Intune), and security/compliance. Coexistence, cutover windows, data integrity, and user communication are critical. Technically, redirects, client reprofiling, and permission migration must be thoroughly tested.

Microsoft 365 offers high availability, but it does not replace a business-aligned backup concept. Define RPO/RTO, evaluate native options (retention, eDiscovery, versioning), and—depending on risk—add third-party backup for Exchange/SharePoint/OneDrive/Teams. Restore tests and clear responsibilities are essential.

Start with requirements (security/compliance use cases) rather than feature lists. E5 is often worthwhile if XDR/SIEM/DLP/Insider Risk is actually used—otherwise E3 + add-ons may be more economical. A gap analysis is key: existing tools vs. Microsoft stack, operational effort, and integration costs.

Collect incidents/findings, map them to MITRE techniques, and prioritize by risk, feasibility, and data availability. Start with high-signal use cases (admin abuse, impossible travel, endpoint malware, phishing) and automate response steps in Sentinel/Defender. Measure success via detection coverage and mean time to respond.