Tehama’s Room Directory and Domain Join are two powerful tools that can be optimized by enterprises that need to support a large number of employees and contractors working remotely. These features enable organizations to securely manage their employee’s security, user experience, and access settings at scale and extend user’s corporate identities to virtual desktops. These capabilities allow businesses that have shifted to a hybrid workforce to consistently manage all types of devices with the same set of tools, regardless of user location.
Tehama Room Directory: Manage Group Policy out-of-the-box/with no integration required
By default, every Tehama Room has its own independent directory, called a Room Directory. This allows administrators to review, control and modify Group Policy settings within the Room in order to help provide a consistent user experience for both remote and in-office workers, while also enforcing key security settings. Administrators just need to configure Group Policy settings once, with all settings automatically applied across every desktop in the Room.
This capability comes out-of-the-box with a Tehama Room; no integration, infrastructure or additional IT administration effort required. Whether your organization isn’t using Active Directory, or isn’t ready to facilitate an integration yet, the Tehama Room Directory allows organizations to benefit from the ability to centrally manage Group Policy for a Room without needing to wait for approval or resources to assist in an integration.
The Tehama Room Directory is designed to add flexibility and agility for all organizations using Tehama, especially those that:
- Regularly onboard users (such as contractors or third parties) who aren’t in their domain, but still need to manage what these users can do within the system;
- Want to treat Tehama virtual desktops separately from desktops in their domain; or
- Need more agility when making Group Policy changes (by isolating these changes to a Tehama Room, if required, which only affects the desktops of users in that particular Room).
Tehama’s Domain Join feature goes a significant step further by connecting your Tehama environments with your standard corporate user management capabilities.
Domain Join, when enabled in Tehama Gateway Rooms, allows enterprises to integrate a Room with their existing Active Directory implementation. In a Room with Domain Join turned on, the Tehama directory interfaces with your Windows domain. This provides a central authentication point for Windows users on the network, allowing them to log into a Tehama desktop using their corporate credentials and automatically inherit their domain user settings.
This facilitates centralized management (within your central Active Directory) of critical security, user experience and access settings on Tehama desktops, including those configured with Group Policy, using the same tools you use to manage the rest of your desktop estate.
Organizations who will likely see the most value from Domain Join include:
- Those who want to centrally manage their entire desktop fleet (physical and virtual) and leverage their existing Group Policy settings, without having to duplicate this setup within Tehama;
- Organizations whose security stack requires users to be part of their domain; and
- Organizations with software that needs to run as a specific domain user for proper functioning.
How Tehama’s Domain Join works (and why it’s better)
Ease of Administration with no Additional Infrastructure
When leveraging Tehama’s Domain Join, the act of connecting with your On-Premises Active Directory(AD) is a simple process that can be set up through the Tehama web interface. There is no replication or duplication of your directory required and no additional infrastructure to manage, reducing the amount of IT administration effort involved.
In contrast, other standard methods of connecting DaaS or VDI desktops to your domain have added costs or complexity, often requiring you to buy and support additional infrastructure, pay for yet another cloud resource, or expend significant effort to support this integration.
One-way Trust for Optimal Security
In establishing an integration with your Domain, Tehama establishes a one-way trust, rather than the two-way trust required by some other solutions.
In general, Domain Trusts allow users in one domain to access and use resources in another domain. It’s generally accepted that one-way trusts are more secure than two-way trusts.
Here’s how one- and two-way trusts work:
- In a one-way trust between two domains, Domain A is the trusted domain and Domain B is the trusting domain. That means Domain A users can access Domain B’s resources, but Domain B’s users can’t do the same with Domain A
- In a two-way trust, all users can access resources from both domains
(Named after Willy Wonka’s legendary Golden Tickets guaranteeing the owner a lifetime supply of chocolate, Golden Ticket attacks use a sort of digital golden ticket to access any resource on the domain. Golden Ticket attackers can then escalate their own privileges, moving laterally on enterprise networks without triggering security alerts.)
Unfortunately, some DaaS vendors require a two-way trust. That means your DaaS environment can access resources in your on-prem AD – not an ideal configuration. Two-way domain trusts can introduce unintended access paths between environments – just like the Golden Ticket attacks – when not properly managed and monitored, putting your domain at higher risk for exploitation.
Tehama’s Domain Join leverages a one-way trust relationship with your on-prem AD, which makes the Tehama Room look to the enterprise directory (accessed across an encrypted channel through the Tehama Gateway) as its controller to authenticate users.
To again use the example we mentioned above, your on-prem AD can query and access resources (desktops) in the Tehama Room, but the Tehama Room can’t do the same in your on-prem AD. This limits your AD’s exposure to external threats.