Versions Compared

Key

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

...

Numbered Headings

Include Page
TEM:_SystemPrep_RHEL7
TEM:_SystemPrep_RHEL7

Install the Software

We’re now ready to install the Moonshot software and its required dependencies. Install the software by running the following command:

Code Block
languagebash
$ yum install moonshot-gss-eap moonshot-ui freeradius-abfab freeradius-utils trust_router dbus-x11

Configure the Moonshot APC

Next, we need to configure the Moonshot APC.

Configure FreeRADIUS

Include Page
TEM:_CertPrep_RHEL
TEM:_CertPrep_RHEL

RadSec

Next we need to configure RadSec. We do this by creating a file at /etc/radsec.conf with the following:

Code Block
linenumberstrue
realm gss-eap {
	type = "TLS"
	cacertfile = "/etc/raddb/certs/ca.pem"
	certfile = "/etc/raddb/certs/client.pem"
	certkeyfile = "/etc/raddb/certs/client.key"
	disable_hostname_check = yes
	server {
		hostname = "127.0.0.1"
		service = "2083"
		secret = "radsec"
	}
}

Realm

We next need to configure your realm in the FreeRADIUS server so that it knows not to send any requests for your own users off to another server.

  1. Configure your realm in /etc/raddb/proxy.conf
    1. Open the file for editing and find the line “realm example.com {“
    2. Above this, add the following, where YOUR_APC_REALM should be substituted by your APC realm (e.g. apc.moonshot.ja.net):

      Code Block
      linenumberstrue
      realm YOUR_APC_REALM {
      	# Intentionally left blank
      }

Channel Binding Support

We next need to configure your FreeRADIUS server to support channel bindings.

  1. Open /etc/raddb/sites-available/abfab-tls for editing:
    1. Scroll to the client default stanza at the bottom of the file
    2. Edit the stanza to match the below:

      Code Block
      client default {
              ipaddr = 0.0.0.0/0
              proto = tls
              gss_acceptor_realm_name = "your APC realm here"
              trust_router_coi = "your APC realm here"
      }
    3. If you have any other client definitions here, for example to distinguish between internal and external clients, also apply the change to them.

EAP Type

Set the EAP type in use by Moonshot (EAP-TTLS) by editing /etc/raddb/mods-enabled/eap

  1. Find the first instance of default_eap_type = md5 and change it to TTLS, i.e.:

    Code Block
    default_eap_type = ttls
Info
Other EAP types should be supported (PEAP and MD5 have been tested).

Returning the User-Name

The APC must return the User-Name attribute in its RADIUS response.

  1. As root, find the post-auth section in the /etc/raddb/sites-available/abfab-tr-idp file.

    1. Insert the below at the top of the section, if it does not already exist:

      Code Block
      	#
      	#  For EAP-TTLS and PEAP, add the cached attributes to the reply.
      	#  The "session-state" attributes are automatically cached when
      	#  an Access-Challenge is sent, and automatically retrieved
      	#  when an Access-Request is received.
      	#
      	#  The session-state attributes are automatically deleted after
      	#  an Access-Reject or Access-Accept is sent.
      	#
      	update {
      		&reply: += &session-state:
      	}
    2. Save the file.
  2. As root, find the post-auth section in the /etc/raddb/sites-available/inner-tunnel file.
    1. At the top of the post-auth section, insert the following text:

      Code Block
      	#
      	#  Return the User-Name
      	#
      	update reply {
      		User-Name := &request:User-Name
      	}
    2. Then look for the following text towards the bottom of the post-auth section:

      Code Block
      	#
      	#  Instead of "use_tunneled_reply", uncomment the
      	#  next two "update" blocks.
      	#
      #	update {
      #		&outer.session-state: += &reply:
      #	}
      
      	#
      	#  These attributes are for the inner session only.
      	#  They MUST NOT be sent in the outer reply.
      	#
      	#  If you uncomment the previous block and leave
      	#  this one commented out, WiFi WILL NOT WORK,
      	#  because the client will get two MS-MPPE-keys
      	#
      #	update outer.session-state {
      #		MS-MPPE-Encryption-Policy !* ANY
      #		MS-MPPE-Encryption-Types !* ANY
      #		MS-MPPE-Send-Key !* ANY
      #		MS-MPPE-Recv-Key !* ANY
      #		Message-Authenticator !* ANY
      #		EAP-Message !* ANY
      #		Proxy-State !* ANY
      #	}
       
    3. If the text does not exist, insert it above the comments that describe the line "Post-Auth-Type REJECT {".
    4. Remove the comments from the update statements in the text.
    5. Save the file.

Resource Provider Authentication

All Resource Providers in the Trust Router network, including all IdPs and RP Proxies and the Trust Router itself, need to authenticate themselves to the APC using Moonshot. This means that for every service or organisation, you must provision a credential on the APC.

Tip

In a production environment, we recommend you use a method of Resource Provider Authentication that integrates well with your chosen method of managing your Trust Router infrastructure.

See Configuring FreeRADIUS to Use a Local Identity Store for options to define credentials.

We recommend using an automatic means to provision credential files, such as an online portal.

Defining the APC credential

During testing, we recommend using the FreeRADIUS users file to define credentials that your Resource Providers can use to authenticate to the APC. We will create a user with username "testapc" and password "testing".

  1. Open /etc/raddb/users for editing and put the following at the top of the file:

    Code Block
    linenumberstrue
    testapc	Cleartext-Password := "testing"
    			Reply-Message = "Hello test user. You have authenticated!"
    Warning

    The formatting of the stanza above is very important. There should be a <tab> in between the username and Cleartext-Password, and a line break followed by a <tab> before the Reply-Message.

Provisioning the APC credential

For the APC credential you defined in the previous step, create a Moonshot credential XML file:

  1. Set the <user> tag to the credential you defined in the previous step, e.g. testapc
  2. Set the <password> tag to its appropriate password. You may wish to base64-encode the password.
  3. Set the <realm> tag to YOUR_APC_REALM.
  4. You can leave the <services> tag out.
  5. You should set the <selection-rules> tag to:

    Code Block
    titleselection-rules
    linenumberstrue
        <selection-rules>
           <rule>
             <pattern>trustidentity/*</pattern>
             <always-confirm>false</always-confirm>
           </rule>
        </selection-rules>
  6. Define either of the two trust anchors as per the moonshot-webp XML Format documentation.

    Note

    For simple test infrastructures, you may leave out the trust anchors, but it is not recommended

  7. Save the file, then deploy it onto the Trust Router that you are connecting to this APC (see Section 3.2.2 of Install a Trust Router).

Configure the Trust Router connection

The APC is fundamental to a Trust Router network, so the next step involves configuring the Trust Router client software and configuring its connection to a Trust Router.

Set up the FreeRADIUS and Trust Router users

We need to place the FreeRADIUS user and the Trust Router users into each other's groups to allow them to read shared files of each others.

Code Block
languagebash
$ usermod -a -G radiusd trustrouter
$ usermod -a -G trustrouter radiusd

Configure TIDS

The IdP also runs the Temporary ID Server (TIDS).

  1. Open the /etc/sysconfig/tids file for editing:

    Code Block
    linenumberstrue
    TIDS_SERVER_IP="[your server IP]"					# IP address that the TIDS is reachable on
    TIDS_SERVER_NAME="[your server hostname]"			# The host name that the TIDS is known as
    TIDS_USER="trustrouter"							# The user that the TIDS is running as
    TIDS_GROUP="trustrouter"							# The group that the TIDS is running as
    TIDS_GSS_NAME="testapc@YOUR_APC_REALM"			# The user name for the APC, defined in Section 4.1
    KEYFILE="/var/lib/trust_router/keys"				# The key file that the TIDS will store keys in
    
    ## Static variables that you can also adjust
    TIDS_PIDDIR="/var/run/trust_router"
    TIDS_LOGDIR="/var/log/trust_router"
  2. Open the /usr/lib/systemd/system/tids.service file for editing and check that the file includes the following lines:

    Code Block
    languagetext
    [Service]
    EnvironmentFile=/etc/sysconfig/tids
    ExecStartPre=/bin/sh -c "/usr/bin/sqlite3 </usr/share/trust_router/schema.sql /var/lib/trust_router/keys"
    ExecStart=/usr/bin/tids ${TIDS_SERVER_IP} ${TIDS_GSS_NAME} ${TIDS_SERVER_NAME} /var/lib/trust_router/keys
    Restart=always
    StandardOutput=syslog
    StandardError=inherit
    User=trustrouter
    Note
    titleTemporary workaround
    Edit the EnvironmentFile and ExecStart lines to match the above. We are fixing this in the next release.

Testing

Now that we have the Moonshot IdP installed and configured, we're now ready to test!

Tip
titleTip

At this point you probably want three consoles open on the server, so that you can manually run various components separately.

Testing FreeRADIUS locally

The first test is to check whether FreeRADIUS is working in its most basic manner.

  1. In window 1, run (as root user)

    Code Block
    languagebash
    $ radiusd -fxx -l stdout
    Note
    titleOpenSSL version issue

    FreeRADIUS may fail to start with an error message:

    Refusing to start with libssl version OpenSSL 1.0.1e-fips 11 Feb 2013 0x01000105f (1.0.1e-15) (in range 1.0.1-0 - 1.0.1f-15)
    Security advisory CVE-2014-0160 (Heartbleed)
    For more information see http://heartbleed.comOnce you have verified libssl has been correctly patched, set security.allow_vulnerable_openssl = 'CVE-2014-0160'

     

    This is because of how the version of OpenSSL is detected. If you are sure that you are fully up to date, then edit /etc/raddb/radiusd.conf and edit the end of the security { } section:

            #
            #allow_vulnerable_openssl = no
            allow_vulnerable_openssl = 'CVE-2014-0160'
    }

  2. In window 2, run (as root user)

    Code Block
    languagebash
    $ radtest testapc@YOUR-APC-REALM testing localhost 2222 testing123
    Info

    This uses the "radtest" utility which is used in the following way - radtest username password servername port shared-secret

  3. If this is working correctly you should see something like the following:

    Code Block
    titleIn window 1 - FreeRADIUS server output
    Sending Access-Accept of id 57 from 127.0.0.1 port 1812 to 127.0.0.1 port 33363
         Reply-Message = 'Hello test user. You have authenticated!'
    (1) Finished request 1.
    Waking up in 0.3 seconds.
    Waking up in 4.6 seconds.
    (1) Cleaning up request packet ID 57 with timestamp +94
    Ready to process requests.
    Code Block
    titleIn window 2 - radtest client output
    Sending Access-Request of id 57 from 0.0.0.0 port 33363 to 127.0.0.1 port 1812
         User-Name = 'testapc'
         User-Password = 'testing'
         NAS-IP-Address = 127.0.1.1
         NAS-Port = 2222
         Message-Authenticator = 0x00
    rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=57, length=61
         Reply-Message = 'Hello test user. You have authenticated!'

Testing the Trust Router connection

To test the connection to Trust Router, we need to make sure the Temporary Identity Server (TIDS) software is running, then use the Temporary Identity Client (TIDC) software to simulate a connection to the Trust Router.

Starting the Temporary Identity Server (TIDS)

In window 3 (window 1 should still be still running the FreeRADIUS server and window 2 the radtest command), run the TIDS software:

Code Block
languagebash
$ tids [your server IP] testapc@YOUR-APC-REALM [your server hostname] /var/lib/trust_router/keys

testapc@YOUR-APC-REALM is the identity that the trust router will use when provisioning keys - this makes it easy to spot in your own log files.
Specifying your server's IP and hostname may seem redundant (and for single server deployments, it is!). You'll need to set the hostname and IP arguments a little differently if you want to enable some more advanced configurations (such as load balancing and key sharing).

Info

This uses the "tids" binary which is used in the following way - tids [your-ip-address] trustrouter-gss-name] [your-hostname] [path-to-key-database]

Note

When using Network Address Translation (NAT) or a firewall, you must specify your external IP address.

 

Run an APC authentication test

At this point, you must configure your trust router to use testapc@YOUR-APC-REALM as authentication.

  1. The trust router configuration must be updated with the test user associated with your trust router's rp_realm filter lines.
  2. The trust router configuration must be updated with your new APC designated as the APC for your trust router.
  3. The trust router must have its Moonshot credential store updated with the test user and its password. See Section 3.2.2 of install a trust router (RHEL/CentOS/SL 6 or Debian 7)
  4. The trust router must be restarted. At this point, the trust router will attempt to authenticate itself to the APC.
  5. In the FreeRADIUS console, you should see an Access-Accept response.

 

Next Steps

At this point, you now have a Moonshot APC that is working. Now for the next steps:

Automatically start the software

FreeRADIUS

To automatically start FreeRADIUS, issue the following command (as root):

Code Block
$ sudo chkconfig radiusd on

If this is working correctly, you should see FreeRADIUS running as a daemon process.

TIDS

To automatically start TIDS, issue the following command (as root):

Code Block
$ sudo chkconfig tids on
$ sudo service tids start 

If this is working correctly, you should see TIDS running as a daemon process.

Configure a real source of Authentication

Your FreeRADIUS server can currently only authenticate a single user - "testapc". At this point, you will want to connect FreeRADIUS to your management database. The FreeRADIUS site has information and instructions for how to do this.