Prerequisites
- The client domain server version should be Windows Server 2008 R2 or higher
- Access to the client DNS servers to set up DNS secondary zones or conditional forwarders
- Base Organizational Unit: This is a new organizational unit in the client domain where the group that includes the MSA accounts for the orchestration has full control. In this OU, there should be a user admin with delegated access to the active OU. In addition, new OUs, users groups and new machines will be created.
- A user account with Read Only access to configure the synchronization in the domain.
- Permissions to create group policies (gpo) in the Home OU, or 20 empty gpo should be available in the Home OU where these defined policies will be imported.
- Optional, a user account with enough permissions to add machine accounts to the domain.
- Verify and add the same NTP server for all the domains involved
- A share folder, DFS or a storage for the binary files, customization, scripts and branding.
- A group in the infrastructure domain to allow the client domain users to login in the infrastructure domain(It is normally called "users with authentication rights"); the Delivery Controller machines, Domain controllers, web and file servers(including DFS) should be enabled-> "allow to authenticate" (in the Active Directory VM account).
- Cross domain dns resolution. Choose one of the following:
- DNS Conditional Forwarders: for those domains where we don´t see any type of activities going on, or those that are very large or restrictive.
- DNS secondary zone: for an integrated and orchestrated domain
- GPOs have to be imported to the client domain. They should be enabled accordingly.
- The VDAs should include the name of the infrastructure domain secondary DNS as a suffix in their naming convention. The support registration should be enabled for multiple AD Forests(supportmultipleforests) in case it is disabled.
- The DCs should include the names of the secondary DNS as a suffix to their names, in each one of the associated domains.
Trust relationship
The Trust relationship between the infrastructure domain and the client domain should be created. The type of trust relationship should be: Forest Trust, two-ways, and selective authentication.
DNS Configuration
The DNS domain resolution between the infrastructure domain and the client domain can be configured in two ways:
- Secondary zones
- Conditional forwarders
Both are supported, depending on the level of complexity and the size of the client domain as well as the assigned permission level, you can decide which one to configure.
Required Groups
To meet the requirements, the following groups should either exist or be created in the home OU:
| Group | Name | Notes | Scope |
|
Double Factor authentication Group (Deprecated 4.4) |
VDI OS Double Factor Authentication | Includes users who can start a session in a virtual desktop via Token Based aunthentication | Local Domain |
| USB Redirection Group | VDI OS USB Redirection | Includes users who can use their local machine connected USB devices in their virtual desktops | Local Domain |
| COM redirection Group | VDI OS COM redirection | Includes users who can use their local machine COM' ports in their virtual desktops | Local Domain |
| LPT1 Redirection Group | VDI OS LPT1 Redirection | Includes users who can use their local machine LPT1 ports in their virtual desktops | Local Domain |
| Local Units Redirection Group | VDI OS Local Units Redirection | Includes users who can use their local machine physical disks in their virtual desktops | Local Domain |
| Audio Redirection Group | VDI OS Audio Redirection | Includes users who can redirect sound audio from their virtual desktops to their local machine | Local Domain |
| Printer Redirection Group | VDI OS Printer Redirection | Includes users who can use their local machine connected printers in their virtual desktops | Local Domain |
| TWAIN Redirection Group | VDI OS TWAIN Redirection | Includes users who can use their local machine connected TWAIN scanners in their virtual desktops | Local Domain |
| Network Drives Redirection Group | VDI OS Network drives Redirection | Includes users who can use their local machine network units in their virtual desktops | Local Domain |
Two things you should know about Groups:
- The name of the groups can be modified
- You can use existing groups in the client domain
Configure the new domain in Flexxible|SUITE
To import the new client domain to Flexxible|SUITE you should go to the Domains section and click on "New".
Then enter the information about the new domain:
We should provide the following data:
- The name of the new domain
- Contains multiple tenants: this checkbox must remain unchecked if this domain will be fully dedicated to a single tenant
- The NETBIOS name will be added automatically
- the AD GUID will be added automatically
- The Base OU
- The name of the AD attribute where the user's device registration for two factor authentication is stored, leave it blank if not using 2FA
- The Sync user credentials, to be used as the identity to perform any operation against the AD domain.
- The VM creation credentials used to create the machine accounts during new template or server creation from OS images.
In the bottom of the VDI OS Manager domain form, we will se several tabs:
In the User policies groups tab, you should include the groups that are needed for the orchestration:
In the Permissions tab, you should specify the permissions that the configured sync user have on this domain. See “Domain permissions”.
Once the new domain is saved, the Password policy tab will be visible. In this tab you can see the domain password policy, which is read from the AD domain by the "Synchronize infrastructure" periodic, automatic process.
Generally, you will not be able to manually edit this settings beyond the "Validate password policy" check box. You will only be able to manually edit the password policy settings in case the policy has never been synchronized from the AD domain -this could happen for many reasons, like the sync user not having enough permissions-. The settings you edit will not be applied to the AD Domain, they will only be kept in the Flexxible|SUITE database for account password validation purposes.
Validate password policy
Checking this option will enable password validation in Flexxible|SUITE for this domain, so when you create a new tenant user, or change an existing user's password, it will be checked against the domain password policy before saving the changes made to the user.
Stronger password complexity required
Indicates that the passwords will have to match additional complexity requirments, like containing alphabetic, uppercase, lowercase, numeric or symbol characters, as described in the text "Password policy description".
Minimum length
The minimum length in characters that a password must be.
Valid values range from 0 to 14. A zero value means that passwords are optional and don't have to meet any special requirement, but this is an insecure and unlikely value for a real world AD domain.
History count
The number of previous passwords that can't be re-used. That is, if you change a password and use again one of the last passwords, the password will be invalid.
Valid values range from 0 to 24. A value of zero would mean that you can always use the same password when you are required to change it, but again it is a very unlikely and insecure value for a real wold AD domain.
Minimum age
It is how old (specified in days.hours:minutes:seconds) must be a password before it can be changed again. Valid values range from 0 to 999 days.
Maximum age
It is how old (specified in days.hours:minutes:seconds) can be a password before it must be changed. Valid values range from 0 to 998 days.
If an existing user had a specific password policy different from the domain password policy, the "Update user" created when saving the tenant after modifying the user's password will fail and an error log line would be included specifying the specific password requirements for that particular user.
Note: password history is not checked, so if you use an old password not allowed by the policy, the "Update user" job might fail.