0.4 Northgate Group: The Current Estate

Introduction

A current-state assessment records what an estate actually is, so that a target design starts from the truth, which is often not what people remember.

It is built from evidence: exports taken from the tenants, inventories, the diagrams people have drawn and what people say in interviews. Each source is right about some things and wrong about others, and the assessment is where you decide which to trust for which question.

Northgate's evidence covers three tenants taken on different dates. Northgate Engineering's and Präzision's exports date from 15 March 2026 and haven't been retaken; Northgate Systems' was taken on 1 October 2026, four months after its acquisition. This lesson reads all three, company by company, and then what joins them.

The figure is how the lesson works. For each company you'll see what the case study records and what the export shows, side by side. Where they agree you have a fact you can cite.

Where they disagree, or where one is silent, you have a question, and Module 1's lab asks you to turn those questions into a first view of the group's risks. This lesson stops short of that judgment on purpose.

Every estate has two descriptions: the one its people carry in their heads and the one its configuration holds. They drift apart from the first day, because changes are made under pressure and documentation is updated later or never. An architect who designs from the first description builds a target on a foundation that isn't there.

Exports close the gap for anything a tenant can report about itself. A Conditional Access policy's state, a role assignment's expiry or the licenses assigned are exact in an export and approximate in anyone's memory. Exports are weak on everything else: why a setting exists, who asked for it, and what breaks if it changes. That's what the people are for.

Dates matter more than they seem. A configuration export is true on the day it was taken. Northgate Engineering's was taken on 15 March 2026, before the tabletop exercise, the change review and the sharing report that the case records later in the year. Anything you conclude from it about today is an assumption, and your assessment should say so.

There's a practical discipline in this. When you use a fact from an export, cite the file and the object: the policy's display name, the user's principal name, the SKU's part number.

When you use a fact from an interview, cite the person. When two sources disagree, write both down with their citations before deciding anything. That record is what makes your assessment checkable, and it's the first part of every deliverable in the course.

The exports are what Microsoft Graph returns, saved as JSON, one file per call. Each answers a specific question, and knowing which file answers which question is most of the skill. The questions come in three groups.

What the tenant is and what it has bought is in organization.json, from Get-MgOrganization, with its domains and whether it synchronizes from Active Directory, and subscribedSkus.json, from Get-MgSubscribedSku, with every license and the service plans inside it.

Who holds power is in roleAssignmentSchedules.json and roleEligibilitySchedules.json, which record who holds a directory role now, who may activate one through PIM, and until when. And how sign-in is controlled is in conditionalAccessPolicies.json, with every policy's state, conditions and controls, and identitySecurityDefaultsEnforcementPolicy.json, which says whether security defaults are on.

An assessment usually reads them in that order, because who holds power only makes sense once you know what the tenant is.

Two features of the format catch people out.

A list comes back wrapped: an @odata.context line naming what was asked for, then a value array holding the objects, so a count of policies or users is the length of that array, and a file with an empty value is a finding, not a broken export. And objects refer to each other by ID, a GUID that means nothing until you look it up in another file.

A role assignment's principalId is a user, found in users.json; its roleDefinitionId is a role, found in roleDefinitions.json. Built-in role IDs are the same in every tenant, so 62e90394-69f5-4237-9190-012177145e10 is Global Administrator wherever you meet it. A policy export repays slow reading. This is one of Northgate Systems' twelve Conditional Access policies, trimmed to its user conditions and its grant, with its IDs shortened:

{
 "users": {
  "includeUsers": ["All"],
  "excludeGroups": ["4dd9..."],
  "excludeRoles": ["d29b..."],
  "excludeGuestsOrExternalUsers": {
   "guestOrExternalUserTypes":
    "internalGuest,
     b2bCollaborationGuest,
     b2bCollaborationMember,
     b2bDirectConnectUser,
     otherExternalUser,
     serviceProvider",
   "externalTenants": {
    "membershipKind": "all" }
  }
 },
 "grantControls": {
  "builtInControls": ["mfa"] }
}

Read it in order. The export marks the policy enabled for every application, includeUsers set to All means everyone, and then the exclusions take people out again. The group ID resolves in groups.json and its members in groupMembers.json; the role ID resolves in roleDefinitions.json, and Graph returns the guest types as one comma-separated string, wrapped here to fit. builtInControls set to mfa requires multifactor authentication, the policy's only control.

The policy's name says MFA for all users. The export says MFA for every internal user except two accounts and a role, and for no guest or external user at all, which is the kind of difference the assessment exists to find. Following IDs across files, from a policy to a group to its members, is the move you'll make in every module.

Of the three companies, this is the one whose evidence you can check most completely, because its configuration, its events and its people's accounts all appear in the pack. It is also the largest and best equipped, and the case describes it in most detail because the group has held it longest. Read its identity first, because every other layer depends on it.

Its identity is hybrid. Active Directory, corp.ne.com, runs on NE-DC01, NE-DC02 and a read-only controller, NE-RODC01, and Entra Connect on SRV-NGE-MCR-AAD01 synchronizes it to Entra ID. That makes the synchronization server part of the identity boundary: whoever controls it can shape the cloud accounts.

Calder Fabrication's forest is trusted by corp.ne.com and isn't synchronized, which you'd learn from the directory, not the tenant, and which means Calder's accounts can reach on-premises resources without any cloud policy seeing them.

The export settles access and privilege exactly. It holds 840 Microsoft 365 E5 licenses and assigns 811. Its role assignments show 3 permanent Global Administrators and 8 roles eligible through PIM, every eligibility without an expiry, so PIM is deployed and its main benefit, privilege that ends, isn't used.

Its 5 Conditional Access policies are 4 enforced and 1 in report-only, and security defaults are off, as they must be for Conditional Access to run.

Mail and collaboration carry the exceptions. Exchange Online has inbound and outbound connectors for Calder, a transport rule trusting Calder's mail and one letting the office scanners bypass spam filtering: "Calder Fabrication - trusted partner", "Office scanners - bypass spam filtering", alongside 3 others. Its DNS export shows DMARC at p=quarantine for ne.com and p=none for ne.co.uk.

The tenant and OneDrive allow anyone links, and so does the Sales site, while Engineering and HR allow sharing with signed-in external users only. The certificate authority, NE-ADCS01, hasn't been reviewed since it was built. Facts like these are cheap to read and expensive to remember wrongly, which is why the course always sends you to the file.

Northgate also runs the group's shared systems and its only security operations. The ERP and PLM sit on its servers, Defender XDR and Sentinel watch its tenant, two L1 analysts work in-house, and Watchpoint SOC covers out-of-hours triage under a contract for Northgate Engineering alone.

Präzision's estate is the simplest to read and, because so much of it was set up by someone who has left, the hardest to explain. Its tenant is its own, created in 2019 by its former IT provider on the domain ngpraezision.example, and its identity is cloud-only, with no on-premises directory. Read every setting as the provider's choice until someone at Präzision claims it.

The export confirms the case's main points. Security defaults are on and there are no Conditional Access policies; Microsoft requires security defaults to be turned off before Conditional Access policies replace them. Business Premium licenses are assigned to 140 staff. 2 accounts hold Global Administrator permanently: Jonas Weber's, and admin@ngpraezision.onmicrosoft.com, the provider's original account, which created the tenant.

The provider's remote-management application, Fernwartung Partner Portal, still has a service principal with permissions in Microsoft Graph, so a party with no contract anyone can find holds two routes into the tenant, one as a person and one as an application.

Präzision's mail has a fault the case traces to an incident. Its SPF record includes the former hosting provider's range and it publishes no DMARC record, so a server in that range can send as ngpraezision.example and pass SPF, and receivers are given no instruction about mail that fails. In April a forged invoice sent from that range reached Northgate's finance team. The DNS records are in the pack.

Its administration rests on one person. Jonas Weber is the company's whole IT department, and when he's away the only other account that can change the tenant is the provider's. The devices tell the same story: the provider enrolled Präzision's Windows laptops and shop-floor terminals in Intune, so the device configuration is the provider's work too, and staff read email on personal phones nobody manages.

Two facts shape everything you'll design for Präzision and appear in no export. Its staff work in German and its works council has co-determination rights over systems that monitor them; and its Business Premium licensing is fixed by the purchase agreement until February 2028, so a design that needs more capability there has to find it within that or make a case for changing it.

Because Systems' export is the newest, it's the one you can trust most for today's state. Read it with the US prime's questionnaire beside it. Systems has been part of the group for four months; its previous owner ran it with a local managed service provider, Saluda Managed IT, and almost every setting in the export is the MSP's.

Its identity is hybrid, from corp.ngsystems.example on NGS-DC01 and NGS-DC02, with Entra Connect Sync running on NGS-DC02 itself and synchronizing password hashes. A synchronization server on a domain controller joins the two most sensitive roles in the estate on one machine. Its licenses are 260 Microsoft 365 E3, across engineering, sales and support, administration and the production supervisors and technicians, and 44 Microsoft 365 F3 for line operators.

Authentication allows Microsoft Authenticator, SMS and voice call for everyone, with passkeys and Temporary Access Pass off. The export makes the privileged access concrete. Each of the four Global Administrator assignments is permanent, two held by Ray Delgado's and Tasha Monroe's everyday accounts and two by the MSP's engineers, and there is no emergency access account. This is one of the MSP's, as roleAssignmentSchedules.json records it:

{
  "principalId": "0929ac82-e8e3-411e-9449-9e7003b00248",
  "roleDefinitionId": "62e90394-69f5-4237-9190-012177145e10",
  "directoryScopeId": "/",
  "assignmentType": "Assigned",
  "memberType": "Direct",
  "createdDateTime": "2018-05-22T14:05:00Z",
  "scheduleInfo": {
    "startDateTime": "2018-05-22T14:05:00Z",
    "expiration": {
      "type": "noExpiration",
      "endDateTime": null,
      "duration": null
    }
  }
}

assignmentType set to Assigned with an expiration of noExpiration is standing access with no end date. Systems has no eligibility schedules at all, and couldn't: Privileged Identity Management needs Microsoft Entra ID P2 or ID Governance, and E3 and F3 carry P1. Its 12 Conditional Access policies are the MSP's, 9 enabled and 3 disabled, and the policy read earlier in this lesson shows what one of them says about who it really covers.

Systems is also where licensing and practice have drifted furthest apart. Its E3 licenses include Defender for Endpoint Plan 1 and Defender for Office 365 Plan 1, neither configured, while it pays separately for a third-party endpoint product whose alerts go to the MSP's mailbox.

Its DMARC record publishes p=none with reports sent to the MSP, which collects reports and protects nothing yet, and DKIM signs only the onmicrosoft.com domain, not the one staff and customers use. The payment fraud Systems suffered in August arrived from a customer's real mailbox, and lesson 0.5 sets out what the case records about it.

The connections between the companies are where one company's controls end and another's begin, which makes them the places to look first. None of them appears in a single tenant's export; you see them only by reading the three together, and each is a path someone built to get work done. None of them was approved as a design, and none has an owner who reviews it.

Trust between the tenants is set nowhere. Each tenant's crossTenantAccessPolicy.json holds a default and an empty partners list, so no tenant names any other, so each runs the service defaults: B2B collaboration allowed in both directions, B2B direct connect blocked, and no trust of another tenant's multifactor authentication or device claims. Neither export holds a guest from the other company, so Präzision's staff reach Northgate's files today only by email.

If they were invited as guests under the service default, each would satisfy Northgate's MFA policy by doing MFA again in Northgate's tenant, so Northgate couldn't tell whether the device was managed at Präzision.

Präzision's and Systems' staff reach the ERP and PLM over Northgate's VPN, with Northgate accounts IT created by hand, which means three companies' leavers have to be removed from a fourth directory that no joiner process feeds.

The tools are three different stacks: Defender XDR and Sentinel at Northgate, Business Premium's defaults at Präzision, and a third-party endpoint product at Systems.

About 40 SaaS applications sit in IT's register, signed in to with Entra single sign-on at Northgate and with their own passwords elsewhere. And the renewals fall at different times, Systems in December 2026, Northgate's E5 in June 2027 and Präzision's Business Premium in February 2028, which sets the order in which the licensing can change.

What the group lacks matters as much. There is no group directory, no group security operations, no common policy baseline and no single place where an assessor could ask who can administer Northgate's tenants and get one answer. The pack's as-is diagrams draw each company's estate in five layers and the group view on a page of its own; open them beside this lesson.

Devices are where identity, data and threat protection meet, and the group's device estate is as uneven as everything else. Each device population needs its own answer to the same question: what does the group trust this device to do, and how would it know if that trust were misplaced?

Counting is the easy part; how each device is managed matters more, because a device the group doesn't manage can't be required to meet any standard.

Northgate Engineering's 865 endpoints are almost all Windows 11 24H2 laptops, Entra joined and enrolled in Intune, with a small macOS fleet in Product Design and shared terminals at Birmingham Works. Präzision's laptops and terminals are enrolled in Intune by its former provider.

Systems has 280 Windows laptops and desktops, 140 of them enrolled, and 12 shared Android tablets, one per production cell, not enrolled and signed in with one shared account, which the export confirms with 280 Windows devices.

Three populations will come up again and again. Shared shop-floor devices exist at all three companies: terminals at Birmingham and Stuttgart and tablets at Greenville, used by shift workers who can't sign in individually at every use, which constraint CON-08 records for Birmingham.

Personal phones read company mail at Präzision, about 110 of them, and at Northgate, where a contractor's lost phone in May could not be wiped; Northgate and Systems haven't counted theirs. And Systems' Windows estate is half managed, so any control that relies on device compliance would currently exclude half of its staff.

Module 8 asks you to design trust models for those populations. For now, record which devices exist, which are managed, and which nobody has counted, citing the file or the person each count came from.

The unmanaged populations in the figure are the ones a later design has to decide about explicitly, because a compliance requirement applied to them unchanged would stop shift work at Greenville and mail on Präzision's phones on the day it was enforced.

Practice

Files this lesson draws on

The evidence pack files used in this lesson, each linked for the Practice and for the modules that come back to it:

• 13-tenant-exports.zip: the Graph exports for all three tenants, with the date each was taken
• 06-inventories.xlsx: applications, devices, licenses and privileged roles, as IT records them
• 04-as-is-architecture.drawio: each company's estate in five layers, and the group view