Azure Lighthouse - Simply Explained

0:00 An outside company can manage your Azure setup without ever holding your password. That's what Azure Lighthouse does, and it's Microsoft's fix for a weekly headache. A company that manages cloud for other businesses used to need a separate login inside every customer's account. Lighthouse replaces that with one signed door that opens only one way and stays under the customer's control. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end, you'll be able to explain it, the handshake behind it and the one limit. Beginners miss the two houses problem. When a company signs up for Microsoft's cloud, it doesn't get a shared lobby. It gets its own private world, and Microsoft calls that world a tenant. Think of a tenant as a house with its own locks, its own rooms, and its own guest list.

0:40 Everything that company runs in Azure or Microsoft three hundred sixty five lives inside those walls, and the whole point of the design is that no other company can wander in. That separation is good for security, and it's miserable for anyone whose job is to run cloud on behalf of other people. Picture the old reality. Say you run an IT company and you look after the Azure setup for forty small businesses to touch their resources. You couldn't simply use your own account. You had to sign in with an account that actually lived inside each customer's tenant. That meant an administrator at every one of those forty companies had to create an account for you. Hand it the right permissions and remember to remove it later. Multiply that by every person on your team who needs access, and then by every customer, and you end up with a spreadsheet.

1:22 Nobody can keep honest. The real tension here is that the safer Microsoft made those walls, the harder it became to do legitimate work across them. This wasn't a small annoyance for a managed service provider, which is the outside company a business hires to run its cloud. It was the thing that made growth painful. You couldn't bring a new customer on board in an afternoon, because first you had to chase down the administrator and wait for accounts to be built by hand. Large companies ran into the same wall from the inside. When one company buys another, it often ends up with two or three separate tenants instead of one. Suddenly, its own IT team is stuck doing the same awkward dance across its own organization. While we're defining things, two more words will keep coming up, so let's put them in plain terms. A subscription is the billing and management container a company uses to organize and pay for its Azure resources.

2:07 A resource group is just a folder inside that container that keeps related resources together. Hold on to those two words because they become the handles the customer uses later to decide exactly what gets shared. So the pain had two faces. One face was access that was too hard to get, and the other was access that nobody could cleanly remove. Every temporary login you created for a customer turned into another thing to track, and another thing sitting quietly inside someone else's system long after the project wrapped up. That's the problem Azure Lighthouse was built to solve. What Azure Lighthouse actually is. Azure lighthouse lets one organization manage another organization's Azure resources from its own environment without needing an account inside the other organizations directory. That's the plain version. Microsoft's own description talks about managing many tenants at once with more automation and stronger governance, but you can set that sentence aside for now.

2:54 What you actually need is the picture. Keep the two houses in mind. Lighthouse doesn't merge them and it doesn't knock down a wall. It builds one door. And that door is what people mean when they say delegated resource management. A delegated resource is simply a customer resource that the customer has agreed to hand over for someone else to manage. The clever part is what Microsoft calls a logical projection. The customer subscriptions and resource groups begin to show up inside the provider's own view, almost as if they belonged to the provider. Even though the resources never leave the customer's house, nothing gets copied and nothing gets moved. You're looking through a doorway, not staring at a duplicate. Say a provider looks after a customer's virtual machines. With lighthouse. Those machines appear in the provider's portal right next to their own, and the provider's team can patch them, back them up, and check their health without ever leaving home.

3:39 The customer, meanwhile, still owns each of those machines, still pays the bill, and still decides who is allowed through the door. The direction matters more than anything else in this episode, so hold on to it. The access only ever travels one way from the managing organization into the managed one. The customer never reaches back into the provider's environment, and the provider can't quietly past that access along to somebody else. Two more facts make this easier to live with. There's no extra charge for using Azure Lighthouse to manage Azure Resources, and any Azure customer or partner can use it. It also isn't tied to a single region, which means a provider in one part of the world can manage resources scattered across many others. What makes this different from simply handing somebody your password is that the door is written down.

4:20 It has a name, a scope, and a role attached to it. And all three of those things live in your account rather than theirs. You aren't trusting a person to behave. You're trusting a document you can read and later revoke. So the concept comes down to one signed door between two separate worlds built for management and pointed in a single direction. There's one honest limit that trips up almost everybody and will come to it. But first you need to see how the door is actually built. The handshake, how the door gets built. The door isn't magic. And that's good news because it's built from exactly two small pieces you can name. The first piece is called a registration definition. It's a record that lives inside the customer's account and it answers two questions which organization is being trusted to manage these resources, and what exactly is that organization allowed to do?

5:02 The second piece carries a similar name the registration assignment. If the definition is the contract, the assignment is the address it applies to. It attaches that contract to one specific place, which is either a whole subscription or a single resource group inside it. Inside the definition sits the thing that really matters, and it's called an authorization. An authorization is one person or more often one team or a service account used for automation, paired with one built in role that sets the limit a reader can look but not touch. While a contributor can change things. The role is the leash and the customer decides how long it stays. In practice, a provider rarely hands over a single name. They build a small structure of teams. A support group gets read only access.

5:42 A migration group gets permission to make changes, and an automation account gets exactly what a script needs. Each one counts as its own authorization, which means the customer gets to read the list and see line by line who is coming in and how much they're allowed to carry. The part that surprises people is what happens on every single request. Microsoft doesn't rely on the customer remembering to check anything. Every time a provider's user tries to act as your resource manager, the layer that approves or rejects every request in Azure stops and confirms that both pieces are present in the customer's account. If the definition and the assignment aren't both sitting there, the request simply fails. That means access isn't a one time handshake you hope was done correctly. It's checked on every action over and over for as long as the door exists.

6:23 There's a paper trail too, and it lives on the customer's side of the wall. Every action the provider takes gets written into the customer's own activity log, so the customer can open it up and see what changed and who changed it. The customer is never a passenger in any of this. Their own administrator, the person who holds the top level of permission on that subscription has to run the deployment that creates the definition and the assignment. If that person doesn't act, the door doesn't exist. One small detail saves people a lot of confusion. Later, when the onboarding runs, Microsoft switches on a piece of behind the scenes machinery called the Managed Services Resource Provider, it can take up to fifteen minutes before the change shows up in the portal. If you deploy it and see nothing at first, you're probably just early rather than wrong. One more choice deserves your attention.

7:03 When a customer delegates, they aren't forced to hand over the entire account. They can point at a single resource group the way you might hand someone a key to one room instead of the front door. So the handshake has a clear shape. The provider proposes the terms, the definition records them, the assignment aims them at one spot, and Azure checks the paperwork on every move, who uses it and who approves it. Three kinds of organizations lean on this, and you've probably met one of them without knowing it. The first is the managed service provider, the outside company that runs cloud for lots of other businesses. For them, lighthouse turns forty separate logins into one screen. The second is the large enterprise that ended up with more than one account world. After a merger or an acquisition, a company often keeps separate tenants on purpose, maybe because of a legal rules, or because the two businesses genuinely operate independently.

7:49 With lighthouse, one of those worlds can act as the manager for the others. The same policies, the same backups, and the same security process can then be applied everywhere without forcing a painful merge. The third is the software maker that delivers a service to many customers at once. If you've ever used a cloud product that plugs into your own Azure account, there's a fair chance lighthouse is part of how it reaches you. Picture a provider with three customers to see why the flexibility matters. One wants full management of a single application, another wants monitoring only, and a third is a regulated business that will allow nothing beyond read access to one resource group. With lighthouse, all three relationships live side by side in the provider's portal, each one locked to its own scope and its own role. The way a relationship starts is worth a closer look, because there are two doors for signing up, and they suit different situations.

8:33 The first door is a template that gets deployed inside the customer's account. The provider prepares the file, then the customer runs it. This works best for a direct known relationship where the two companies already have a contract and just need to connect the plumbing. The second door is a managed service offer listed in the Microsoft Marketplace, the customer picks it, chooses which subscriptions to hand over, and the connection is built as part of the purchase. This suits a provider who sells the same service to a long list of customers, and wants a repeatable way to onboard them. Either way, one rule never changes the customers own administrator has to approve the deployment, and that person needs top level permission on the subscription in question. Nothing happens behind the customer's back because the customer is the one holding the pen. There's one more distinction worth knowing, and it's about fairness.

9:15 A public author gives every customer who buys it exactly the same permissions, which is simple but blunt. A private offer is built for one customer's exact needs. If a provider wants to treat two customers differently, they need private offers or custom templates because a public plan can't be tailored after the fact. Once everything is connected, both sides get a home base. The customer reviews and manages its providers on the page in its own portal, and the provider sees every customer on a matching page of its own. Everyone can see the relationship, which is exactly how it should be. The security story. Who really holds the keys? Let's name the fear directly because it's the right fear to have. This whole arrangement sounds like handing a stranger the run of your house. The customer stays in charge for a simple reason. They choose the scope which sets.

9:56 Whether it's one room or the whole building. They choose the role which sets whether the provider can look or can change things. That control doesn't stop at setup either. They can open the activity log and audit every action that was ever taken, and they can remove the access completely at any moment without asking anyone's permission. Microsoft's own guidance for providers starts with the principle of least privilege, which is a plain way of saying give people only what the job actually needs. In practice, that means attaching permissions to teams and service accounts rather than to individuals, so access can be added or taken away without rebuilding the whole agreement from scratch. Multi-Factor authentication is strongly recommended on both sides, and there's a catch here that beginners should hear clearly a customer's own sign in rules, the ones that control where and how people may log in don't apply to the providers users.

10:39 Only the managing organizations rules apply to them. That's a real gap, and it's why Microsoft asks both sides to switch on stronger sign in protection. A smarter option exists for handing out power instead of granting a role permanently. A provider can mark it as eligible, which means the person has to deliberately activate it for a limited window before it switches itself off again. This leans on a Microsoft feature called Privileged Identity Management, and it has licensing requirements, so it isn't free. In every plan where it's available, it shrinks the number of people walking around with standing power. Now, for the limits that protect the customer. The full owner role isn't supported in a delegation, so a provider never gets handed the keys to everything. Roles that carry access to the data inside a service aren't supported either, and custom roles are off the table, so only the built in ones Microsoft defines are allowed.

11:24 One more safety valve is worth knowing if the provider includes a specific cleanup role. When they set up the agreement, they can remove their own access later, which is useful when a contract ends. Without that role, only the customer can remove it. Removal is just as clean as setup. A delegation can be updated when a role changes or deleted when the relationship ends, and either one is the customer's call to make. That matters because the messy part of access is rarely getting it, and it's almost always getting rid of it. Auditing isn't an afterthought either, because the activity log records provider actions in the customer's tenant. A customer can answer the question that keeps people up at night. They can see who touched something when they touched it and what they changed. So the keys stay where they belong. The customer owns the house, writes the guest list, watches the door, and can change the locks whenever they like.

12:08 What Azure Lighthouse is not. After all that reassurance, honesty matters. So here's what this tool can't do. The biggest confusion to clear up is that lighthouse is a management tool rather than a data tool. It handles the requests that travel through Azure Resource Manager, the service that builds and changes resources, and it doesn't reach into the data sitting inside those resources. In plain terms, it isn't a route to reading a secret out of a key vault or opening a file in the storage account. Those requests travel a different road, and lighthouse isn't on it. The second thing worth saying is that nothing gets moved or copied. We said it earlier, and it bears repeating because the phrase delegated resource management makes some people picture a transfer of ownership. There's no transfer, only a link and the link runs one way.

12:48 The third point is the honest catch, and it's worth knowing before you assume a safety net is a wall. If a customer places a lock on their resources to stop things from being changed or deleted, that lock doesn't stop a provider's users from acting. It's a genuine gap, and it surprises people who assume every guardrail applies to everyone. There's a regional rule worth a line as well. Lighthouse crosses regions freely, but it can't bridge a national cloud and the public cloud or two separate national clouds. A national cloud is its own version of azure, run by one country under its own rules. And that's one boundary the door simply can't cross. One more limit is about visibility, and it's easy to trip over for people on the customer side, the usual access list in the portal and the standard command line tools don't show the roles that were handed out through lighthouse.

13:29 Those assignments live in the lighthouse section of the portal instead. That isn't a security hole, but it does mean you should look in the right place before you conclude that nobody has access. Finally, there's a naming trap. Azure Lighthouse and Microsoft three hundred sixty five lighthouse sound like the same product, and they aren't. Azure lighthouse is what we've been talking about, and it manages Azure Resources. Microsoft three. Sixty five lighthouse is a separate tool that helps providers onboard, monitor and manage Microsoft three hundred sixty five customers. They share a name, but they solve different problems. The recap and one question. So let's pull the threads together. Two organizations keep two separate cloud worlds and lighthouse builds one signed door between them. The connection is made from a definition and an assignment aimed at a scope. The customer chooses and checked on every single action.

14:12 The customer keeps the keys. They can watch everything through the activity log, and they can pull that access whenever they choose, and it costs nothing extra to use. The real value here is the control that travels with the access. Now sit with this question. Picture an outside provider given exactly the right amount of access. Watch the whole time and removed when the contract ends. Where else in your work does access get handed out once and never taken back? If this made Azure Lighthouse, click subscribe to M365 FM, because next time we break down another piece of the Microsoft cloud the same way.