Changed shibboleth attribute map to use current correct radius attribute, corrected...
[devwiki.git] / ConfiguringRHEL.mdwn
index 94be5b9..d13d2a5 100644 (file)
@@ -107,7 +107,6 @@ When in debug mode, FreeRADIUS acts as an interactive program, so it should be r
 ##Moonshot Proper
 First we need a minimal _/etc/radsec.conf_
 
-    dictionary = "/etc/raddb/dictionary"
     
     realm gss-eap {
         type = "UDP"
@@ -142,12 +141,13 @@ 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"/>
+        <GSSAPIAttribute name="urn:ietf:params:gss:radius-attribute 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:
+
     <Extensions>
         <Library path="plugins.so" fatal="true"/>
     </Extensions>
@@ -172,18 +172,19 @@ This file tells moonshot what encryption options are valid for use with GSS.
     # Any encryption type supported by Kerberos can be defined as the
     # last element of the OID arc.
     #
-    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
-
+    eap-aes128 1.3.6.1.5.5.15.1.1.17 mech_eap.so
+    eap-aes256 1.3.6.1.5.5.15.1.1.18 mech_eap.so
+   
 ##Testing Functionality
 
 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.5.5.15.1.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
+    /opt/moonshot/bin/gss-client -mech "{1.3.6.1.5.5.15.1.1.18 }" 127.0.0.1 host@localhost bar
 
 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:
@@ -221,7 +222,9 @@ This chooses the "best" mutually-agreeable encryption method for between client
 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
@@ -229,7 +232,6 @@ 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’__
 
@@ -269,5 +271,59 @@ With any luck, magic happens and you are logged in as the user specified in your
 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. 
 
+##Common Issues:
+
+###If you see:
+
+    connecting to server: Connection refused
+
+_gss-server_ is not running – start it again, and check its output for any reasons why it doesn't stay running
+
+###If you see:
+
+    GSS-API error initializing context: Unspecified GSS failure.  Minor code may provide more information
+    GSS-API error initializing context: SPNEGO cannot find mechanisms to negotiate
+    reading token flags: 0 bytes read
+
+Then _/etc/gss/mech_ is invalid or missing
+
+###If you see:
+
+    Sending init_sec_context token (size=101)...continue needed...
+    CTRL-EVENT-EAP-STARTED EAP authentication started
+    GSS-API error accepting context: Unspecified GSS failure.  Minor code may provide more information
+    GSS-API error accepting context: 
+    Sending init_sec_context token (size=43)...continue needed...
+    GSS-API error initializing context: Unspecified GSS failure.  Minor code may provide more information
+    GSS-API error initializing context: SPNEGO failed to negotiate a mechanism
+
+Your RADIUS server may not be running, or malfunctioning, run it in debug mode (as mentioned earlier) to find out why.
+
+###If you see:
+
+       Segmentation fault
+
+Then _~/.gss\_eap\_id_ is invalid or missing
+
+###If you see:
+
+       CTRL-EVENT-EAP-METHOD EAP vendor 0 method 4 (MD5) selected
+
+Then you have not correctly set the _default\_eap\_type_ on the RADIUS server.
+
+###If you see:
+
+    GSS-API error gss_pname_to_uid: Unspecified GSS failure.  Minor code may provide more information
+    GSS-API error gss_pname_to_uid: Unknown error
+
+Then there is not a local user that matches your Chargeable-User-Identity
+
+###If you see…
+
+    /opt/moonshot/bin/gss-client: relocation error: /opt/moonshot/bin/gss-client: symbol gss_acquire_cred_with_password, version gssapi_krb5_2_MIT not defined in file libgssapi_krb5.so.2 with link time reference
+
+Then LD_LIBRARY_PATH is not properly set
+
+
 ##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