INUVIKA OVD VIRTUAL DESKTOP ENTERPRISE MICROSOFT ACTIVE DIRECTORY INTEGRATION Agostinho Tavares Version 1.0 Published 06/05/2015 This document describes how Inuvika OVD 1.0 can be integrated with Microsoft Active Directory based on Windows 2008 R2. www.inuvika.com
TABLE OF CONTENTS 1. INTRODUCTION... 3 1.1 Overview... 3 1.2 Microsoft Active Directory Setup... 3 2. CONFIGURATION... 4 2.1 Microsoft Active Directory Best Practices... 4 2.2 OVD Server DNS Configuration... 4 2.2.1 Ubuntu 14.04 LTS DNS Configuration... 4 2.3 Configure OVD to Use Active Directory... 5 2.3.1 Advanced Configuration Options... 6 2.3.2 Microsoft Active Directory With Multiple Domains... 7 3. USERS... 8 3.1 Using samaccountname... 8 3.2 Using userprincipalname... 8 4. USER GROUPS... 9 4.1 Using Active Directory User Groups... 9 4.2 Using Internal User Groups... 10 5. DOMAIN USERS... 11 5.1 Manage Users In OVD... 11 5.2 Manage Users In Active Directory... 11 6. SETTING READ ACCESS FOR A USER IN ACTIVE DIRECTORY... 13 7. ACTIVE DIRECTORY RECOMMENDED CONFIGURATION... 17 7.1 Dedicated Organization Unit... 17 7.2 Stop GPO Inheritance... 17 7.3 Recommended GPO... 18 Page 2
1. INTRODUCTION This document describes how Inuvika OVD 1.0 can be integrated with Microsoft Active Directory based on Windows Server 2008 R2. Using an example Active Directory, the document describes the alternative integration methods, and provides detailed instructions and best practices for using Microsoft Active Directory with Inuvika OVD 1.0. 1.1 OVERVIEW Inuvika OVD provides options for the level of integration with Microsoft Active Directory. As a minimum, integration with Active Directory means that users are defined within Active Directory and OVD will delegate user authentication to Active Directory. OVD will retrieve the list of users from Active Directory but will not modify any user data. The system administrator can further choose whether to define user groups within Active Directory or in OVD. In addition, there are two different modes of managing users when integrating with Active Directory. One option is to allow Inuvika to manage the creation of users, shared folders and user profiles. The second option is to use Active Directory to define the users, shared folders and user profiles. Before starting the integration with Active Directory, the decision on which options to use should be made. Each of the options is described in more detail below and can be configured in the OVD Administration Console (OAC) by selecting the Microsoft option of the Domain Integration Settings on the Configuration tab. 1.2 MICROSOFT ACTIVE DIRECTORY SETUP For the purposes of this documentation, we will use a Microsoft Active Directory domain called mydomain.inuvika.demo. In this example, the domain controller hosts Microsoft Active Directory Domain Services and the DNS Server. The domain controller FQDN is dc.mydomain.inuvika.demo. The Microsoft Active Directory used in this document is running on Windows Server 2008 R2 and is set to run at the 2008 R2 functional level. Page 3
2. CONFIGURATION This section describes how to configure OVD and Active Directory so that OVD can access data stored in Active Directory. 2.1 MICROSOFT ACTIVE DIRECTORY BEST PRACTICES Inuvika recommends the following best practices when integrating with Active Directory: 1. Define all the OVD objects within a dedicated Active Directory OU. These objects are: User groups specific to the OVD environment (if using Active Directory to define user groups) Windows OVD Application Servers (OAS) (when managing users in Active Directory) 2. Stop all domain wide custom policies at the OU level (no propagation of its content). If some policies are mandatory, they should be set after successfully integrating Active Directory with OVD to ensure they do not conflict with the integration. 2.2 OVD SERVER DNS CONFIGURATION Inuvika recommends configuring all the OVD servers in the farm to use the same DNS Server to simplify management. In our example, we are using the DNS Server on the domain controller. The following example describes how to configure and test the DNS configuration to allow the OVD Session Manager (OSM) to use the DNS Server running on the domain controller. 2.2.1 UBUNTU 14.04 LTS DNS CONFIGURATION Edit the network interface definition file used by this server nano /etc/network/interfaces and add the DNS server information # The primary network interface auto eth0 iface eth0 inet static address 192.168.0.100 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 192.168.0.199 dns-search mydomain.inuvika.demo Page 4
Save the file and check that the configuration is working correctly by searching DNS for the Active Directory domain controller, which in our example is dc.mydomain.inuvika.demo) nslookup dc If the system is setup correctly, the command should return something like: root@osm:~# nslookup dc Server: 192.168.0.199 Address: 192.168.0.199#53 Name: dc.mydomain.inuvika.demo Address: 192.168.0.199 Next check the DNS reverse name resolution using nslookup: nslookup 192.168.0.199 The command should output something like: root@osm:~# nslookup 192.168.0.199 Server: 192.168.0.199 Address: 192.168.0.199#53 199.0.168.192.in-addr.arpa name = dc.mydomain.inuvika.demo. 2.3 CONFIGURE OVD TO USE ACTIVE DIRECTORY To configure OVD to use Active Directory, login to the OAC, go to the Configuration tab and select Domain Integration Settings. On this page, select Microsoft from the drop down list. The system will display the following screen: Page 5
Enter the following information relevant to your configuration. Domain: enter the FQDN of the Active Directory Domain. In our example, this is mydomain.inuvika.demo Authentication: any user with the read all properties rights can be specified. Primary Host and Secondary Host fields are optional if the OSM server has been configured to use DNS as described above. Otherwise, enter either the FQDN of the main domain controller or the IP address. Authentication: OVD requires read-only access to Active Directory. Any standard user from the default Users container that has the read all properties enabled can be used. A user from another container will not have this attribute set and therefore requires further configuration (see Setting read access for a User in Active Directory for details) Test: The Test button performs a connection check. If everything is OK then the system will display information in the upper right corner of the screen in green. If there are any errors, then the error information will be displayed in red. Once the configuration has been defined and tested successfully, save the definitions using the Save button. To complete the configuration, refer to the Users, User Groups and Domain Users settings described in the next chapters. 2.3.1 ADVANCED CONFIGURATION OPTIONS It is possible to refine the connection details to Active Directory using the advanced options as shown below: LDAP port: The default port is 389. A different port may be used. Use LDAP encryption (SSL): checking this box enables LDAPs or LDAP over HTTPS. In this case, the TCP port must be changed from 389 to 636 when using the default port. Specific organization unit: an organization unit (OU) may be specified to filter the directory data. Data defined for other OU s will be ignored. Page 6
2.3.2 MICROSOFT ACTIVE DIRECTORY WITH MULTIPLE DOMAINS When using a Microsoft Active Directory that has multiple domains, the configuration must be changed as follows: Domain: the Active Directory domain (usually the root of the domain) Primary Host: this is optional if DNS is set up as described above. If required, enter the IP or FQDN of the server acting as the Global Catalog (GC) for the Active Directory forest. The Active Directory Sites and Services tool provided by Microsoft can be used to check the GC information in a forest LDAP port: When connecting to a Global Catalog, the TCP port to use is by default 3268 and 3269 when using SSL (LDAPs) Page 7
3. USERS When integrating with Active Directory, the OVD Users page in the OAC will always retrieve and display the set of users from Active Directory independent of other Active Directory integration choices. The user data cannot be modified within OVD, Active Directory must be used to modify any user data. OVD provides support for both the samaccountname (default) and the userprincipalname. Select the required option in the configuration page as shown below: In both cases, when more than the configured number of users are available (15 by default), a search field will be displayed to allow the search to be refined. Wild card characters can be specified such as * when specifying the text to use for the search. The number of users to display can be configured by the Maximum items per page setting available in the System Setting page in the Configuration tab in the OAC. 3.1 USING SAMACCOUNTNAME When this option is selected, OVD will map the user login name to the samaccountname. The samaccountname is limited to 20 characters and is typically of the form user10, no domain information is included. This option may be selected if user names will not exceed the 20- character limit. 3.2 USING USERPRINCIPALNAME When this option is selected, OVD will map the user login name to the userprincipalname. The userprincipalname is of the form user10@mydomain.inuvika.demo. This option should be selected if user names may exceed the 20-character limit imposed by the samaccountname. Page 8
4. USER GROUPS Irrespective of how users are managed, user groups can be defined using either Active Directory or OVD by selecting the relevant option in the configuration page as shown below: 4.1 USING ACTIVE DIRECTORY USER GROUPS When using Active Directory user groups, the user group data is defined in Active Directory and then retrieved by the OSM as read-only data. The data is used to publish OVD applications either using the OAC or via the OSM API. In this case, all the user groups to be used in OVD must be created and managed in Active Directory. Inuvika recommends using one or more dedicated OVD user groups, for example Inuvika Users and to perform a search to find the user group as in the example below should the number of user groups exceed the page limit setting. Page 9
Adding a user to or removing a user from a user group is performed within Active Directory using Microsoft tools such as the Active Directory Users and Computers snap-in: 4.2 USING INTERNAL USER GROUPS When using internal user groups, user groups are created using either the OAC or the OSM API, and stored in the OVD database. The list of available users will be retrieved from Active Directory by OVD, and can be added to a user group for resource publishing via the OAC or OSM API. This method can be useful when using a complex Active Directory with many OUs and user groups, or when there is limited access to Active Directory with no option to create specific OVD user groups. Page 10
5. DOMAIN USERS OVD Users can be managed within Active Directory or by Inuvika OVD by selecting the relevant option in the configuration page as shown below. There are important differences in functionality between these two options as described in detail in the following sections. 5.1 MANAGE USERS IN OVD To manage users in OVD select the option: Use internal method to handle users in OVD sessions. In this case, OVD will manage user profiles and shared folders using the OFS as well creating users on the relevant application servers. This mode is required if using both Linux and Windows application servers OVD manages user data persistency through the use of the OFS role which provides centralized Linux and Windows profile data management OVD manages user sessions: o The OVD Admin account (an OVD account local to the Windows application server) creates a user session on behalf of the user account on a Windows OVD Application Server (OAS) and creates a local user profile with TS/RDS local access o When a user logs off, the OVD Admin account deletes the local user session, backs up all user data to the OFS store (in the case that user persistency is enabled) o The OVD Admin account deletes the user from the local accounts on the Windows server Active Directory is used for user authentication and optionally for user groups. Other Active Directory services are not supported in OVD such as GPOs, network shares, application and printer publishing Windows OAS servers can be members of an Active Directory domain or simply running in a WORKGROUP 5.2 MANAGE USERS IN ACTIVE DIRECTORY To manage users in Active Directory, select the option: Use Active Directory to handle users in OVD sessions (not compatible with Linux applications). In this case, users are managed entirely in Active Directory, the OFS is not used for user profiles or shared folders. Page 11
This mode can only be used for a pure Windows OAS environment. Linux OAS servers are not supported in this mode. Microsoft roaming profiles are required to provide user profile data persistency within the OVD server farm (in the case of load balanced OAS Windows servers) A full Active Directory integration is provided including GPOs, network shares, application and printer publishing. See 7 Active Directory Recommended Configuration for further information on how to setup OVD in a full Active Directory environment Page 12
6. SETTING READ ACCESS FOR A USER IN ACTIVE DIRECTORY In this example, we have a specific account created in an OVD dedicated Organization Unit in Microsoft Active Directory. By default, users created outside the default Users container do not have the read all properties attribute which is required by OVD. In this example, our account is ovd-admin which is a domain user account. Start the Active Directory Users and Computers snap-in. Then select the domain object> View > Advanced Features Page 13
Now select domain object> properties Now click the Advanced button Page 14
Click Add and select the user account. Select the Properties tab: - In Apply to: select this object only - Select Read all properties Page 15
Click OK and save all changes Page 16
7. ACTIVE DIRECTORY RECOMMENDED CONFIGURATION 7.1 DEDICATED ORGANIZATION UNIT It is best to create a dedicated organization unit (OU) in Active Directory to make it easier to manage the OVD server deployment and other OVD objects such as user groups. Create all objects related to the OVD farm inside the OU if possible and particularly: User Groups (if defining user groups in Active Directory) Windows Application Servers (if managing users in Active Directory) 7.2 STOP GPO INHERITANCE It is highly recommended to stop domain GPO inheritance to avoid any possible negative impact of domain policies on the OVD environment. If some domain GPOs need to be applied to the OVD servers and users, those GPOs should be applied only after OVD has been successfully evaluated without them. This is important so that policies that may conflict with OVD or cause other problems can be isolated. Page 17
7.3 RECOMMENDED GPO Recommended GPOs will vary from one environment to another. It is recommended to check the Microsoft web site for the recommended GPOs in a Windows 2008 R2/ 2012 R2 environment. A GPO that must always be set for each Windows OAS is the User Group Policy loopback processing mode. When user profiles for both Windows workstations and Windows RDS servers are managed using Active Directory, if this policy is not set, registry settings from a Windows 8 system may be overwritten by Windows 2008 R2 registry settings. With this policy set replace this problem will not occur. Page 18