Skip to main content

Domain

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.

Domain Joined Instances

Using the Domain Join feature requires the use of your own public cloud account or AHV cluster where the Windows machines will be provisioned and orchestrated by the Frame Platform. This is known as the "Bring Your Own (BYO) Infrastructure" feature. Before configuring your Domain for use with Frame, you will need to set up your BYO infrastructure as described in the BYO Infrastructure section of our documentation.

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.
  • Customers using AWS infrastructure must update their AWS IAM role before enabling DJI (as described in the guide listed below).
  • Customers using Azure infrastructure must configure their Azure DNS before enabling DJI (as described in the guide listed below).

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. Modifying the password 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.
  • Restricting remote RPC connections to the Windows Security Account Manager (SAM) on a domain controller to Administrators only may introduce issues with renaming computer objects in Active Directory. Delegated rights to the service account will be ignored if this policy is configured
  • 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