Domain Joined Instances

Many enterprises and organizations rely on Microsoft Active Directory (AD) for provisioning user accounts, applying security policies to operating systems, and enabling access to applications. In classic on-premises environments, Windows operating systems are “joined to the (AD) domain” in order to enable these functions. Frame allows administrators to join their workload VMs to their Active Directory domain. This allows their users to log in to a Windows machine using their own AD credentials. Since the Windows operating system is joined to the customer’s domain, the user can use Windows applications that rely on AD for access, authentication and authorization, such as SAP apps. If the IT managers joins the Sandbox to the domain, they can use their existing app packages, app tools, and deployment processes to install, run, and manage their organization’s applications on Frame.

To use the Domain Join feature, you will need to utilize your own public cloud account or bring your own AHV cluster, where these Windows machines will be provisioned and orchestrated by the Frame Platform. This is called our Bring Your Own (BYO) infrastructure feature. Before continuing with this setup guide, you will need to set up your BYO infrastructure described in these articles: BYO AWS, BYO Azure, BYO GCP, or Frame on AHV.

This section of Frame documentation will outline the required steps to prepare and implement Domain Joined Instances (DJI) for your Frame account. Before reading the guides below, please review the requirements and recommendations for Domain Join to function properly on your Frame account.

Requirements:
  • Frame Account with Windows 10, Windows Server 2016, or Windows Server 2019-based image.

  • The Domain Join feature requires customers use Windows Server 2008 R2 and Domain Functional Level 2008 R2 or higher.

  • The Frame account workloads must reside in a VPC/VNET/VLAN with a non-overlapping CIDR with the rest of your network, including where your Windows domain controllers reside. Currently, Frame only supports subnet masks between /16 and /24.

  • The workload VMs to be joined to the domain must be able to route to the domain controller.

  • For customers using AWS, they must update their AWS IAM role before enabling DJI.

  • For customers using Azure, they must configure their Azure DNS before enabling DJI.

Considerations:

Please consider the following before moving on to the Domain Controller Preparation guide and setup process:

  • The Frame user created by Frame must be a local Windows administrator. Any GPO settings that take effect on workload instances must not remove this user from the “Local administrators” group.

  • Autologin must be allowed for a local Frame user session to initiate successfully. Any GPO settings that disable this function will prevent domain joined instances from working properly.

  • Interactive Logon message must be disabled in GPO settings for successful initiation of a Frame session.

  • The domain join feature does not join the Sandbox or any utility servers to the domain. Frame strongly advises that administrators do not manually join the Sandbox or the utility server to the domain unless there is a specific requirement for an application to function. If either of these two VM types must be joined to the domain, the Frame administrator should enable RDP and create another local Windows admin user in that server. Before the server is joined to the domain, the administrator should verify that they can reach the server using RDP.

  • Do not modify the Frame user local admin account password. We rotate the password for the Frame user (Frame guest agent) and modifying it will cause autologon to fail. For password security options like LAPS, there is a need to exclude the local Frame user.

  • Static DNS IPs are not supported and should not be entered in the Sandbox or workload VMs.

  • The local Frame user password is stored in LSA (Local Security Authority) portion of the machine registry that is accessible only to SYSTEM account processes. Some of these secrets are credentials that must persist after reboot and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:

    • Local Frame user password

    • Service account name and password for web proxy