Skip to content

Active Directory SSO Using Kerberos

Last updated on Oct 31 2023.

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.

Introduction

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 the Microsoft kerberos authentication guide.

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 the Microsoft kerberos guide

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

The following OVD Enterprise documentation is available:

Prerequisites

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

Note

  • 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 and OFS 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.
  • All passwords are case sensitive

Session Manager IP Configuration

The Session Manager IP address may be established either by using DHCP or by using a static IP configuration. In the case that a DHCP configuration is used and the DHCP service is not provided by the Active Directory server, the following must be ensured:

  • The DHCP server must always provide the same IP to the Session Manager (MAC address match)
  • The DHCP server must provide the Session Manager with the IP address of the active Directory server as the primary DNS server

It is highly recommended to perform the above steps before proceeding further in the documentation.If it is not possible to validate the above steps then a possible workaround is to configure the Session Manager with a static IP address.

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.

Client Compatibility

The SSO feature is compatible with OVD clients running on a Windows workstation that is joined to the Active Directory domain. SSO is compatible with the OVD Enterprise Desktop Client and OVD Web Access clients 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 or the Web Access clients running on Linux or Mac.

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 User Session Configuration section of the configuration page, ensure that the Full OVD integration option is selected. Neither the Hybrid integration nor the Full Active Directory integration options are 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.

Network Overview

A standard OVD Network with a Microsoft Domain Controller

In order to use Kerberos with the OVD Session Manager, the firewall must be configured to allow authentication. Refer to Firewall and Ports for instructions.

Note

In the figure above and throughout the example, the Microsoft Domain Controller is dc.test.demo and Session Manager is osm.test.demo. The Windows domain is test.demo.

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.

FQDN and DNS Compatiblity

Windows Kerberos requires the use of Fully Qualified Domain Name (FQDN), 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 reverse-resolvable. The reverse and forward lookup for a FQDN can be tested using the nslookup command.

System Hostname Definition

Before proceeding, make sure that the Session Manager server is configured correctly by entering the following commands and checking that the response is as expected:

  • hostname - the expected response is osm
  • hostname -f - the expected response is osm.test.demo

If either of the responses is not as expected, follow the steps below to correct the configuration and then retest:

  1. Make sure the system hostname is defined correctly (osm) and does not contain the network/domain name (test.demo) by editing the file /etc/hostname to define osm as hostname.
  2. Edit the /etc/hosts file and ensure it contains the following lines, using the IP address and Session Manager FQDN applicable to your environment:

    192.168.0.201 osm.test.demo osm

  3. If you made any modification to the hostname configuration file or the /etc/hosts file, please reboot your server.

  4. After reboot make sure the expected response is obtained for the hostname and hostname -f commands

Note

When configuring the hostname for your environment, the domain specified in the hostname should be the Windows domain name defined by the Active Directory Domain Controller.

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. Open the /etc/resolv.conf file on the Session Manager server and ensure that the name server is the Domain Controller's IP address. If not then:

    1. For a DHCP configuration, go to section Session Manager IP Configuration and check the configuration is correct.
    2. For a static IP configuration, change the system primary DNS to be the Active Directory Domain controller IP. For further information refer to the Static IP Address Configuration section.
      nameserver 192.168.0.200
      search test.demo
  2. Save the file and verify that the name resolution works.

    $
    ping test.demo

Time Synchronization

Time Synchronization is critical for Kerberos authentication to work. Please follow the Time Synchronization documentation.

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

    • For Ubuntu

      #
      apt install -y krb5-user

    • For RHEL 8

      #
      dnf install krb5-workstation

    • For CentOS / RHEL 7

      #
      yum install krb5-workstation

  2. Backup the Kerberos configuration file

    #
    mv /etc/krb5.conf /etc/krb5.conf.old

  3. Create a new file called /etc/krb5.conf and copy & paste the following lines into the file:

    [libdefaults]
        default_realm=TEST.DEMO
        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

    1. Replace dc.test.demo by the FQDN of the Domain Controller of your Active Directory domain
    2. Replace test.demo by the Active Directory domain name
    3. Replace TEST.DEMO by the Active Directory domain name in upper case characters
  4. Create log directory /var/log/krb5 and empty log files:

    1. Create a directory

      #
      mkdir -p /var/log/krb5

    2. Create an empty log file /var/log/krb5/krb5kdc.log

      #
      touch /var/log/krb5/krb5kdc.log

    3. Create an empty log file /var/log/krb5/kadmind.log

      #
      touch /var/log/krb5/kadmind.log

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

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

    • For Ubuntu

      #
      apt install -y smbclient

    • For RHEL 8

      #
      dnf install samba-client

    • For CentOS / RHEL 7

      #
      yum install samba-client

  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

    1. Replace the osm netbios name by your netbios name.
    2. Replace dc.test.demo by the FQDN of the Domain Controller of your Active Directory domain
    3. Replace TEST.DEMO by your Active Direcory domain in upper case characters
    4. 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 command below:

    #
    net ads join -U administrator@TEST.DEMO

  5. Enter the administrator's password

  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

Active Directory Users and Computers

The Session Manager must 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.

  1. Locate the osm object

    osm Computer Object

  2. Right-click on the osm object to display the menu options for that object and select Properties

    osm Object Menu

  3. In the Properties dialog, click on the Delegation tab.

    osm Properties Dialog

  4. In the Delegation dialog, choose Trust this computer for delegation for any service (Kerberos only).

    Delegation tab of the osm Object

  5. Click on Apply and OK.

The Session Manager is now configured in the Active Directory domain.

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.

  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:
    list

    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
  5. Exit the utility using the exit command.

    ktutil:
    exit

  6. Set access permissions for the keytab file.

    #
    chmod 640 /etc/krb5.keytab

  7. Set file group owner

    • For Ubuntu

      #
      chgrp www-data /etc/krb5.keytab

    • For CentOS / RHEL

      #
      chgrp apache /etc/krb5.keytab

Note

We want to set the default posix group used by the Apache process as the group owner of the keytab file. If for any reason your system overrides the default configuration value please refer to Apache Group.

Apache and Kerberos

Please follow the steps below:

  1. Install the package first

    • For Ubuntu

      #
      apt install -y libapache2-mod-auth-kerb

    • For CentOS / RHEL

      #
      yum install 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:

    • For Ubuntu

      /etc/apache2/conf-enabled/test.conf

    • For CentOS / RHEL

      /etc/httpd/conf.d/test.conf

  4. and copy the following data into the file:

    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>

    1. Replace osm.test.demo by the FQDN of the Session Manager in your environment.
    2. Replace TEST.DEMO by your Active Direcory domain in upper case characters
  5. Create a folder test in the web server root

    #
    mkdir -p /var/www/test

  6. 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 />";

  7. Restart the Apache service

    • For Ubuntu

      #
      systemctl restart apache2

    • For CentOS / RHEL

      #
      systemctl restart httpd

Validate the Configuration

The example below must be completed on a Windows workstation running a domain user. Please install Firefox for testing purposes. In this example, we recommend to use Firefox because it is an easier browser with which to configure Kerberos.

First, configure Firefox to use Kerberos and then verify the configuration using HTTPS.

  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 to match the OSM FQDN e.g.

    1. network.negotiate-auth.delegation-uris: Right click and select modify to enter the value osm.test.demo
    2. network.negotiate-auth.trusted-uris: Right click and select modify to enter the value osm.test.demo

      about:config

  5. Browse to the URL http://osm.test.demo/test/. If SSO is working correctly, you will see information similar to the screenshot below:

    Kerberos Authorization

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:

    • For Ubuntu

      1. navigate to directory /etc/apache2/sites-enabled

        #
        cd /etc/apache2/sites-enabled

      2. create a copy of the file default-ssl.conf

        #
        cp default-ssl.conf ovd-session-manager-kerb.conf

    • For CentOS / RHEL

      1. navigate to directory /etc/httpd/conf.d

        #
        cd /etc/httpd/conf.d

      2. create a copy of the file ssl.conf

        #
        cp ssl.conf  ovd-session-manager-kerb.conf

  2. Edit the ovd-session-manager-kerb.conf file

    1. Delete all the lines that appear before and after the VirtualHost section.
    2. 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.

    3. Copy & paste the following block at the end of the VirtualHost definition

      <Location /ovd>
              AuthType Kerberos
              AuthName "Kerberos Login"
              KrbServiceName HTTP/osm.test.demo
              KrbMethodNegotiate On
              KrbMethodK5Passwd On
              KrbAuthRealms TEST.DEMO
              Krb5KeyTab /etc/krb5.keytab
              Require valid-user
      </Location>

    4. Replace osm.test.demo by the FQDN of the Session Manager in your environment

    5. 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 the IP address of the Session Manager.

    1. For Ubuntu, the file is /etc/apache2/sites-enabled/default-ssl.conf
    2. For CentOS / RHEL, the file is /etc/httpd/conf.d/ssl.conf

      ServerName 10.1.0.10

      Note

      If no ServerName setting is defined, add the setting in the SSL Virtual Host configuration file.

  4. Reload the Apache configuration

    • For Ubuntu

      #
      systemctl reload apache2

    • For CentOS / RHEL

      #
      systemctl restart httpd

  5. Go to the OVD Administration Console page: "Users / Authentication Settings"

    1. Check the RemoteUser authentication checkbox

    2. Set the Use Kerberos login method option to yes

    3. Click on the Save button at the bottom of the page

      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.

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. The OWA must be configured to address the OSM using 127.0.0.1 or localhost. If it does not work, please review the steps mentioned in the Session Manager Configuration section from the beginning through to the Validate the Configuration section.

  1. Edit the OWA configuration file /etc/ovd/web-access/config.inc.php
    1. Uncomment the line define('OPTION_FORCE_SSO', true);
    2. The SESSIONMANAGER_HOST setting must be set to localhost if it was defined with an IP or FQDN
    3. 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.

    Login screen

Note

Firefox must be configured to use Kerberos. To configure Firefox, follow the steps detailed in the Validate the Configuration section.

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 Session Manager Configuration.

Clicking on Connect will start the OVD session without the requirement to enter any further credentials.

Enterprise Desktop Client

This section applies to the Enterprise Desktop Client (EDC) running on a Windows workstation.

Workstation Configuration

The user workstation (Windows) must be configured to allow SSO authentication into OVD. For this, 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.

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. Create a registry entry as follows:
    • Create a DWORD entry with the name AllowTgtSessionKey and value 1 at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

      Registry AllowTgtSessionKey

Enable DES

Depending on your version of Windows, further settings may need to be applied as described in the Microsoft information page at https://technet.microsoft.com/en-us/library/dd560670(v=ws.10).aspx

These settings apply to Windows 8 and newer.

  1. Open an admin session on the workstation
  2. Run gpedit.msc from a command prompt
  3. Navigate

    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:

    Network Security options

  5. Reboot the workstation

EDC

Start the EDC and check Use Local credentials as shown in the figure below:

Inuvika OVD Enterprise Desktop Client

Note

Clicking on Start should start the session without the need to enter any further credentials.

Troubleshooting

Validate Test Case

If the test from section Validate the Configuration does not work, check the items below first:

  1. The server time on all servers is correctly synchronized and operational
  2. Browser is set-up correctly
  3. No firewall issues on the OSM node
  4. 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 the Kerberos and OVD section.
  • 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)

DNS Issues

If the result from net ads join test failed as described in section Joining the Domain is as follows:

No DNS domain configured for osm. Unable to perform DNS Update.
DNS update failed!

Then the possible reasons are

  • Invalid system hostname
  • Invalid system network name in /etc/hosts
  • Invalid system network name in the smb.conf configuration for the netbios name

To resolve this issue, configure the system hostname and system network name for the Session Manager correctly and then remove the workstation from Active Directory and re-register it again.

Clock Skew

If there is an issue in authenticating OVD with Kerberos, turn on the Apache error logs and check the reports for a Clock skew too great error:

[error] [client 192.168.0.65] krb5_get_init_creds_password() failed: Clock skew too great

This error indicates that the time on the Session Manager is not synchronized with the time on the Active Directory Domain Controller. Run the ntpdate command to fix the issue and check for the possible reasons why the ntp service is not synchronizing it.

OWA HTML5

If the HTML5 client is not working, open the developer tools console in Firefox and enter ovd.settings.http_provider and ensure it returns direct. Otherwise the about:config settings were not saved. Please refer to the screenshot below:

Developer tools console calling ovd.settings.http_provider

EDC

  • Check your local credentials using the klist command and ensure that there is an HTTP/osm.test.demo ticket.

Static IP Address Configuration

Generally, the DNS information is stored in the /etc/resolv.conf file. Sometimes, when you modify the file to have a specific DNS server IP address, it may not be persistent because of the system configuration and the modification may change when the system is rebooted or the network service is restarted.

On Ubuntu and RHEL/CentOS systems, the DNS configuration can also be defined in the global network configuration. In turn, this will overwrite the DNS modification made in /etc/resolv.conf. For these reasons, it is recommended to modify the DNS information directly in the global network configuration file.

  • For Ubuntu : Edit the /etc/network/interfaces to add

    dns-nameservers 192.168.0.200
    dns-search test.demo

  • For CentOS / RHEL : Edit the file /etc/sysconfig/network-scripts/ifcfg-eth0 to add

    DNS1=192.168.0.200
    SEARCH=test.demo

Apache Group

The system default group used by Apache is :

  • For Ubuntu: www-data
  • For CentOS / RHEL: apache

If for some reason the system overrides the system default value or if you want to check it, the following command line will give you the group name used by apache on your system:

  • For Ubuntu

    1. For group name starting with Group:

      #
      egrep -w --color=auto  '^Group' -R /etc/apache2/

    2. For group name associated with environmental variable APACHE_RUN_GROUP

      #
      egrep -w --color=auto  'APACHE_RUN_GROUP' /etc/apache2/envvars

  • For CentOS / RHEL

    #
    grep -E '^Group' /etc/httpd/conf/httpd.conf