Room Domain Join User Guide

Tehama offers a Domain Join feature for Tehama Gateway Rooms. This feature allows an organization to create a Gateway Room that has their network's domain joined to the Room, giving read-only access to the domain's objects, such as users and policies, to the Room.

The benefits of the Domain Join feature are:

  • The Room's members' Tehama login usernames (email addresses) are used as the login usernames for the desktops in the Room to which they are assigned.

  • Any policies found in the Room's organization's network domain will be applied automatically to the desktops in the Room.

DISCLAIMER: The Room Domain Join (Beta) feature is still undergoing development and is provided 'as-is', without any warranties or support, and Tehama will not be liable for any loss of data.


Domain Join Room Requirements and Limitations

Requirements:

  • You must have a Tehama organization.

  • You must have a network environment established.

  • You must be willing to run a Tehama Gateway connected to your Room from inside this network.

  • You must be willing to open your network's firewall (if you have one set up) to allow communication with the Tehama Gateway and with Tehama's Domain Join components for your Tehama Room.

  • This network environment must have a domain running in it.

  • You must have LDAPS configured on your Domain Controllers (DCs).

  • Your network domain must have two user accounts, a service user account and an admin user account, whose credentials you will share with Tehama. See Required Domain User Permissions for more information about the required domain user accounts.

  • Your network domain must not set any password rotation policies for the service and admin user accounts.

  • Your network domain must use private addresses as defined by RFC 1918:
    RFC 1918 defines the following address ranges as private,
    • 10.0.0.0/8 (addresses 10.0.0.0 through 10.255.255.255 inclusive)
    • 172.16.0.0/12 (addresses 172.16.0.0 through 172.31.255.255 inclusive)
    • 192.168.0.0/16 (addresses 192.168.0.0 through 192.168.255.255 inclusive)

  • You must be willing to share your network domain's credentials with Tehama.

  • The members in your Tehama organization, at least the ones you plan to add to your Room with domain join, must use their username (email address) from your network's domain as their Tehama username.

Limitations:

  • Tehama Rooms with Domain Join enabled are limited to desktops of type "Tehama Windows" only.

  • Members of Tehama Rooms with Domain Join enabled must connect to their desktops through the 'Connecting with credentials' methodology, using the Teradici PCoIP Client. (The automatic connect sequence provided by the Tehama Client is not supported.)

Required Domain User Permissions

You must create two accounts in your network domain, a service user account and an admin user account, whose credentials you will share with Tehama during the Domain Join Room setup process.

The admin account:

  • Usage:
    This account is used by Tehama to establish trust during the 'domain join' setup process, which occurs in the course of your Domain Join Room setup.
  • Permissions:
    This account must have the required permissions to set up a 'forest trust'. Typically, a domain administrator account will have these permissions.
  • Lifetime:
    This account only needs to exist while Tehama is setting up your Domain Join Room. You should delete this account after the Room is set up.

The service account:

  • Usage:
    This account is used by Tehama to authenticate users from your domain when they connect to their Tehama Desktops and at any other time that Tehama needs to access user details.
  • Permissions:
    This account must have read permission, at the root level, for all the users in your domain.
  • Lifetime:
    This account must continue to exist for the lifetime of your Tehama Domain Join Room. Do not delete this user while the Room exists.

Steps to enable a Domain Join Room

Note: These steps only require action from your organization, but Tehama Support is available to offer assistance.

Create and connect a "Domain Join" Tehama Room. This will give you a Room with network access mode set to Tehama Gateway, with your organization as both the Room's owner organization and its connected organization (owner+connected) and a default Desktop type of 'Tehama Windows'. You will not be allowed to invite any other organizations into the Room.

Steps:

A. Follow the instructions in the Create and connect a Domain Join Room section of the Getting Started with Tehama Installation guide, taking special note of these steps.

  1. Step 4 - Select Domain Join Room:
    Be sure to select the Domain Join Room option here. This leads you on the correct pathway for creating and connecting a Domain Join Room.

  2. Step 12 - Establish a Gateway Connection:
    Install a Tehama Gateway in your network, and open your network firewall to allow communication from the Tehama Room with your Gateway and with your network's Domain Controller(s).

    As documented in this step, follow the gateway installation instructions in the Tehama Gateway User Guide. There are three methods of installation: install from an AWS AMI, install from an automated-script and install using Docker. Select the method best suited to your circumstances.

    A common step in each installation method is to configure your network firewall (assuming your network has a firewall) so the Tehama Gateway instance you are installing can adequately communicate with your Tehama Room.

    In Domain Join Rooms, you must also open access in your network's Domain Controller(s) (DC) to a predefined set of ports, so that the Domain Join components in your Tehama Room can communicate with your DC(s) (via the Gateway). See the list of ports in section Ports to open for Room to DC communication.

    IMPORTANT Verify that the Tehama Gateway successfully connects to the Room. The Room status on the Room's STATUS page should be Connected (green).

  3. Steps 14, 15 and 16 - Connect to Domain:
    Connect your network's domain to the Room. You will need to enter your network domain credentials:
    • Domain name e.g.: name.tehama.io
    • Search base e.g.: CN=Users,DC=onprem,DC=com
    • Admin account name e.g.: myadminuser
    • Admin account password e.g.: adminpassw0rd
    • Service account name e.g.: myserviceuser
    • Service account password e.g.: servicepassw0rd

      Note: You will not be able to perform any Room administration, such as adding members or creating/assigning Desktop templates, while you are waiting for the Room to connect to your domain.

B. Set up firewall rules in your Tehama Room, as desired. (These rules control what can be accessed through the internet from your Room's desktops.)

Follow the instructions for how to add custom firewall rules to your Tehama Room in the Add Custom Rule section of the Firewall Rules User Guide.

Verify that the Room's firewall rules work as expected. Follow the instructions for how to test a connection with Tehama's Connection Test Tool in the Connection Test Tool User Guide.

C. Now your Domain Join Room is ready to be used. Proceed to add members to your Room and to create Desktops for them.

Follow the instructions for how to add members to your Tehama Room in the Add Room access for users/teams section of the Room Membership User Guide.

Follow the instructions for how to create Desktops in your Tehama Room in the Add a Desktop template section of the Desktops User Guide.


Ports to open for Room to DC communication

If the network your Domain Join Room is connected to has a firewall, open access in your network's Domain Controller(s) (DC) to the following ports so that the Domain Join components in your Tehama Room can communicate with your DC(s) (via the Gateway).

Service Port Protocol
DNS 53 tcp/udp
Kerberos 88 tcp/udp
ntp 123 udp
Endpoint Mapper (DCE/RPC Locator Service) 135 tcp
NetBIOS Name Service 137 udp
NetBIOS Datagram 138 udp
NetBIOS Session 139 tcp
LDAP 389 tcp/udp
SMB over TCP 445 tcp
Kerberos kpasswd 464 tcp/udp
LDAPS 636 tcp
Global Catalog 3268 tcp
Global Catalog SSL 3269 tcp
Dynamic RPC Ports 49152-65535 tcp

Maintenance of a Domain Join Room

  • IMPORTANT: Refrain from deleting/archiving your room without the assistance of Tehama Support.
    This is to ensure that all domain join artifacts are removed from your network when your Room is removed. Tehama Support will ask you to keep your Room's Tehama Gateway running while they perform the necessary domain join deactivation steps.

  • Only invite members to the Room who are members of your network domain.
    Unless a member is part of your domain, any Desktops assigned to them will be unable to authenticate them.

  • Keep your Tehama Gateway running and up-to-date.
    Domain Join requires that a Tehama Gateway be running in your network, in order to access your domain.


Troubleshooting

Issue: The user is unable to add a Desktop template and create a Desktop for a member of a Domain Join Room.

Possible reason: The member’s Tehama username (email address) may be different from the email address they have in the AD properties of the domain used by the Room.

Mitigation:

By default, Tehama queries your network domain's Active Directory (AD) (the domain you connected to the Room) by taking the member's Tehama email address and then looking that up in your AD by using mail OR userPrincipalName properties. If these properties do not contain the email address used by the member as their Tehama username, there is further configuration required. Determine which of the cases below the member falls into and take the appropriate action.

  • CASE A: If the member needs to be referenced by a different value other than his/her Tehama email, BUT can be found in the same mail or userPrincipalName AD properties, then provide that value to Tehama Support before attempting to assign desktops to the member. (This would apply to each member in your Domain Join Room with the same issue.) An example of this would be that the member used his/her personal email to onboard to Tehama but your AD references that user by company email address.

  • CASE B: If the member’s email addresses are referenced in a different AD property than mail or userPrincipalName, then provide this AD property to Tehama Support before attempting to assign desktops to the member.

  • CASE C: It’s possible there could be a combination of A and B above. An example of this would be that the member can only be found with a specific AD property where the values ARE NOT the member's Tehama username (email address). Provide both the name and value of this AD property to Tehama Support before attempting to assign desktops to the member.