A Terminal Policy groups together a set of terminals (flexVDI Client software). When a terminal identifies itself with its TID, the Manager selects a Terminal Policy for it:
- It first looks for a Terminal Policy that
- already has this TID registered.
- If the TID is not yet registered with any policy, the Manager looks for a Terminal Policy named after the host name that the client used to establish the connection with the Manager. More later on Named Terminal Policies.
- If it cannot find it, the TID is associated with the Terminal Policy named "default".
The Manager then uses the Terminal Policy to get the list of Desktop Policies that will be presented to the user. In an unauthenticated policy, this list is directly stored in the policy. In an authenticated one, the list is retrieved from an LDAP server.
You can see how to configure an authenticated policy in the First steps guide.
In many scenarios, you will want to have different authentication domains; e.g. different LDAP branches for each department in a big company, or even different LDAP servers for each client in a multi-tenancy platform. You need to create a different policy for each domain. However, manually registering terminals to each policy can be an cumbersome task. Named Terminal Policies solve this problem by associating a Terminal Policy with the host name the clients are using to connect with the Manager:
- Create an entry in your DNS servers associating your platform IP address with a different name for each authentication domain. E.g. accounts.mycompany.com and hhrr.mycompany.com.
- Create a Terminal Policy for each of these names, and configure their authentication parameters accordingly.
- Instruct your users to connect to your flexVDI platform using the appropriate name. E.g. users from the accounts department will enter "accounts.mycompany.com" in the hostname field of the flexVDI Client.
Usually, you will want your "default" Terminal Policy to be authenticated and/or use named policies. In this way, your users will be able to move to new, unregistered terminals (like their phone or tablet, or a new computer) and still be able to access the platform without you having to register the new terminals explicitly. Then, you can create additional unauthenticated policies for public kiosk-type terminals. Other common groups of terminals are classrooms, laboratories, office floors, etc. You will seldom create additional authenticated Terminal Policies. You will only need them if you have users in different branches of the LDAP directory, or even in different LDAP servers. But then, you will have to register terminals with these policies manually.
Use a desktop attribute that already exists in your LDAP directory schema, but is not in use, so that you do not need to modify the schema. If you are using an Active Directory, a suitable attribute would be "info" (or Comment in the AD nomenclature). It can be easily edited with the "AD Users and Computers" tool, where it appears as a big text box labeled "Notes", for both users and groups.