But the setup guides and feature demos tend to move fast through the part that creates the most real-world friction: what the included security baselines actually do when applied to a client environment that hasn’t been audited first.

That’s the part worth spending time on before anything goes live.

The Legacy Authentication Problem

Lighthouse’s deployment baselines include a Conditional Access policy that blocks legacy authentication. The name sounds routine. The impact is not.

Legacy authentication covers older protocols and auth flows that predate OAuth 2.0, specifically POP3, IMAP, SMTP AUTH, and older Exchange Web Services calls. None of them support MFA. That is the security problem: a client can have MFA fully configured in Entra ID, and a credential spray via IMAP bypasses it entirely, because the connection never goes through a flow where MFA can be triggered. Microsoft’s own position is that most compromising sign-in attempts come from legacy authentication, and that legacy protocols like IMAP, SMTP, and POP3 cannot support MFA, meaning bad actors can bypass enforcement through them. The policy is correct directionally. Medium

The issue is execution order.

Apply the baseline to a tenant without first auditing what is using legacy auth in that environment, and something breaks. Common culprits: printers or multifunction devices configured to use SMTP AUTH for scan-to-email, older line-of-business applications that authenticate to Exchange with Basic Auth, third-party integrations that were never updated to OAuth, and shared service accounts used by automation or scheduled tasks that nobody has touched in years. The authentication attempt fails silently, the device or application stops working, and the ticket comes in with no obvious link to anything that changed.

The Block Legacy Authentication policy appears in Entra ID as a Conditional Access policy, and administrators can set its state (report-only, on, or off) and manage which identities are excluded from it. That report-only mode is the right starting point. Before enforcing anything, pull the Entra sign-in logs and filter the Client App column for “Legacy Authentication Clients.” Every result is a dependency that needs a decision: update it to OAuth, create a targeted exclusion in the policy, or involve the vendor. Run report-only for at least a week per tenant. Watch the logs. Then enforce. Microsoft Learn

The baseline is right. The audit is what makes the rollout not a fire drill at 7 AM.

Other Drawbacks Worth Knowing

Legacy auth is the one with the most immediate blast radius, but the other friction points are worth understanding before you commit to the platform.

GDAP onboarding is slower than it looks. Each client tenant has to actively approve the Granular Delegated Administrative Privileges relationship before Lighthouse surfaces full visibility for that tenant. The setup involves sending relationship requests through Partner Center and walking clients through approving them. For technically engaged clients, that is manageable. For a non-technical office manager who does not recognize what the approval email is asking for, expect it to sit ignored or get flagged as phishing. Build the approval step into a broader onboarding conversation rather than a cold email. Microsoft Learn

Licensing gates the useful features. Full Lighthouse functionality requires Entra ID Premium P1. That comes with Microsoft 365 Business Premium, can be added as a standalone add-on to lower-tier plans, and Entra ID Premium P1 is also required for user account data to appear in reports within Lighthouse. Clients running Business Basic without the add-on get a limited view, mostly tenant visibility and service health. Device management and the threat management pages also require Intune enrollment and Defender Antivirus on endpoints. If a chunk of your client base is on minimal licensing, budget the conversation before you build out the workflow. Dev4Side

Nothing auto-tickets. Lighthouse surfaces findings and leaves them there. A risky user alert across ten tenants sits in the portal until someone looks. If your PSA does not have a native Lighthouse integration (most do not), bridging that gap is a manual workflow or custom alerting build you own.

It is not an RMM. Patch management, agent-level scripting, remote task execution, and automation live in your RMM. Lighthouse operates on the Microsoft 365 and Entra ID layers. The two tools do not overlap much in practice, but the distinction matters when scoping what Lighthouse is actually adding.

Where It Earns Its Place

The multi-tenant security posture view is genuinely useful. MFA coverage gaps, risky user alerts, and device compliance status across all managed tenants in a single dashboard is something you cannot replicate by logging into each admin center individually.

GDAP is now a prerequisite for Lighthouse and a cornerstone of secure multi-tenant management. For all its onboarding friction, GDAP is the right model. The older DAP model gave MSPs broad, persistent global admin access to client tenants with no scope limits, which was a significant security liability. A compromised MSP account had full access to every client. GDAP scopes permissions to specific Entra roles. If your MSP is still on DAP across most of your client roster, the Lighthouse migration accelerates the fix. CIAOPS

Cross-tenant service health is a smaller feature that adds up in practice. All Microsoft 365 service incidents across all managed tenants in one place, no tab-switching. Individually minor, practically useful.

Lighthouse is free to qualified CSP partners; only the MSP needs to be enrolled in the CSP program, not the clients they manage. You are not adding a vendor line item to evaluate it. Microsoft Learn

For MSPs covering specialized verticals, like dental or orthodontic practices running Microsoft 365 for both clinical coordination and admin operations, having security posture and risky user detection aggregated from a single console fills a gap that is harder to justify closing practice by practice. Catching a compromised account or an MFA gap before it becomes an incident matters more in environments with minimal on-site IT.

The Short Version

Lighthouse is worth adding to the stack. The posture visibility is real, the GDAP migration is overdue for most MSPs anyway, and the cost is zero.

Map your legacy authentication dependencies before the baseline goes live. Use the Entra sign-in logs, filter for legacy auth clients per tenant, run the Block Legacy Authentication policy in report-only mode first, and watch what shows up. That step is the difference between a clean rollout and a client down first thing in the morning.

If this was useful, the subscribe button is right below. New posts go out when there’s something worth writing about.

The shorter version of posts like this goes out on LinkedIn first.

Subscribe now

Reference links:

• Block legacy authentication with Conditional Access (Microsoft Learn)

• Microsoft 365 Lighthouse requirements (Microsoft Learn)

• Set up GDAP in Microsoft 365 Lighthouse (Microsoft Learn)

For a small footprint, that’s fine. For an MSP managing dozens of dental and orthodontic practices across the country, it adds up fast. Every new location meant sitting through the same sequence of configuration steps. Every policy change meant doing it over. The only way to maintain consistency was discipline and documentation, and those are fragile.

UniFi Fabrics, announced in January and officially moved to the stable branch in April 2026, is Ubiquiti’s answer to that. It’s a management layer built on top of Site Manager that lets multiple UniFi sites be grouped under a shared administrative and identity model, with centralized role-based access control, identity provider integration, policy and device templates, and more. The short version: a single control plane that treats all your sites as one system instead of a collection of independent deployments.

Here’s what that actually means in practice.

The Orchestration Engine: Blueprints and Canvas

Blueprints and Canvas are the two main tools inside the Orchestration Engine. Blueprints handle initial site deployment. You pre-provision a new site in the Fabric, and installers receive a Magic Link with instructions to bring the site up against your pre-configured settings, including custom WAN settings per site. Canvas handles ongoing configuration compliance. It contains settings that are synced to site devices and can’t be modified from within the individual site’s Network application.

That second part is where the real operational value is. Canvas settings are enforced. You configure a firewall policy, a guest network isolation rule, or a DNS server at the Fabric level and it stays that way across every site. A technician working inside a specific site’s console can’t accidentally (or intentionally) drift from the standard. For an MSP environment where you’re handing different contractors access to different sites, that’s not just convenient, it’s a compliance consideration.

Blueprints are equally useful on the deployment side. New sites can be deployed rapidly while maintaining consistent organization configuration and security standards. Scaling infrastructure is simplified through device templates and policy assignments that enable true Zero Touch Provisioning. In practice this means a new practice location can come online with your standard VLAN setup, your firewall policies, your SSID configuration, and your monitoring integrations already applied, before anyone on your team logs in. The installer follows the link, connects the hardware, and the site comes up in your Fabric.

RBAC and Identity

Fabrics provide a way to centrally manage people and assign granular permissions across multiple UniFi sites. By defining access at the Fabric level, administrators can scale both user and administrative access without duplicating configuration per site.

The permission model splits into two categories. Admin permissions control access to the UniFi management interface, ranging from full access to view-only or application-specific grants. User permissions (through the UniFi Endpoint app) cover things like One-Click WiFi, One-Click VPN, and Smart Door Access.

For MSPs, the more relevant feature is IdP integration. Administrators can bind leading identity providers, apply user-based policies, and deliver secure access through a seamless UniFi Identity experience across platforms. Security is enforced by identity, not location-specific policies. Microsoft Entra is explicitly supported. This means employee onboarding and offboarding in your client’s directory automatically propagates to UniFi access. A new employee gets provisioned in Entra, and their UniFi permissions appear. Someone leaves, their access is gone. The Identity Sync Service runs on a designated console called the Master Site, which acts as the orchestrator for people and permissions across all sites in the Fabric.

Hardware requirement worth noting: IdP binding requires one of the following consoles to be present in the Fabric: UDM Pro, UDM SE, UDM Pro Max, EFG, UNVR Pro, ENVR, or ENVR Core. UniFi OS v4.4 or newer is required. If you’re running older hardware or lower-end gateways as your primary console, plan for that before you start.

The API and Automation Layer

The Fabric API extends the platform to developers and integrators with complete documentation, Ansible support, and unified access to every connected environment through a single interface.

This one is early days, but the direction is clear. A single API endpoint that covers your entire deployment is a different thing than site-by-site API calls. If you’re building automation around UniFi or integrating it with something like N-able or a PSA tool, the Fabric API is where that work will eventually live.

The No-Licensing Part

Site Manager redefines how enterprise IT is built and managed, bringing together power, simplicity, and scalability without added licensing complexity. The future of enterprise IT is unified, scalable, and completely license-free with UniFi and the new Site Manager.

That’s Ubiquiti’s marketing language, but it’s accurate. There is no per-site licensing, no controller hosting fee, no tier you need to upgrade to in order to use Fabrics. That’s a real differentiator. The platforms that compete with this level of multi-site management capability charge for it, usually on a per-device or per-site basis that compounds fast across a large fleet.

Getting Started

Fabrics is available now on the stable branch. To get started, navigate to Site Manager, select or create a Fabric, go to Settings > Identity, and enable Consolidated People Management. From there you can optionally bind an Identity Provider for Zero-Trust networking and automated employee onboarding and offboarding.

The recommended approach (and worth doing before you get deep into it) is to make sure a single company-managed UI account owns all your sites. It’s not strictly required to use Fabrics, but it simplifies RBAC and is required for the Site Magic SD-WAN feature if that’s on your roadmap.

The Ubiquiti Academy also has material covering how Fabrics is deployed and operated at scale. If you’re setting this up for the first time across a large fleet, start there.

Resources:

• Introducing UniFi Fabrics: https://blog.ui.com/article/introducing-unifi-fabrics

• The New Site Manager, Now Official: https://blog.ui.com/article/officially-bringing-unifi-fabrics

• Getting Started with UniFi Fabrics (Help Center): https://help.ui.com/hc/en-us/articles/30979808349463-Getting-Started-with-UniFi-Fabrics

• Managing Fabric People, Roles, and Permissions: https://help.ui.com/hc/en-us/articles/31557407384343-Managing-UniFi-Fabric-People-Roles-and-Permissions

That’s the short version. The longer version is more interesting.

The Detour That Made Sense Later

A few years behind the green apron, then a move that looked completely unrelated on paper: operations management at U-Haul. If that sounds like a wrong turn, it wasn’t. That job taught me how to troubleshoot systems under pressure when someone is standing in front of you, frustrated, and the clock is moving. That skill transfers directly to IT support. It just wasn’t obvious at the time.

At some point, with the support of my family, I made the decision to go all in on technology. I enrolled at Tennessee College of Applied Technology and started stacking credentials. CompTIA A+, Network+, Security+. Then Microsoft’s Azure Fundamentals, 365 Fundamentals, and Security, Compliance, and Identity (SC-900). No four-year program, no shortcut. Just focused study and a clear direction.

That path led to Impact360, a managed service provider handling technology for dental and orthodontic practices across the country. The platform I work in shows 5,545 managed endpoints across our client base as of this morning. (Pulled that number directly from our RMM tool before writing this sentence.) Workstations, servers, imaging equipment PCs, and everything in between, spread across 50+ practices where downtime is measured in patients, not just lost productivity.

What the Day-to-Day Actually Looks Like

The practices we support run software most people outside this vertical have never heard of: Dolphin Management, OrthoTrac, Dentrix. They have dedicated imaging systems for dental X-rays. They run Remote Desktop Services so multiple users can share a single application instance across a server. They have VoIP phones, Cisco Meraki firewalls, UniFi access points, and SentinelOne doing behavioral detection on every endpoint.

When something breaks in that stack, the front desk can’t check patients in. The doctor can’t pull up treatment records. The X-ray system won’t capture. That’s the environment I work in every day, and it’s a surprisingly complex one for an industry that doesn’t generate a lot of written IT content.

I’ve built custom software to solve a port-conflict problem that shows up in Dolphin Management’s RDS deployments. I’ve scripted BitLocker auditing across the fleet and found compliance rates well below what anyone would have guessed. I’ve done full VLAN schemas for practice networks from the ground up, configured Meraki warm spare HA setups, and worked through the kind of vendor-specific failures that don’t appear in any official documentation.

Why I’m Writing

I’ve always had a knack for writing. Not in the “always wanted to be a writer” sense. More in the “I notice when a sentence is wrong and I can’t move on until I fix it” sense. It’s just something that comes naturally, and for a long time I didn’t have a dedicated outlet for it.

This is that outlet.

The blog lives under the Syght Ventures brand, which is the umbrella for the work I put out publicly. What you’ll find here is field-level IT content with enough detail to be useful, not career advice listicles or surface-level takes on industry news.

That means posts about the dental and orthodontic IT vertical, which is genuinely underserved in written content considering how complex it is. It also means posts about the broader technology world. Apple, Microsoft, Anthropic, OpenAI, Google, and all the things those companies are building that shape the environments practitioners like me work in every day. AI is changing what managed services looks like. I have opinions about where that goes, and I know how to write them down clearly.

What to Expect

Some posts will be technical walkthroughs of specific problems and how they got solved. Others will be field notes from working across a large fleet. Some will be commentary on tech industry news and what it means for people actually working in IT, not just watching it from the outside.

Posts go out when there’s something worth writing about. Not on a schedule.

If this is the kind of content you’re looking for, the subscribe button is right below.

Found me on LinkedIn first? The shorter takes go there. Full posts live here.

Subscribe now

Subscribe now