Manage Windows Endpoints Better — Get Them Off the Domain

"Three things will survive a nuclear war — cockroaches, Twinkies and Windows apps."

Even as SaaS and browser based apps are continuously expanding in adoption and varied types of endpoints and devices are making the move from consumer to business use, Windows maintains a central and critical position in enterprise IT. As such, managing, maintaining and securing Windows endpoints is key to providing a great user experience while also protecting the business against exploits and vulnerabilities. IT departments spend considerable time and treasure in these efforts, often using multiple tools while chasing lower than desired success/compliance rates for core activities such as patching and application lifecycle management.

The problem is that while time has progressed for many (most?) IT organizations, Windows management has not.

At its core, Windows management has relied on the concept of being part of a domain. From Windows NT 3.1 (released in 1993 — which makes me feel old) through the present, Windows machines and users have been "joined" to the domain for the purpose of centralized management and resource access. Users and machines are represented as accounts in the domain, and membership in the domain is a prerequisite to getting access to file and print resources owned by other domain members as well as receiving required configuration changes. 

The advent of Active Directory significantly expanded this ability to manage resources, users and machines from a centralized system. For 20+ years now (again, when did I become so old?) IT has built upon Windows domains and AD to manage their Windows environments and in fundamental ways, they haven't changed.

However, the environment they are managing has changed and some glaring deficiencies have developed.

First, the domain model is predicated on all members being continuously LAN/WAN connected. This connectivity is required for the members to communicate with the Domain Controller and other joined systems for identity verification and configuration validation as well as with other integrated systems for functions like antivirus scanning and updating and patching. However, as the current pandemic and associated work from home shift have exacerbated, Windows endpoints are moving off the corporate managed network at an accelerating rate. 

For many companies, there are now more Windows endpoints "off LAN/WAN" than are on the LAN/WAN. Even when using VPNs for remote connectivity, the endpoint spends more time disconnected than connected due to licensing and hardware and circuit sizing limitations. As a result, systems are spending considerable amounts of time effectively unmanaged — and bad actors are very aware of this. When the systems do connect often they are unable to be validated and "caught up" due to bandwidth constraints and important patches, updates and configurations are not successfully received and processed.

A second deficiency of the domain model lies in its core architecture. When an endpoint is joined to a domain, an account/object for the computer is created and the account is added to the Authenticated Users group. By virtue of having an account, the machine is able to perform activities such as browse or query the domain for resources. Its membership in the Authenticated Users group allows it to access resources for which that group has been assigned rights. 

While the assignment of rights to the Authenticated Users group is discouraged as a current recommended practice, any Windows admin with sufficient tenure will say that they've used it in troubleshooting. However, much like the creation of documentation, cleaning up the "shotgun troubleshooting" act of assigning rights to Authenticated Users often is overlooked as the next fire flares up and demands attention. This results in the computer account having access to resources it should not, and this is a very common vector for exploitation by malware.

Modern management: this is the way!

Windows 10 gives us an opportunity to correct these issues and adapt to the changing Windows landscape via modern management. Built like a mobile operating system, Win10 devices can be managed by unified endpoint management (UEM) systems without being joined to a domain — and I would argue far better than being domain-joined. These systems allow the ability to configure, secure, validate and remediate systems "over the air" via unsecured networks. Importantly, this includes configuration settings and policies that have been traditionally delivered via Group Policy. 

Additionally, these non-domain joined endpoints can leverage the modern management compliance validation and remediation capabilities to quickly detect any configuration deviance and enforce remediation with an escalation workflow if needed to protect the enterprise — far better than wondering why something didn't apply, issuing the gpupdate.exe /force command and waiting 90 minutes +/- 30 minutes to see if anything changes.

Non-domain joined Win10 devices also make an important contribution to a Zero Trust security posture by removing the inherent trust that a computer object receives in a domain. With no computer account the endpoint itself has no ability to query for domain-managed accounts, shares, or other resources, and with no corresponding membership in Authenticated Users, there is no opportunity for misapplied security ACLs to compromise resource security. This ensures that user objects are the proper basis for assigning rights to resources, not more easily compromised, lost or stolen endpoint devices.

Moving to Win10 modern management is not an overnight process, and determining to what extent non-domain joined devices make sense for an organization requires careful analysis and planning. However, the benefits more than justify the effort. 

We can help you through the entire process and help you shake off the legacy chains of Windows domain management.