Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Numbered Headings

System Preparation

Turn off SELinux

Currently, Moonshot will not work while SELinux is in enforcing mode. Until we resolve this, simply turn SELinux to permissive mode. This can be done temporarily (i.e., on reboot it will be turned back on), or permanently (the change will persist).

Temporarily

The following command will turn Enforcing mode off:

Code Block
languagebash
$ echo 0 > /selinux/enforce

Permanently

Edit /etc/sysconfig/selinux and change "SELINUX=enforcing" to "SELINUX=permissive". Reboot the system.

Add the Moonshot libraries

If you have not already done so, you first need to follow the instructions on how to install the Moonshot Libraries on RHEL/CentOS/SL 6.

Installation Instructions

Using the standard RedHat mod_auth_gssapi module

  1. To use the Apache module, install it from the base repository:

    Code Block
    languagebash
    $ yum install mod_auth_gssapi
  2. Ensure that the certificates referenced in /etc/radsec.conf can be read by the Apache user:

    Code Block
    languagebash
    $ su - --shell=/bin/bash apache $ cat path_to_ca.pem $ cat path_to_client.pem $ cat path_to_client.key
  3. If they cannot be read, add the Apache user to the group that has read access to the certificates:

    Code Block
    languagebash
    $ usermod -a -G <group> apache
  4. Verify that the KeepAlive option is enabled in the Apache configuration file /etc/httpd/conf/httpd.conf:

    Code Block
    languagebash
    KeepAlive On
  5. Restart Apache:

    Code Block
    languagebash
    $ service httpd restart

Using the Moonshot mod_auth_gssapi module

  1. To use the Apache module, install it and the Kerberos workstation package from the base repository:

    Code Block
    languagebash
    $ yum --disablerepo=base install mod_auth_gssapi
    $ yum install krb5-workstation
  2. Add a dummy Kerberos key to make the module happy:

    Code Block
    languagebash
    $ ktutil
    ktutil:  addent -password -p HTTP/localhost@YOUR-WEBSERVER-HOSTNAME -k 1 -e aes256-cts
    <enter any password>
    ktutil:  wkt /etc/httpd/krb5.keytab
    ktutil:  quit
  3. Export the location of the keytab file into Apache's config:

    Code Block
    languagebash
    $ echo export KRB5_KTNAME=/etc/httpd/krb5.keytab >> /etc/httpd/envvars
    Note
    titleAlternative

    Alternatively, you can use the GSSKrb5Keytab configuration directive in the Location directive in Section 3.1 to specify the keytab.

  4. Assign the correct permissions to the keytab file:

    Code Block
    languagebash
    $ chown apache.apache /etc/httpd/krb5.keytab
  5. Ensure that the certificates referenced in /etc/radsec.conf can be read by the Apache user:

    Code Block
    languagebash
    $ su - --shell=/bin/bash apache
    $ cat path_to_ca.pem 
    $ cat path_to_client.pem 
    $ cat path_to_client.key
  6. If they cannot be read, add the Apache user to the group that has read access to the certificates:

    Code Block
    languagebash
    $ usermod -a -G <group> apache
  7. Verify that the KeepAlive option is enabled in the Apache configuration file /etc/httpd/conf/httpd.conf:

    Code Block
    languagebash
    KeepAlive On
  8. Restart Apache:

    Code Block
    languagebash
    $ service httpd restart

Configuration Instructions

Warning
titleShibboleth2 Apache module incompatibility

Please note that this module is currently not compatible with the Shibboleth2 service provider Apache module. When testing or using the Moonshot module, disable the Shibboleth module and restart the webserver before attempting your test. We are attempting to resolve this problem.

Protecting a location with Moonshot

Using the standard RedHat mod_auth_gssapi module

To protect a particular location on your Apache server, you must configure it with an AuthType of "GSSAPI".

Here's a sample configuration that can get you started.

Tip
titleExample

To allow anyone with a valid Moonshot account to access /wherever, you would do the following:

Code Block
linenumberstrue
<Location "/wherever">
    AuthType GSSAPI 
    AuthName "Moonshot Login"
    Require valid-user
    AddHandler cgi-script .cgi
    Options +ExecCGI
    GssapiConnectionBound On
    GssapiNameAttributes json
</Location>
Info
titleConfiguration Directives
For more information on the configuration directives supported by the RedHat mod_auth_gssapi module, see its homepage at https://github.com/modauthgssapi/mod_auth_gssapi

Using the Moonshot mod_auth_gssapi module

To protect a particular location on your Apache server, you must configure it with an AuthType of "Negotiate".

The module-shipped /etc/httpd/conf.d/auth_gssapi.conf file contains a sample configuration that can get you started.

Tip
titleExample

To allow anyone with a valid Moonshot account to access /wherever, you would do the following:

Code Block
linenumberstrue
<Location "/wherever">
    AuthType Negotiate
    AddHandler cgi-script .cgi
    Options +ExecCGI
    Require valid-user
</Location>
Info
titleCompabitility

Additionally, in an effort to provide cross-compatibility, the Moonshot mod_auth_gssapi module will soon support the configuration directives that the RedHat mod_auth_gssapi module supports.

 For more information on the configuration directives supported by the RedHat mod_auth_gssapi module, see its homepage at https://github.com/modauthgssapi/mod_auth_gssapi

 

Populating REMOTE_USER

Web services often rely on the REMOTE_USER Apache environment variable for user information, such as a local user account or a pseudonymous identifier.

Using the RedHat mod_auth_gssapi module

 To populate REMOTE_USER, enable the GssapiImpersonate configuration directive:

Code Block
<Location "/wherever">
    :
    :
    GssapiImpersonate On
    :
    :
</Location>

Using the Moonshot mod_auth_gssapi module

To populate REMOTE_USER, update the FreeRADIUS reply from the RP Proxy with the User-Name RADIUS attribute in the RP Proxy's post-auth section:

Code Block
update reply {
        User-Name := "content"
}

 

HTTPS Internet Explorer compatibility

For updated best practice with Internet Explorer connections, you should also read Microsoft's HTTPS and Keep-Alive Connections article.