INUVIKA TECHNICAL GUIDE

--------------------------------------------------------------------------------------------------- INUVIKA TECHNICAL GUIDE SINGLE SIGN-ON WITH MICROSOFT ACTIVE DIRECTORY USING KERBEROS OVD Enterprise External Document Version 1.0 Published ----------------------------------------------------------------------------------------------------------------------------------------- Passing on or copying of this document, use and communication of its content not permitted without Inuvika written approval

PREFACE This document explains the steps to implement a Single Sign-On for users of Inuvika OVD with a Microsoft Active Directory integration using Kerberos. Page 2

HISTORY Version Date Author Comments mm-dd-yy 1.0 11-17-15 Julien Langlois/Richard Tang Initial version Page 3

TABLE OF CONTENTS 1. INTRODUCTION... 7 1.1 Active Directory and Kerberos Auth Method... 7 1.1.1 Understanding Kerberos Concepts... 7 1.2 OVD and SSO... 7 1.3 Related Documentation... 8 2. PRE-REQUISITES... 9 2.1 Server Environment... 9 2.2 Workstation and Domain Account... 9 2.3 Client Compatibility... 10 2.4 Integrating Microsoft Active Directory with OVD... 10 3. NETWORK OVERVIEW... 11 4. SESSION MANAGER CONFIGURATION... 12 4.1 FQDN and DNS Compatiblity... 12 4.1.1 System hostname definition... 12 4.1.2 Active Directory DNS... 13 4.2 Time Synchronization... 13 4.3 Install and Configure Kerberos... 14 4.3.1 Verification... 16 4.4 Joining the Domain... 17 4.5 Active Directory Users and Computers... 18 4.6 Create a Service Ticket... 22 4.7 Apache and Kerberos... 24 4.7.1 Validate the Configuration... 25 4.8 Kerberos and OVD... 28 5. OWA HTML5 CLIENT... 30 6. EDC AND OWA JAVA CLIENT... 31 6.1 Workstation Configuration... 31 6.1.1 AllowTGTSessionKey... 31 6.1.2 Enable DES... 31 6.2 EDC... 33 6.3 Web Access... 33 7. TROUBLESHOOTING... 35 7.1 Validate Test Case... 35 7.2 OWA HTML5... 35 Page 4

7.3 EDC and OWA Java Client... 36 Page 5

CONVENTIONS The table below shows the typing conventions used in this document. These conventions denote a special type of information. Typing convention Information type Bold-face text Italics Double Quotes Dialog fields Commands Buttons File names Document titles Document references Menu Options Page 6

1. INTRODUCTION 1.1 ACTIVE DIRECTORY AND KERBEROS AUTH METHOD The Kerberos authentication protocol provides a mechanism for authentication - and mutual authentication - between a client and a server, or between one server and another server. Microsoft's Active Directory is an implementation of a Kerberos authentication realm. Kerberos enabled servers with the authentication realm will allow users to sign-in to Windows workstations that are joined to the Microsoft Domain and to access resources in that domain. A user does not need to provide the authentication credentials again once signed-in. This is known as Microsoft Single Sign-On (SSO). A detailed overview of Microsoft and Kerberos authentication can be found at: https://technet.microsoft.com/en-us/library/cc780469%28v=ws.10%29.aspx 1.1.1 UNDERSTANDING KERBEROS CONCEPTS The Kerberos authentication protocol is standard on all versions of Windows. A typical Kerberos implementation consists of 3 server entities: Key Distribution Center (KDC) which typically is installed on the Domain Controller (the primary Microsoft Active Directory server); A client workstation that is a part of the domain; and A server with the desired service to access. An overview of a typical Kerberos workflow can be found at: https://msdn.microsoft.com/en-us/library/bb742516.aspx 1.2 OVD AND SSO The default Inuvika OVD authentication method requires a login and password and uses the internal MySQL database to store the user credentials. OVD can also be configured to use external authentication services such as LDAP, Novell, and Microsoft Active Directory. A Single Sign-On mechanism aims to authenticate a user only once on a secure authorization platform and then connect the user to the various external resources by re-using the credentials. OVD is compatible with several SSO solutions such as CAS and SAML2. Integrating OVD with Active Directory SSO will provide users a way to login to an OVD session without sharing any login details; instead, the credentials previously delivered by Active Directory Page 7

during the initial authentication process, will be re-used. The following sections describe the configuration process that enables OVD to use SSO with Active Directory. 1.3 RELATED DOCUMENTATION The following OVD Enterprise documentation is available for download at http://docs.inuvika.com. Microsoft Active Directory Integration Guide OVD Administration Guide SAML 2.0 Configuration Guide CAS Authentication Guide Page 8

2. PRE-REQUISITES 2.1 SERVER ENVIRONMENT The server environment must include a Microsoft Domain Controller as well as a typical OVD server farm. The Microsoft Domain Controller (DC) must have the following characteristics: Active Directory is installed and functional DNS Server is installed and functional Configured as an NTP host server Microsoft functional level 2003, 2008R2, or 2012R2 The OVD server farm must be able to access the Domain Controller and vice-versa. The OVD farm consists of the following: A server that has the OVD Session Manager, Web Access and Admin Console An OVD Application Server (ApS), either Windows or Linux or both An OVD File Server (OFS) Notes: If OVD was configured to use the internal authentication method, any publications will need to recreated after changing the authentication method. It is important to perform backups of your running OVD farm and Microsoft Active Directory server prior to executing any integration steps outlined from this point onwards. It is preferable to test your integration by cloning the servers or to re-create a new isolated environment so that you can conduct comprehensive testing of the OVD SSO integration. An isolated environment is required so that your production environment will not recognize the cloned Domain Controller to avoid any negative Domain Controller policy propagation. The ApS cannot be installed on the same server as the Session Manager. There will be a configuration conflict otherwise which will prevent the system from working correctly. 2.2 WORKSTATION AND DOMAIN ACCOUNT SSO integration requires that the user login with a user account managed by Microsoft Active Directory and also that the workstation is joined to the domain. Page 9

2.3 CLIENT COMPATIBILITY SSO is not compatible with all OVD client software. The OVD client must run on the Windows workstation that is joined to the domain. SSO is compatible with the OVD Enterprise Desktop Client and OVD Web Access, both Java and HTML5, using a Windows workstation. It is not compatible with the Enterprise Mobile Client (Android, ios) or the Enterprise Desktop Client on Linux and Mac platforms. Note: The configuration is not the same for OWA/Java and OWA/HTML5. 2.4 INTEGRATING MICROSOFT ACTIVE DIRECTORY WITH OVD OVD must be configured to use the Active Directory authentication method. Please refer to the Microsoft Active Directory Integration Guide for detailed instructions. For information about the Domain Integration Settings in the OVD Administration Console, please refer to the OVD Administration Guide. In the Domain Users section of the configuration page, ensure that the Use Internal method to handle users in OVD Sessions option is selected. The Use Active Directory to handle users in OVD sessions option is not compatible with Single Sign-On. After changing the authentication method, users must be assigned to the relevant user groups and publications created so that they can create a session. Session Data and user profiles that were created when Internal Authentication was enabled will no longer be accessible after switching to Active Directory. After creating the publications, verify that users can create access OVD correctly by having them login in and confirm that they see the same applications as before the modifications for Active Directory. Note: Windows 2003 limits the hostname of the server and the DNS entry to 8 characters. Page 10

3. NETWORK OVERVIEW Figure 2: A standard OVD Network with a Microsoft Domain Controller Note: In the figure above, the Microsoft Domain Controller is dc.test.demo and Session Manager is osm.test.demo. Page 11

4. SESSION MANAGER CONFIGURATION The Session Manager support for Windows SSO is based on using Samba to manage the Kerberos keytab, which is a file containing pairs of Kerberos principals and encrypted keys, and the krb5- user software which provides basic programs to authenticate using MIT Kerberos. The following sections describe how to setup Samba on the Session Manager server to provide this capability. For the purposes of this document, the instructions provided apply to an Ubuntu 14.04 installation. 4.1 FQDN AND DNS COMPATIBLITY Windows Kerberos requires the use of FQDNs (Fully Qualified Domain Name), it will not work with IP addresses. Each server in a Kerberos authentication realm must be assigned a FQDN that is forward-resolvable. The Kerberos protocol also expects the server s FQDN to be reverseresolvable. The reverse and forward lookup for a FQDN can be tested using the nslookup command. 4.1.1 SYSTEM HOSTNAME DEFINITION Before proceeding, make sure that the Session Manager server is correctly configured to reply to the command hostname f. The expected response is osm.test.demo. 1. Log-in to the OSM server. 2. Make sure the system hostname is defined correctly in the system hostname configuration file. This file is located in the /etc/ folder. 3. Edit the /etc/hosts file and ensure it contains the following lines, using the IP address applicable to your environment: 192.168.0.201 osm.test.demo osm 4. If you made any modification to the hostname configuration file or the /etc/hosts file, please reboot your server. 5. Test the configuration by logging into a console and entering the command: hostname -f This should return osm.test.demo. Page 12

4.1.2 ACTIVE DIRECTORY DNS Using the DNS server that is provided on the Active Directory server simplifies the requirements for FQDN when using Kerberos. To check that the DNS server is working correctly, perform the following steps: 1. Edit /etc/resolv.conf on the Session Manager server and ensure that the name server is the Domain Controller s IP address. nameserver 192.168.0.200 search test.demo 2. Save the file and verify that the name resolution works. ping dc.test.demo 4.2 TIME SYNCHRONIZATION Time Synchronization is critical for Kerberos authentication to work. The Domain Controller should be configured as the local network s time server (NTP server). Configure the Session Manager server to synch with the Domain Controller, and the Domain Controller to sync each hour against a reliable outside source. Make sure the clock time of the Domain Controller, the client workstation and Session Manager server are in sync. If the time difference is greater than five minutes, Kerberos may not work correctly. NTPD is a Linux software service to synchronize the time over the network using NTP (Network Time Protocol). This package should be installed and configured on the Session Manager server. 1. Install the package using the following commands: apt-get install -y ntp service ntp stop 2. Synchronize the time by using the following command: ntpdate dc.test.demo Page 13

3. Open the /etc/ntp.conf file a. comment all the lines starting with server # more information #server 0.ubuntu.pool.ntp.org #server 1.ubuntu.pool.ntp.org #server 2.ubuntu.pool.ntp.org #server 3.ubuntu.pool.ntp.org #Use Ubuntu s ntp server as a fallback #server ntp.ubuntu.com b. then set the Domain Controller as the ntp server server dc.test.demo 4. Restart the service service ntpd start 4.3 INSTALL AND CONFIGURE KERBEROS On the Session Manager server, install and configure the Kerberos package called Krb5-user. Then configure Kerberos to authenticate in the Active Directory domain. 1. Install the Kerberos package apt-get install -y krb5-user 2. Backup the Kerberos configuration file mv /etc/krb5.conf /etc/krb5.conf.old Page 14

3. Create a new file called /etc/krb5.conf and copy & paste the following lines into the file: [libdefaults] default_realm=test.demo default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 allow_weak_crypto = true kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true fcc-mit-ticketflags = true default_keytab_name = FILE:/etc/krb5.keytab [realms] test.demo = { } kdc = dc.test.demo master_kdc = dc.test.demo admin_server = dc.test.demo default_domain = test.demo [domain_realm] test.demo = TEST.DEMO [logging] kdc = FILE:/var/log/krb5/krb5kdc.log a. Replace dc.test.demo by the FQDN of the Domain Controller of your Active Directory domain b. Replace test.demo by the Active Directory domain name c. Replace TEST.DEMO by the Active Directory domain name in upper case characters Notes: The allow_weak_crypto = true line is necessary only for Windows 2003 Domain Controllers. If your environment is using Windows 2008R2 or Windows 2012R2 as a Domain Controller, omit this line. The rdns parameter should be set to false if your DNS server has not been configured to support reverse look-ups. If you have reverse DNS enabled, set rdns =true. Page 15

4. Create the corresponding log directory /var/log/krb5 corresponding to the configuration file entry: mkdir p /var/log/krb5 touch /var/log/krb5/krb5kdc.log touch /var/log/krb5/kadmind.log 4.3.1 VERIFICATION To verify that the installation and configuration were successful, perform the following test using kinit: kinit john@test.demo Password for john@test.demo: Note: You can use any Active Directory account for the test with or without the realm (user or user@domain). In the above example, the user is John. Check that the Ticket Granting Ticket (TGT) is correctly configured by using the following commands: klist Information similar to that shown below should be displayed: Ticket cache: FILE:/tmp/krb5cc_0 Default principal: john@test.demo Valid starting Expires Service principal 07/20/15 16:08:51 07/21/15 02:08:54 krbtgt/test.demo@test.demo renew until 07/21/15 16:08:51 In order to destroy the active TGT, enter the following command: kdestroy Page 16

4.4 JOINING THE DOMAIN The next step is to install and configure Samba so that the Session Manager server can be added to the Active Directory domain using Kerberos. 1. Install the Samba package apt-get install -y smbclient 2. Take a backup of the samba configuration file smb.conf, using the command below: mv /etc/samba/smb.conf /etc/samba/smb.conf.old 3. Create a new /etc/samba/smb.conf file and copy/paste the following lines into it: [global] netbios name = osm realm = TEST.DEMO security = ADS encrypt passwords = yes password server = dc.test.demo workgroup = TEST kerberos method = dedicated keytab dedicated keytab file = /etc/krb5.keytab a. Replace dc.test.demo by the FQDN of the Domain Controller of your Active Directory domain b. Replace TEST.DEMO by your Active Direcory domain in upper case characters c. Replace TEST by your Active Directory Netbios name in upper case characters 4. Join the Session Manager server to the domain using the net ads join command with a domain administrator user (a user that has rights to add computers and users to the domain) by entering the below command: net ads join -U administrator@test.demo 5. Enter the administrator s password Page 17

6. Test the configuration using the following command: net ads testjoin 7. After performing that command, the computer is joined to the domain, and the SM server is now added as a computer object in Active Directory. Note: If the user wants to further verify the system is working, use the following command: net ads info Output similar to that shown below should be displayed: LDAP server: 192.168.0.200 LDAP server name: dc.test.demo Realm: TEST.DEMO Bind Path: dc=test,dc=demo LDAP port: 389 Server time: Mon, 18 May 2015 18:40:22 CEST KDC server: 192.168.0.200 Server time offset: 455 4.5 ACTIVE DIRECTORY USERS AND COMPUTERS The Session Manager must then be configured in the Domain Controller so that it can be trusted for use with Kerberos. On the Domain Controller, open the Active Directory Users and Computers console. Page 18

1. Locate the osm object Figure 3: osm Computer Object 2. Right-click on the osm object to display the menu options for that object and select properties. Figure 4: osm Object Menu Page 19

3. In the Properties dialog, click on the Delegation tab. Figure 5: osm Properties Dialog Page 20

4. In the Delegation dialog, choose Trust this computer for delegation for any service (Kerberos only). Figure 6: Delegation tab of the osm Object Page 21

5. Click on Apply and OK. Figure 7: Delegation Options 6. The Session Manager is now configured in the Active Directory domain. 4.6 CREATE A SERVICE TICKET Up to this point, the system has been configured so that the Session Manager server is able to connect to the Active Directory domain. The next step is to get the Kerberos service keys in a keytab file so that the data can be used by the Apache web server on the Session Manager server. Samba is used to set the service principle(s) for Apache. Page 22

1. On the session manager server, login to a console as an administrator, in the example we are following this is administrator@test.demo. net ads keytab add HTTP -U administrator@test.demo After entering the command, you should see output similar to that shown below: Processing principals to add... Enter administrator's password: 2. Now check that the /etc/krb5.keytab file contains the HTTP/osm.test.demo principal ticket by using the kutil command. ktutil 3. Enter the path to the keytab file. ktutil: rkt /etc/krb5.keytab 4. Type the command List to show the contents. ktutil: l slot KVNO Principal ---- ---- -------------------------------------------------------------- ------- 1 2 HTTP/osm.test.demo@TEST.DEMO 2 2 HTTP/osm.test.demo@TEST.DEMO 3 2 HTTP/osm.test.demo@TEST.DEMO 4 2 HTTP/osm.test.demo@TEST.DEMO 5 2 HTTP/osm.test.demo@TEST.DEMO 6 2 HTTP/osm@TEST.DEMO 7 2 HTTP/osm@TEST.DEMO 8 2 HTTP/osm@TEST.DEMO 9 2 HTTP/osm@TEST.DEMO 10 2 HTTP/osm@TEST.DEMO ktutil: 5. Exit the utility using the exit command. ktutil: exit 6. Set access permissions for the keytab file. chmod 640 /etc/krb5.keytab Page 23

7. Set file group owner chgrp www-data /etc/krb5.keytab Note: The Apache user should be www-data for Ubuntu. This can be verified using the following commands: ps aux grep apache2 egrep -w --color=auto '^User ^Group' /etc/httpd/conf/httpd.conf 4.7 APACHE AND KERBEROS Please follow the below steps: 1. Install the package first apt-get install -y libapache2-mod-auth-kerb 2. Enable the Apache module. The Apache module should be loaded automatically after installing the package. If the module does not load, enter the command below: a2enmod auth_kerb 3. Edit the configuration file: /etc/apache2/conf-enabled/test.conf and copy the following data into the file: Page 24

Alias "/test" "/var/www/test" <Directory "/var/www/test"> AllowOverride None DirectoryIndex index.php AuthType Kerberos AuthName "Kerberos Login" KrbServiceName HTTP/osm.test.demo KrbMethodNegotiate On KrbMethodK5Passwd On KrbAuthRealms TEST.DEMO Krb5KeyTab /etc/krb5.keytab require valid-user </Directory> 4. Create a folder test in the web server root mkdir -p /var/www/test 5. Create a /var/www/test/index.php file and paste the following content in it: <?php echo "<h2>kerberos Auth</h2>"; echo "Auth type: ". $_SERVER['AUTH_TYPE']. "<br />"; echo "Remote user: ". $_SERVER['REMOTE_USER']. "<br />"; 6. Restart the Apache service service apache2 restart 4.7.1 VALIDATE THE CONFIGURATION The example below must be completed on a Windows workstation running a domain user. Please install Firefox for installation purposes. In this example, we recommend to use Firefox because it is an easier browser to configure Kerberos. If you want to use another browser, please refer to the information provided at: http://sammoffatt.com.au/jauthtools/kerberos/browser_support Note: The Apache configuration presented here is not compatible with Internet Explorer or Google Chrome. First, configure Firefox to use Kerberos and then verify the configuration using HTTPS. Page 25

1. Run Firefox 2. In the URL field, enter the value about:config. 3. In the search field, enter network.nego. 4. Change the two values with your OSM FQDN e.g. network.negotiate-auth.delegation-uris: Change the status user set, type String and enter the value osm.test.demo network.negotiate-auth.trusted-uris: Change the status user set, type String and enter the value osm.test.demo Figure 9: about.config Page 26

5. Browse to the URL http://osm.test.demo/test/. If SSO is working correctly, you will see the screenshot below: Figure 10: Kerberos Authorization Page 27

4.8 KERBEROS AND OVD We have validated that Kerberos authentication over HTTP is working using a simple PHP example. The next step is to configure Kerberos authentication for the OVD Session Manager. 1. Duplicate the Apache SSL VirtualHost that already exists for the Session Manager: cd /etc/apache2/sites-enabled cp default-ssl.conf ovd-session-manager-kerb.conf 2. Edit the ovd-session-manager-kerb.conf file a. Change the ServerName setting value to the OSM FQDN (osm.test.demo in this example) ServerName osm.test.demo Note: if no ServerName setting is defined yet, create a new one at the beginning of the VirtualHost definition. b. Copy & paste the following bloc at the end of the VirtualHost definition <Location /ovd> AuthType Kerbers </Location> AuthName "Kerberos Login" KrbServiceName HTTP/osm.test.demo KrbMethodNegotiate On KrbMethodK5Passwd On KrbAuthRealms TEST.DEMO Krb5KeyTab /etc/krb5.keytab Require valid-user c. Replace osm.test.demo by the Active Directory Domain Controller FQDN d. Replace TEST.DEMO by the Active Directory domain name in upper case characters 3. Edit the default SSL VirtualHost configuration file and change the ServerName setting value to IP address for your system. ServerName 10.1.0.10 Page 28

4. Reload the Apache configuration service apache2 reload 5. Go to the OVD Administration Console page: Configuration->Authentication Settings a. Check the RemoteUser authentication checkbox in the AuthMethod section b. Set the Remove domain if exists option to yes in the RemoteUser section c. Click on the Save button at the bottom of the page Figure 11: Enable AuthMethod The SM is now configured to authenticate a user with Kerberos. The next step is to configure the OVD client to validate that the setup is working. Note: This configuration for the Session Manager provides both regular and Kerberos authentication. If you want to disable regular authentication, the easiest way is to uncheck the Password checkbox in the OVD Administration Console. Page 29

5. OWA HTML5 CLIENT The Kerberos Authentication for the HTML5 client will only work if the OWA is installed on the same system as the OSM and it is accessed via HTTPS. If it does not work, please review the steps mentioned in section 4 Session Manager Configuration from the beginning through to section 4.7.1 Validate the Configuration. 1. Edit the OWA configuration file /etc/ovd/web-access/config.inc.php a. Uncomment line define('option_force_sso', true); b. Save and exit. 2. Start Firefox and enter the URL https://osm.test.demo/ovd/. You will see a screen similar to the one below if Kerberos is working properly. Figure 12: Login screen Note: Firefox must be configured to use Kerberos. To configure Firefox, follow the steps detailed in section 4.7.1 Validate the Configuration. If the login panel does not show the user login name, check the firewall settings and re-check the steps again for Kerberos Authentication in section 4 Session Manager Configuration. Clicking on Connect will start the OVD session without the requirement to enter any further credentials. Page 30

6. EDC AND OWA JAVA CLIENT This section applies to both the EDC client and the OWA Java client running on a Windows workstation. 6.1 WORKSTATION CONFIGURATION The user workstation (Windows 7) must be configured to allow SSO authentication into OVD. A local or domain admin access to the workstation is required. Please note that domain GPO (Group Policy) may be used to automate the changes below in an enterprise environment. 6.1.1 ALLOWTGTSESSIONKEY There is a key called AllowTgtSessionkey in the Windows registry that controls whether a client application is allowed to decrypt the session key of a Kerberos Ticket Granting Ticket (TGT). This capability must be enabled. 1. Login as an admin user on the user workstation 2. Run the registry editor: regedit.exe 3. Change the following value: Depending on the version of Windows you use, the above registry key should be created in the following registry path: Windows XP HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\ REG_DWORD name: AllowTgtSessionKey Value: 1 Windows 2003 Server, Vista, 7, 8, etc. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Par ameters REG_DWORD name: AllowTgtSessionKey Value: 1 6.1.2 ENABLE DES Depending on your version of Windows, further settings may need to be applied as described in the Microsoft information page at http://technet.microsoft.com/en-us/library/dd560670(v=ws.10).aspx Page 31

These settings apply to Windows 7, Windows 8 and Windows 8 R2 and Windows 2012. 1. Open an admin session on the workstation 2. Run gpedit.msc from a command prompt 3. Navigate to Local Computer Security-Computer Configuration Windows Settings Security Settings Local Policies Security Options 4. Open the Network Security: Configure encryption types allowed for Kerberos setting and enable the following options: 5. Reboot the workstation Figure 13: Network Security options Page 32

6.2 EDC Start the EDC and check Use Local credentials as shown in Figure 14 below: Figure 14: Inuvika OVD Enterprise Desktop Client Note: Clicking on Start should start the session without the need to enter any further credentials. 6.3 WEB ACCESS 1. Edit the following file /etc/ovd/web-access/config.inc.php 2. Comment the following line: define('option_show_use_local_credentials', true); Page 33

3. Enter the OWA URL in a browser and select the Java session type. You will see a screen similar to the one below: Figure 15: Login Screen Note: Clicking on Connect will start the session without the need to enter any further credentials. Page 34

7. TROUBLESHOOTING 7.1 VALIDATE TEST CASE If the test from section 4.7.1 Validate the Configuration does not work, check the items below first: The server time on all servers is correctly synchronized and operational Browser is set-up correctly No firewall issues on the OSM node Check that the auth_kerb module is enabled in Apache and ensure that the module is present and loaded. If the test still does not work, the Apache Logs and web-browser developer tools console can provide further information. A tool such as wireshark can be used to monitor the HTTP data stream (HTTP instead of HTTPS +wireshark) Enable the debug mode on the SM side by performing the following for the OVD session: Set-up the domain integration to Microsoft and internal session method Enable RemoteUser authentication as described in section 4.8 Enable debug mode the the OSM and Apache logs Enable the SSO option in the OWA by editing the OWA config file at /etc/ovd/web_access/config.inc.php Use HTTPS (it should not be HTTP) 7.2 OWA HTML5 If the HTML5 client is not working, open the developer tools console in Firefox and call ovd.settings.http_provider and ensure it returns direct. Otherwise the about:config settings were not saved. Please refer to the screenshot below: Page 35

Figure 16: Developer tools console calling ovd.settings.http_provider 7.3 EDC AND OWA JAVA CLIENT Check your local credentials using the klist command and ensure that there is a HTTP/osm.test.demo ticket. Start the EDC with the Kerberos debug mode enabled: cd Program Files (x86)\ovd\enterprise Desktop Client java Dsun.security.krb5.debug=true jar OVDEnterpriseDesktopClient.jar Page 36