X-Git-Url: http://www.project-moonshot.org/gitweb/?a=blobdiff_plain;f=ConfiguringRHEL.mdwn;h=d13d2a5dc249e59192570f376cf88f1c5c6f686f;hb=809769d55e607aa1c4675832fec744facb956fae;hp=019ece6d3e33258bf5aef10cb1a14fcc01150735;hpb=f5d214384ad3818c32ec8e8587e7960145390a40;p=devwiki.git diff --git a/ConfiguringRHEL.mdwn b/ConfiguringRHEL.mdwn index 019ece6..d13d2a5 100644 --- a/ConfiguringRHEL.mdwn +++ b/ConfiguringRHEL.mdwn @@ -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: - + 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: + @@ -172,21 +172,23 @@ 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.
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): - /opt/moonshot/bin/gss-client -mech "{1 3 6 1 4 1 5322 22 1 18}" 127.0.0.1 host@localhost bar +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.5.5.15.1.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: + /opt/moonshot/bin/gss-client -spnego 127.0.0.1 host@localhost bar ##Sample Output @@ -220,7 +222,9 @@ This chooses the "best" mutually-agreeable encryption method for between client 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.
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 @@ -228,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:
Uncomment __UsePrivilegeSeparation__ and set it to __‘no’__ @@ -268,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.
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