(no commit message)
[devwiki.git] / ConfiguringRHEL.mdwn
index 5dc1b9a..30acacc 100644 (file)
@@ -1,6 +1,6 @@
-First we need to install and configure moonshot, its dependencies, and a local RADIUS server for testing
-In a real deployment, a local RADIUS server is not needed, however it simplifies testing if one is available
-__gss-server__ and __gss-client__ are standard Kerberos diagnostic tools, which give us a lot of information that is helpful for debugging
+First we need to install and configure moonshot, its dependencies, and a local RADIUS server for testing<br />
+In a real deployment, a local RADIUS server is not needed, however it simplifies testing if one is available<br />
+__gss-server__ and __gss-client__ are standard Kerberos diagnostic tools, which give us a lot of information that is helpful for debugging<br />
 Again, in a real deployment these are not required, but help with testing
 
 This guide walks through deploying the client, IdP and SP portions of moonshot - depending on your target, some steps may be inappropriate.
@@ -10,11 +10,15 @@ This guide walks through deploying the client, IdP and SP portions of moonshot -
 __LD_LIBRARY_PATH__ has to have _/opt/moonshot/lib64/_ and _/usr/lib64/freeradius_ added to it.<br />
 The best way to do this is create a file at _/etc/profile.d/moonshot.sh_, with the following:
 
-    if [ [ $LD_LIBRARY_PATH != */opt/moonshot/lib64/:/usr/lib64/freeradius/* ] ]
+    if \[[ $LD_LIBRARY_PATH != */opt/moonshot/lib64/:/usr/lib64/freeradius/* ]]
     then
        export LD_LIBRARY_PATH=/opt/moonshot/lib64/:/usr/lib64/freeradius/:$LD_LIBRARY_PATH
     fi
 
+After, either restart your shell session, or:
+
+    source /etc/profile.d/moonshot.sh
+
 This is required as moonshot currently stores its modified libraries separately to the main system ones to avoid conflicts.  This should not be necessary in the future.
 
 
@@ -63,6 +67,7 @@ Moonshot has a couple of outstanding issues regarding proper labeling of _SELinu
 Moonshot needs __EPEL__ for a few extra libraries (as pulling them from a semi-supported repository is preferable to repackaging).<br />
 The simplest way to install EPEL is:
 
+    rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
     yum install epel-release
 
 ## Moonshot Packages
@@ -168,23 +173,23 @@ In the demo we just use a very simple example – mapping the _Chargeable-User-I
 
 Delete _/etc/shibboleth/attribute-map.xml_ and replace it with:
 
-
     <Attributes xmlns="urn:mace:shibboleth:2.0:attribute-map" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
         <GSSAPIAttribute name="urn:ietf:params:gss-eap:radius-avp urn:x-radius:89" id="local-login-user"/>
     </Attributes>
 
 In this case, 89 corresponds to _Chargeable-User-Identity_, which is mapped to _local-login-user_, which sets the local account that the user will be given access to.
 
-To load the moonshot extensions, under the root node in /etc/shibboleth/shibboleth2.xml, add:
+To load the moonshot extensions, under the root node in _/etc/shibboleth/shibboleth2.xml_, add:
     <Extensions>
         <Library path="plugins.so" fatal="true"/>
     </Extensions>
 
-
 Further down the same file, find this line:
+
     <AttributeExtractor type="XML" validate="true" path="attribute-map.xml"/>
 
 Directly underneath it, add:
+
     <AttributeExtractor type="GSSAPI" validate="true" path="attribute-map.xml"/>
 
 Note that this file is sensitive to the order of statements.
@@ -204,16 +209,16 @@ This file tells moonshot what encryption options are valid for use with GSS.
 
 ##Testing Functionality
 
-As mentioned earlier, we will be using the Kerberos test tools to make sure that things are working.
-To start the gss-server, run:
+As mentioned earlier, we will be using the Kerberos test tools to make sure that things are working.<br />
+To start the _gss-server_, run:
     /opt/moonshot/sbin/gss-server host@localhost &
 
-There are two ways to start gss-client – the first specifies an encryption method to use by its OID 1.3.6.1.4.1.5322.22.1.18 (as seen in /etc/gss/mech):
+There are two ways to start _gss-client_ – the first specifies an encryption method to use by its OID 1.3.6.1.4.1.5322.22.1.18 (as seen in /etc/gss/mech):
     /opt/moonshot/bin/gss-client -mech "{1 3 6 1 4 1 5322 22 1 18}" 127.0.0.1 host@localhost bar
 
 
-The second uses Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)
-This chooses the "best" mutually-agreeable encryption method for between client and server.  To invoke the client using SPNEGO, use:
+The second uses __Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)__<br />
+This chooses the "best" mutually-agreeable encryption method for between client and server.  To invoke the client using __SPNEGO__, use:
     /opt/moonshot/bin/gss-client -spnego 127.0.0.1 host@localhost bar
 
 ##Sample Output
@@ -244,8 +249,8 @@ This chooses the "best" mutually-agreeable encryption method for between client
     Signature verified.
     NOOP token
 
-Running gss- client produces a massive amount of output.
-The important part is at the end – you should see output similar to what is on the previous slide.
+Running _gss-client_ produces a massive amount of output.<br />
+The important part is at the end – you should see output similar to what is on the previous slide.<br />
 If you do not see the line:
     Attribute local-login-user Authenticated Complete
 Then attribute mapping is not functioning properly, and you need to check your shibboleth configuration.
@@ -256,42 +261,44 @@ To install moonshot-enabled SSH:
     yum install openssh-moonshot-clients openssh-moonshot-server
 
 
-Inside /etc/ssh/sshd_config, and if these values are not set already:
-
-Uncomment UsePrivilegeSeparation and set it to ‘no’
+Inside _/etc/ssh/sshd\_config_, and if these values are not set already:<br />
+Uncomment __UsePrivilegeSeparation__ and set it to __‘no’__
 
        UsePriviligeSeparation no
 
-Uncomment GSSAPIAuthentication and set it to ‘yes’
+Uncomment __GSSAPIAuthentication__ and set it to __‘yes’__
 
        GSSAPIAuthentication yes
 
-Uncomment GSSAPIKeyExchange and set it to ‘yes’
+Uncomment __GSSAPIKeyExchange__ and set it to __‘yes’__
 
        GSSAPIKeyExchange yes
 
-Inside /etc/ssh/ssh_config and if these values are not set already:
-
-Uncomment GSSAPIAuthentication and set it to ‘yes’
+Inside _/etc/ssh/ssh\_config_ and if these values are not set already:<br />
+Uncomment __GSSAPIAuthentication__ and set it to __‘yes’__
 
        GSSAPIAuthentication yes
 
-Uncomment GSSAPIKeyExchange and set it to ‘yes’
+Uncomment __GSSAPIKeyExchange__ and set it to __‘yes’__
 
        GSSAPIKeyExchange yes
 
 ###Running SSH
 
 Finally, we need to start sshd on a seperate port:
-    /opt/moonshot/sbin/sshd –p 2222
 
-At this time we do not recommend running openssh-moonshot as the systemwide SSH client or server – it should be installed alongside the the standard SSH client and server.
-Also note, that sshd must be invoked with its full path, i.e. /opt/moonshot/sbin/sshd.
+    /opt/moonshot/sbin/sshd –p 2222
 
+At this time we do not recommend running __openssh-moonshot__ as the systemwide SSH client or server – it should be installed alongside the the standard SSH client and server.<br />
+Also note, that sshd must be invoked with its full path, i.e. _/opt/moonshot/sbin/sshd._
 
 Finally, try connecting with the following:
+
     /opt/moonshot/bin/ssh –p 2222 –l "" 127.0.0.1
 
-With any luck, magic happens and you are logged in as the user specified in your Chargeable-User-Identity!
-After successfully logging in, don’t forget to type "exit" to end the SSH session and return to the root shell.
-Note in the SSH client command, the option -l "" – this signifies that no username is to be sent to the SSH server. 
+With any luck, magic happens and you are logged in as the user specified in your _Chargeable-User-Identity_!<br />
+After successfully logging in, don’t forget to type __exit__ to end the SSH session and return to the root shell.<br />
+Note in the SSH client command, the option __-l ""__ – this signifies that no username is to be sent to the SSH server. 
+
+##Remote IdP
+This is left for an exercise for the user - at this stage it should just be a case of changing _/etc/radsec.conf_ to point at the right RADIUSd