Procedure 17.2. Configuring Kerberos for the Apache Service

1. On the KDC server, use the kadmin utility to create a service principal for the Apache service on the Red Hat Enterprise Virtualization Manager. The service principal is a reference ID to the KDC for the Apache service.

   # kadmin
   kadmin> addprinc -randkey HTTP/fqdn-of-rhevm@REALM.COM

2. Generate a keytab file for the Apache service. The keytab file stores the shared secret key.

   kadmin> ktadd -k /tmp/http.keytab HTTP/fqdn-of-rhevm@REALM.COM

   kadmin> quit

3. Copy the keytab file from the KDC server to the Red Hat Enterprise Virtualization Manager:

   # scp /tmp/http.keytab root@rhevm.example.com:/etc/httpd

Procedure 17.3. Configuring Single Sign-on to the User Portal or Administration Portal

1. On the Red Hat Enterprise Virtualization Manager, ensure that the ownership and permissions for the keytab are appropriate:

   # chown apache /etc/httpd/http.keytab

   # chmod 400 /etc/httpd/http.keytab

2. Install the authentication extension package, LDAP extension package, and the mod_auth_kerb authentication module:

   # yum install ovirt-engine-extension-aaa-misc ovirt-engine-extension-aaa-ldap mod_auth_kerb

3. Copy the SSO configuration template file into the /etc/ovirt-engine directory. Template files are available for Active Directory (ad-sso) and other directory types (simple-sso). This example uses the simple SSO configuration template

   # cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple-sso/. /etc/ovirt-engine

4. Create a symbolic link for the /etc/httpd/conf.d directory for Apache to use the SSO configuration files:

   # ln -s /etc/ovirt-engine/aaa/ovirt-sso.conf /etc/httpd/conf.d

5. Edit the authentication method file for Apache to use Kerberos for authentication:

   # vi /etc/ovirt-engine/aaa/ovirt-sso.conf

   ⁠

   Example 17.5. Example authentication method file

   <LocationMatch ^(/ovirt-engine/(webadmin|userportal|api)|/api)>
       RewriteEngine on
       RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
       RewriteRule ^(.*)$ - [L,P,E=REMOTE_USER:%1]
       RequestHeader set X-Remote-User %{REMOTE_USER}s
   
       AuthType Kerberos
       AuthName "Kerberos Login"
       Krb5Keytab /etc/httpd/http.keytab
       KrbAuthRealms REALM.COM
       Require valid-user
   </LocationMatch>

6. Edit the LDAP property configuration file by uncommenting an LDAP server type and updating the domain and passwords fields:

   #  vi /etc/ovirt-engine/aaa/profile1.properties

   ⁠

   Example 17.6. Example profile: LDAP server section

   #
   # Select one
   #
   include = <openldap.properties>
   #include = <389ds.properties>
   #include = <rhds.properties>
   #include = <ipa.properties>
   #include = <iplanet.properties>
   #include = <rfc2307.properties>
   
   #
   # Server
   #
   vars.server = ldap1.company.com
   
   #
   # Search user and its password.
   #
   vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com
   vars.password = 123456
   
   pool.default.serverset.single.server = ${global:vars.server}
   pool.default.auth.simple.bindDN = ${global:vars.user}
   pool.default.auth.simple.password = ${global:vars.password}
   

   To use TLS or SSL protocol to interact with the LDAP server, obtain the LDAP server's root CA certificate, and use it to create a public keystore file. Uncomment the following lines and specify the full path to the public keystore file and the password to access the file.

   Note

   For more information on creating a public keystore file, see Section E.2, “Setting Up SSL or TLS Connections between the Manager and an LDAP Server”.
   ⁠

   Example 17.7. Example profile: keystore section

   # Create keystore, import certificate chain and uncomment
   # if using ssl/tls.
   pool.default.ssl.startTLS = true
   pool.default.ssl.truststore.file = /full/path/to/myrootca.jks
   pool.default.ssl.truststore.password = changeit

7. Review the authentication configuration file. The profile name is visible to users on the Administration Portal and the User Portal login pages. The configuration profile location must match the LDAP configuration file location. All fields can be left as default.

   # vi /etc/ovirt-engine/extensions.d/profile1-http-authn.properties

   ⁠

   Example 17.8. Example authentication configuration file

   ovirt.engine.extension.name = profile1-authn
   ovirt.engine.extension.bindings.method = jbossmodule
   ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
   ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension
   ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
   ovirt.engine.aaa.authn.profile.name = profile1-http
   ovirt.engine.aaa.authn.authz.plugin = profile1-authz
   ovirt.engine.aaa.authn.mapping.plugin = http-mapping
   config.artifact.name = HEADER
   config.artifact.arg = X-Remote-User

8. Review the authorization configuration file. The configuration profile location must match the LDAP configuration file location. All fields can be left as default.

   #  vi /etc/ovirt-engine/extensions.d/profile1-authz.properties

   ⁠

   Example 17.9. Example authorization configuration file

   ovirt.engine.extension.name = profile1-authz
   ovirt.engine.extension.bindings.method = jbossmodule
   ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
   ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension
   ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
   config.profile.file.1 = ../aaa/profile1.properties

9. Ensure that the ownership and permissions of the configuration profile are appropriate:

   # chown ovirt:ovirt /etc/ovirt-engine/aaa/profile1.properties

   # chmod 600 /etc/ovirt-engine/aaa/profile1.properties

10. Restart the Apache service and the engine service:

    # service httpd restart

    # service ovirt-engine restart