INUVIKA TECHNICAL GUIDE

Transcription

1 Version 1.6 December 13, 2018 Passing on or copying of this document, use and communication of its content not permitted without Inuvika written approval

2 PREFACE This document describes how to integrate Inuvika OVD 2.x with Microsoft Active Directory based on Windows 2012 R2. Page 2

3 HISTORY Version Date Comments Updates for OVD 2.5, Add Windows 2016 support and correct typos Reformatting Updates for OVD Updates for OVD Incorporate changes for OVD Incorporate SSL configuration information and corrections Initial version Page 3

4 TABLE OF CONTENTS 1 Introduction Overview Microsoft Active Directory Setup Configuration Microsoft Active Directory Best Practices OVD Server DNS Configuration Ubuntu LTS DNS Configuration Configuring OVD to Use Active Directory Advanced Configuration Options Microsoft Active Directory With Multiple Domains Users Using samaccountname Using userprincipalname User Groups Using Active Directory User Groups Using Internal User Groups Domain Users Manage Users In OVD Manage Users In Active Directory Setting read access for a User in Active Directory 17 7 Active Directory Recommended Configuration Dedicated Organization Unit Stop GPO Inheritance Recommended GPOs Session Time Limit Settings Inuvika OVD Service Considerations LDAPS Configuration Overview DNS Configuration Active Directory Configuration Certificate Export Session Manager Configuration Certificate Import Administration Console Configuration Verification steps Problem Determination Page 4

5 1 INTRODUCTION This document describes how to integrate Inuvika OVD 2.x with Microsoft Active Directory based on Windows Server 2012 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 2.x. A section describing the implementation steps for providing secure access to the Active Directory server is also included. 1.1 OVERVIEW Microsoft Active Directory is an object directory server and facilitates user authentication and access control in a common domain. The Active Directory domain may be a single domain, or a sub-domain that is part of the Active Directory forest. To allow an organization to benefit from using their Active Directory server, Inuvika provides built-in integration so that user and group management is centralized. There are several options for configuring 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. This allows the enterprise to manage users and passwords together with related policies in a single centralized manner. The system administrator can further choose whether to define the user groups that will be used by OVD, in 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 OVD to manage the creation of shared folders and user profiles. The second option is to use Active Directory to define the shared folders and user profiles. For security reasons, the system administrator may also wish to implement SSL communication channels to secure the data transmission between the Active Directory server and the OVD Session Manager. Finally, if the System Administrator may wish to implement Windows Single Sign-On (SSO) using Kerberos. The steps for implementing Windows SSO are described in the document Single Sign-On with Microsoft Active Directory using Kerberos. Before starting the integration with Active Directory, the decision on which options to use should be made. Each of the options (except for SSO) 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. A further section describes the steps for implementing secure data transmission. 1.2 MICROSOFT ACTIVE DIRECTORY SETUP For the purposes of this documentation, we will use a Microsoft Active Directory domain called domain.test.demo. In this example, the domain controller hosts Microsoft Active Directory Domain Services and the DNS Server. The domain controller FQDN (Fully Qualified Domain Name) is dc.domain.test.demo with the IP The Microsoft Active Directory used in this document is running on Windows Server 2012 R2 and is set to run at the 2012 R2 functional level. Page 5

6 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 the example in this document, the DNS Server is provided by the Active Directory 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 UBUNTU LTS DNS CONFIGURATION Edit the network interface definition file used by this server nano / etc / network / i n t e r f a c e s and add the DNS server information #The primary network i n t e r f a c e auto eth0 i f a c e eth0 inet s t a t i c address netmask gateway dns nameservers dns search domain. t e s t.demo 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.domain.test.demo**** nslookup dc If the system is setup correctly, the command should output information similar to the following: root@osm:~# nslookup dc Page 6

7 Server : Address : #53 Name: dc. domain. t e s t.demo Address : Next check the DNS reverse name resolution using nslookup: nslookup The command should output something similar to the following: root@osm:~# nslookup Server : Address : # in addr. arpa name = dc. domain. t e s t.demo 2.3 CONFIGURING 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: Figure 1: MS AD Integration Enter the following information relevant to your configuration. Page 7

8 Domain: enter the FQDN of the Active Directory domain (the domain name must be defined in lowercase). In the example, this is domain.test.demo 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 or IP address of the Domain Controller. 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. Please refer to Chapter Setting read access for a User in Active Directory for further 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 information about the error 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 sections ADVANCED CONFIGURATION OPTIONS It is possible to refine the connection details to Active Directory using the advanced options as shown below: Figure 2: LDAP settings LDAP port: The default port is 389. A different port may be used corresponding to the port defined on the Active Directory server. Use LDAP encryption (SSL): checking this box enables LDAPS (LDAP over SSL). In this case, the TCP port must be changed manually from 389 to 636 when using the default port. Further details are provided in Section 8 LDAPS Configuration. Specific organization unit: an organization unit (OU) may be specified to filter the directory data. Data defined for other OU s will be ignored. LDAP connection timeout: the timeout value in seconds to be used when executing LDAP requests to the Active Directory server. A value of 15 seconds is used by default. This value is shared by the Active Directory and LDAP integrations. Page 8

9 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: Figure 3: Multiple domains 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 9

10 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: Figure 4: Users settings 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. Figure 5: Users search 3.1 USING SAMACCOUNTNAME When this option is selected, OVD will map the user login name to the samaccountname. samaccountname is limited to 20 characters and is typically of the form user10, no domain information is included. This option is the default one. The 3.2 USING USERPRINCIPALNAME When this option is selected, OVD will map the user login name to the userprincipalname. userprincipalname is of the form user10@domain.test.demo. This option should be selected if user The Page 10

11 names may exceed the 20-character limit imposed by the samaccountname and the domain part). Page 11

12 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: Figure 6: User groups settings 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. Figure 7: User groups search 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: Page 12

13 Figure 8: Add user in MS AD Page 13

14 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 14

15 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. Figure 9: Domain users settings 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: 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 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) 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. This mode can only be used for a pure Windows OAS environment. Linux OAS servers are not supported in this mode. Not all Session Manager settings apply 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). Page 15

16 A full Active Directory integration is provided including GPOs, network shares, application and printer publishing. See Chapter 7 Active Directory Recommended Configuration for further information on how to setup OVD in a full Active Directory environment Page 16

17 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 admin which is a domain user account. Start the Active Directory Users and Computers snap-in. Figure 10: Read Access for a User Then select the domain object / View / Advanced Features Now select domain object / properties Now click the Advanced button Click Add and select the user account. Select the Properties tab: In the Apply to drop down, select this object only Select Read all properties Click OK and save all changes. Page 17

18 Figure 11: Advanced features Page 18

19 Figure 12: Domain Properties Page 19

20 Figure 13: Domain Properties - Access Page 20

21 Figure 14: Add user for Admin rights Page 21

22 Figure 15: Permissions tab Page 22

23 Figure 16: Read Access for a User Page 23

24 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. Figure 17: Dedicated Organization Unit 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. 7.3 RECOMMENDED GPOS Recommended GPOs will vary from one environment to another. It is recommended to check the Microsoft web site for the recommended GPOs for a Windows 2016, 2012 R2, or 2008 R2 server. Page 24

25 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 to Replace this problem will not occur. Figure 18: User Group Policy loopback processing mode 7.4 SESSION TIME LIMIT SETTINGS The session time limit settings available in the OVD Administration Console are not usable when Active Directory is configured to manage users (Section 5.2 Manage Users In Active Directory). The Sessions Time Limits settings for this configuration can be set using Group Policies. The relevant Group Polices are located under Computer Configuration>Administrative Templates>Windows Components>Remote Desktop>Services>Session Time Limits as shown in the screenshot below. Set the values Page 25

26 Figure 19: Session Time Limits Page 26

27 that you require using these parameters. 7.5 INUVIKA OVD SERVICE CONSIDERATIONS In a full Active Directory environment, some additional configuration settings are required to be applied on all the OAS Windows servers involved in an OVD farm. Two OVD applications need to be published in the RemoteApp Manager. In Windows Server 2008 R2, use the MMC snap-in called Remote App Manager on every individual RDSH server to publish the applications. On Windows Server 2012, management of Remote Apps can be performed centrally in the Server Manager. In both cases, the OVDDesktop.exe and OVDRemoteApps.exe applications must be published. The screenshot below shows these applications being published in a Windows Server 2008 environment. Figure 20: RemoteApp Manager These two OVD applications are not managed by OVD when the full AD mode is configured. They must be published as RemoteApps and also be allowed to run as the initial program when an OVD session is started. For each OAS Windows server, select the RDSH Configuration and modify the RDP-Tcp Properties to apply the setting Run initial program specified by user profile and Remote Desktop Connection or Terminal Services client as shown below. Alternatively, the Allow remote start of unlisted programs GPO can be modified to specify that remote users can start any program on the RDSH server. The full path for the GPO is Computer Page 27

28 Figure 21: RDP-TCP properties Page 28

29 Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections as shown in the screenshot below. Figure 22: Allow remote start of unlisted programs Page 29

30 8 LDAPS CONFIGURATION 8.1 OVERVIEW In order to enable Active Directory and OVD to use Transport Layer Security (TLS) for communication, an X.509 certificate must be configured for use with Active Directory. The certificate may be a commercial SSL certificate or a self-signed certificate. The OVD Session must be configured so that it can trust the certificate. The port used for the communication between the Active Directory server and the OVD Session Manager, by default 636, must be open. The sections below describe the steps required to implement secure data transmission between Active Directory and the OVD Session Manager. 8.2 DNS CONFIGURATION It is very important that the correct DNS configuration entries are made so that the reverse and forward lookup for the Active Directory server are possible. Warning The DNS server needs to have records containing the FQDN of the Active Directory server, the FQDN for the OSM and the short hostname. This is crucial so that the reverse name lookup using the PTR record will match and the common name in the certificate can be correctly resolved. 8.3 ACTIVE DIRECTORY CONFIGURATION In most cases, the Active Directory Domain Controller would typically be the Certificate Authority for any workstations or users that belong to its domain. To create this environment, the Active Directory Certificate Services server role should be installed on your Active Directory server. When performing the installation, ensure that the Certification Authority Role Service is installed and that Enterprise is chosen when specifying the setup type. Active Directory must be configured with its own X.509 certificate and private key, and the associated CA certificate(s). The CN attribute in the certificate must carry the server s FQDN and match the records in the DNS server. Refer to the available Microsoft documentation for instructions on configuring Active Directory. Ensure the OSM is configured to use the same DNS server as the Active Directory server as described in section 2.2 OVD Server DNS Configuration. The Certificate Services installation wizard will allow you to create a self-signed CA certificate that can be used for SSL connections to Active Directory. Because the certificate is self-signed and does not use a publicly trusted Certificate Authority, there are further steps involved so that the certificate can be trusted by the OSM. These steps are described in the section below. If a commercial SSL certificate is used, the certificate must be imported into Active Directory as normal but it should not be necessary to import the certificate into the OSM. Page 30

31 8.3.1 CERTIFICATE EXPORT Once the SSL certificate is available and has been installed in Active Directory, the OSM must be configured to trust the certificate. The first step of this process is to export the certificate as a base-64 encoded X509 file. The file must then be copied to the Session Manager server so that it can be installed. 8.4 SESSION MANAGER CONFIGURATION Configuring the Session Manager consists of importing the X509 certificate if required and then configuring OVD to use SSL CERTIFICATE IMPORT The example below presents the steps to follow for the case where a single CA has been used to create the SSL certificate. This approach can be extrapolated to cases where multiple CAs are involved. 1. Copy the certificate file exported from Active Directory to the directory /etc/ssl/certs/. 2. Edit the /etc/ldap/ldap.conf file and add this entry: TLS_CACERT / etc / s s l / certs / <ca. cer > where ca.cer is the file containing the base-64 encoded certificate that was exported from Active Directory. Then save the file and exit. 3. Run the following openssl command (change ca.cer to the name of the certificate from step 1): openssl x509 in / etc / s s l / certs / ca. cer noout text subject sed n ' / \ subject / s /. * CN=//p ' 4. With the IP and hostname that results from the previous step, do the following: (a) Edit your /etc/hosts file and add the IP and hostname (b) Update the resolv.conf file (at /etc/resolvconf/resolv.conf.d/base in Ubuntu) with the DNS server set to the IP of the Active Directory Domain Controller 5. Restart Apache to apply the changes: Ubuntu: service apache2 r e s t a r t RHEL/CentOS 7: service httpd r e s t a r t Depending on the version of Linux and the packages installed on the OSM, a reboot of the LDAP service may be required for the TLS_CERT entry to be loaded. It is easiest to perform a reboot of the entire server to ensure it is loaded. Page 31

32 8.4.2 ADMINISTRATION CONSOLE CONFIGURATION In the OVD Administration Console (OAC), go to the Configuration tab and select Domain Integration Settings. On this page, select Microsoft from the drop down list. The SSL settings are listed under the Server section. Check the SSL box to enable LDAPs. Then change the TCP port (LDAP Port) from 389 to 636 if you are using the default port. When setting the hostname (Domain or Primary Host), the value should match the hostname generated by step 3 in section It must be the FQDN and not just the IP, otherwise the cert will be mismatched and it will not honor the authentication. 8.5 VERIFICATION STEPS After completing the configuration, use the TEST button to perform a configuration check. If the test is successful, the results are annotated in green. If the test has errors, the results are annotated in red. If the results are green, users may login to OVD and will be authenticated by Active Directory using the secure channel PROBLEM DETERMINATION Depending on the errors displayed after performing the test, please check the following cases: Port 636 is not open To check that port 636 is open, do the following: Windows: # netstat an p tcp find "636" This should output data similar to the following: Proto Local Address Foreign Address State TCP : : 0 LISTENING Linux: # netstat an4 grep i "636" This should output data similar to the following: tcp : : * LISTEN The address denotes that it is listening and allows inbound outboard IPs to accept/receive traffic to port 636. If you have communication issues or disruption it may be due to firewall restrictions either on the server or imposed by an external firewall. Ensure that the external firewall is configured to allow LDAP/LDAP and MS Domain Services. A further check is to perform a telnet request from the OSM to the Active Directory server using port 636 to ensure that communication can be established. Page 32

33 DNS Issues Check that the DNS is correctly configured and use the nslookup command to verify that the hostname is correctly resolved. Also check that the DNS server is correctly configured on the OSM. If the Microsoft Active Directory server is acting as the DNS server, ensure that the OSM DNS server corresponds to the IP address of the Active Directory server. Page 33