Skip to content

Azure Tenant Configuration¶

Creating the Azure tenant is about locking down the “root” access, and ensuring you can’t get locked out. Treat this like a controlled change with clear validations and artifacts.

Phase 0 - Create the tenant and secure the "keys"

Phase 1 - Identity, domains, and access posture

Phase 2 - Management Groups, policy, and subscription vending

Phase 3 - Connectivity, logging, and operational readiness

Phase 0 - Create the tenant and secure the "keys¶

Objectives and success criteria¶

  • Tenant created: New Microsoft Entra ID tenant with correct country/region and initial domain.
  • Root secured: Creator GA account protected with strong MFA and recovery methods.
  • Break‑glass ready: Two cloud‑only Global Administrator accounts created, tested, and excluded from controls.
  • Minimal protections on: Security Defaults enabled (or equivalent baseline) to enforce MFA and block legacy auth.
  • Identifiers captured: Tenant ID, initial domain, admin UPNs, billing identifiers stored in a secure vault.

Prerequisites and Decision Points¶

  • Agreement type: Know your billing agreement (EA/MCA/CSP) and who can create subscriptions later.
  • Geography choice: Pick the tenant country/region aligned to data residency; it’s immutable.
  • Naming: Decide initial domain pattern (short, neutral) and admin account naming conventions.
  • Secrets storage: Confirm where credentials and identifiers will be stored (e.g., enterprise password manager, Key Vault).

Run-book¶

1. Create the tenant

  • Portal path: Azure Portal → Microsoft Entra ID → Manage tenants → Create → Microsoft Entra ID.
  • Inputs:
    • Organization name: Human‑readable name (can be changed later).
    • Initial domain: yourchoice.onmicrosoft.com (permanent; pick short, neutral).
    • Country/region: Correct residency choice (e.g., Denmark/EU).

Verify

Tenant appears in your tenant list; note the Tenant ID (GUID) and initial domain.

2. Secure the creator global administrator

  • MFA: Enable MFA immediately; register at least two methods.
  • Hardware keys: Add at least one FIDO2 key; store a spare securely.
  • Password hygiene: Use a long, unique password; store in the approved vault.

Operational

Do not use this account for daily tasks; reserve it for emergencies and tenant‑level changes only.

3. Create two break‑glass accounts

  • Account properties:
    • Cloud‑only users: Not synchronized from any identity source.
    • Naming: bg-admin-01@onmicrosoft.com, bg-admin-02@onmicrosoft.com.
    • Password: Long, unique; stored in vault with restricted access.
  • Assign role:
    • Global Administrator: Grant GA to both break‑glass accounts.
  • Exclusions:
    • Conditional Access: Exclude both accounts from all CA policies.
    • Security alerts: Add notes/tags marking them “Emergency Access.”
  • MFA stance: Either exclude from MFA (traditional break‑glass) or, if organizational policy requires, enable MFA using hardware tokens stored offline.

Test

Log in through a clean browser/session for each account to confirm access.

4. Enable minimal protections

  • Security Defaults (recommended for Day 0):
    • Enable: Enforces MFA and blocks legacy authentication without building custom CA policies yet.
    • Confirm exclusions: Break‑glass accounts must remain usable; validate they can sign in even with defaults.

5. Record and vault critical identifiers

  • Identifiers:
    • Tenant ID: GUID.
    • Initial domain: onmicrosoft.com address.
    • Admin UPNs: Creator GA and both break‑glass accounts.
    • Billing scope IDs: If known (billing account, profile, invoice section).

Storage: - Vault: Store in the enterprise password manager or secured repository with strict access control. - Access list: Limit to platform leads; audit access and changes.

Phase 1 - Identity, domains, and access posture¶

Objectives and Success Criteria¶

Objectives

  • Establish a branded identity (grinntec.net) for all users.
  • Define a consistent user and admin account model.
  • Enforce baseline security (MFA, block legacy auth).
  • Implement least‑privilege and just‑in‑time access for admins.
  • Ensure auditability of sign‑ins and directory changes.

Success Criteria

  • Users can sign in with @grinntec.net UPNs.
  • All non‑break‑glass accounts require MFA.
  • Legacy authentication protocols are blocked.
  • Global Admins and other privileged roles are elevated via PIM, not standing assignments.
  • Break‑glass accounts remain usable and excluded from CA.
  • Sign‑in and audit logs are visible and retained.

Prerequisites and Decision Points¶

  • Custom domain ownership: Access to DNS for grinntec.net.
  • Licensing: Entra ID P1/P2 if you want Conditional Access and PIM; otherwise Security Defaults.
  • Naming conventions: Decide on UPN/email format (firstname.lastname@grinntec.net) and admin suffix (-admin).
  • Role model: Define which roles are needed (Global Admin, User Admin, Security Admin, Billing Admin).
  • Secrets storage: Vault for admin credentials and identifiers.

Run-book¶

1. Add and Verify Custom Domain

  • Entra admin center → Domain Name
  • Enter grinntec.net.
  • Add TXT record to DNS host.
  • Verify domain.
  • Keep .onmicrosoft.com domain as fallback.

3. Conditional Access Baseline (if licensed)

  • Create baseline CA policies:
    • Require MFA for all users.
    • Block legacy authentication.
    • Require compliant/hybrid‑joined devices for admin roles.
  • Exclude break‑glass accounts.
  • Test in report‑only mode before enforcing.

4. Privileged Identity Management (if licensed)

  • Enable PIM for Entra roles.
  • Configure:
  • No standing Global Admins (except break‑glass).
  • Require MFA and approval for elevation.
  • Limit elevation duration (e.g., 1–4 hours).
  • Assign roles to groups, not individuals.

5. Role Segmentation - Create Entra groups for each role (GA-Admins, User-Admins, SecOps). - Assign directory roles to groups. - Add admin accounts to groups. - Document role assignment model.

6. Security Defaults (if no P1/P2) - If PIM/CA not available, enable Security Defaults. - Verify MFA enforcement and legacy auth block. - Confirm break‑glass accounts excluded.

7. Audit and Monitoring - Confirm sign‑in logs and audit logs are active. - Validate retention (default 30 days). - Plan export to Log Analytics/SIEM in Phase 3.

✅ Validation Tests and Gates¶

  • Domain: Users can sign in with @grinntec.net.
  • MFA: Normal users prompted for MFA; break‑glass excluded.
  • Legacy auth: Attempt POP/IMAP sign‑in fails.
  • PIM: Admin must request elevation; GA role not standing.
  • Role groups: Admin accounts inherit roles via groups.
  • Logs: Sign‑in and audit events visible in portal.

📂 Artifacts to Capture¶

  • Domain verification screenshot and DNS record.
  • Naming convention document.
  • Conditional Access policy list (with exclusions).
  • PIM configuration (roles, approval settings, durations).
  • Role group membership list.
  • Log samples (sign‑in, audit).
  • Runbook log: who performed steps, when, validation notes.

⚠️ Risks, Safeguards, and Rollback¶

  • Risk: Lockout from CA misconfiguration.
    Safeguard: Exclude break‑glass; test in report‑only.
  • Risk: Admins retain standing GA.
    Safeguard: Enforce PIM; audit role assignments.
  • Risk: Inconsistent UPNs.
    Safeguard: Document and enforce naming convention.
  • Risk: Logs not retained.
    Safeguard: Verify retention; plan export in Phase 3.

Neil, this gives you a Phase 1 runbook that mirrors the rigor of Phase 0.

Would you like me to now draft the exact Conditional Access baseline policies (with conditions, assignments, and exclusions) so you can lift them straight into Entra, or keep it at this governance‑level documentation?

Phase 2: Management groups, policy, and subscription vending¶

  • Management group hierarchy: Establish a root hierarchy (Platform, Corp, Online/SaaS, Sandboxes) and place policies at the right scopes.
  • Foundational policies: Enforce required tags, restrict regions, require encryption, block public endpoints where applicable, and register core resource providers automatically.

  • Cost governance: Create budgets and alerts; tag cost centers and owners; integrate cost reports to FinOps.

  • Subscription vending: Adopt a Terraform vending module to create subscriptions under the correct management group, assign RBAC, budgets, policies, and optionally network attachments. Microsoft’s lz‑vending module covers subscription creation, RBAC, budgets, resource provider registration, and hub‑spoke/vWAN patterns4.

Phase 3: Connectivity, logging, and operational readiness¶

  • Networking baseline: Choose hub‑spoke or vWAN; define address spaces; set DNS strategy; plan private endpoints and firewalling.
  • Identity‑aligned access to landing zones: Provision workload identities, managed identities, and federated credentials for CI/CD.
  • Monitoring and SIEM: Enable platform logs and metrics; route to a central Log Analytics workspace and SIEM; set alert rules for critical signals.
  • Security baselines: Defender plans, vulnerability management, key management (Key Vault), and secure secrets handling in pipelines.