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.
eap-aes128 1.3.6.1.4.1.5322.22.1.17 mech_eap.so
eap-aes256 1.3.6.1.4.1.5322.22.1.18 mech_eap.so
-#Testing Functionality
+##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
+##Sample Output
Attribute local-login-user Authenticated Complete
Received message: "testing"
Signature verified.
NOOP token
+
+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.
+
+##SSH
+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:<br />
+Uncomment __UsePrivilegeSeparation__ and set it to __‘no’__
+
+ UsePriviligeSeparation no
+
+Uncomment __GSSAPIAuthentication__ and set it to __‘yes’__
+
+ GSSAPIAuthentication yes
+
+Uncomment __GSSAPIKeyExchange__ and set it to __‘yes’__
+
+ GSSAPIKeyExchange 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’__
+
+ 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.<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_!<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