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-prem environments, Windows operating systems are “joined to the (AD) domain” in order to enable these functions. Frame allows administrators to join their cloud 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. IT managers can use their existing app packages, app tools and processes to install, run and manage their organization’s applications on Frame, because the Sandbox can be joined to the domain.
To use the Domain Join feature, you will need to utilize your own cloud account, where these Windows machines will be provisioned and orchestrated by the Frame Platform. This is called our Bring Your Own, or “BYO,” feature. Before continuing with this setup guide, you will need to set up your BYO described in these articles: BYO AWS, BYO Azure, BYO GCP, or Xi Frame on AHV.
This section of Xi Frame documentation will outline the required steps to prepare and implement Domain Joined Instances for your Xi Frame account. Before reading the guides below, please review the requirements and recommendations for Domain Join to function properly on your Frame account.
Xi Frame Account with Windows Server 2016 or Windows 10-based image.
Xi Frame Solutions Architecture requires customers use Windows Server 2008 R2 and Domain Functional Level 2008 R2 or higher for Domain Joined Instances.
Each account must be in a unique CIDR. Currently, Frame only supports subnet masks between /16 and /24.
An established peering connection to the domain controller or an “always on” VPN Connection to the domain controller.
Customers using Azure must apply custom DNS configurations.
The Frame user created by Frame must be a local 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 to the domain. Frame strongly advises that administrators do not manually join the Sandbox to the domain unless there is a specific requirement for an application to function.
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.
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