Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Problem

I can't seem to be able to connect my service to the trust router infrastructure. I get the following error when running the TIDC command:

Error returned by gss_init_sec_context:
      major error <1> Unspecified GSS failure. Minor code may provide more information
      minor error <1> Missing default password or other credentials
AuthenticateToServer failed: Missing default password or other credentials (err = 2109382948)
Error in tidc_open_connection.

Possible Solutions:

Check the following:
  1. You are running the newest version of the trust router and Moonshot software. If you were part of the Moonshot Pilot Workshop in February 2014, you must update your software to the newest version as Trust Router 1.2 is not backward compatible.
  2. You have installed the dbus-x11 package. This package is not installed as part of the package dependencies, but it is part of the instructions in Section 2 of Install a Moonshot IdP on Debian 7. It is a client library and will not require the installation of the X11 system.
  3. You have the FreeRADIUS user (freerad on Debian systems, radiusd on RHEL systems) listed in /etc/moonshot/flatstore-users.
  4. You have imported the Trust Router credentials using the moonshot-webp command as the FreeRADIUS user in Section 5.3.1 of Install a Moonshot IdP on Debian 7. To verify you have, execute ls -la ~/.local/share/moonshot-ui/identities.txt as the FreeRADIUS user, and you should see the file listed.
  5. You are running the TIDC command as the FreeRADIUS user and that you have run the unset DISPLAY command before running the TIDC command.
  6. If your service is firewalled, check that TCP ports 2083 and 12309 are open both in- and outbound, and that the public IP address is the one you gave Adam Bishop. Ideally, your firewall should also support hairpinning.
  7. If you use Network Address Translation (NAT), check that you are forwarding TCP ports 2083 and 12309 both in- and outbound, and that the public IP address is the one you gave Adam Bishop.

 

Problem

I can't seem to be able to connect my service to the trust router infrastructure. I get the following error in my TIDS window when attempting to authenticate:

Error returned by gss_acquire_cred:
      major error <1> Unspecified GSS failure. Minor code may provide more information
      minor error <1> /etc/radsec.conf: unable to open configuration file
Authenticate failed: Unknown code FF 164 (err = 100004)
tids_auth_connection: Error from gsscon_passive_authenticate(), rc = 100004.

Solution:

Check the following:
  1. You have /etc/radsec.conf present. Without this file, TIDS will start but will not be able to function.
  2. You have /etc/radsec.conf configured as per Section 4.1.3 of Install a Moonshot IdP on Debian 7. It must be configured for TLS for TIDS to function correctly.

 

Problem

I can't seem to be able to connect my service to the trust router infrastructure. I get the following error in my TIDS window when I attempt to authenticate:

Error returned by gss_accept_sec_context:
      major error <1> Invalid credential was supplied
      minor error <1> Authentication rejected by RADIUS server
Authenticate failed: Authentication rejected by RADIUS server (err = 2109382925)
tids_auth_connection: Error from gsscon_passive_authenticate(), rc = 2109382925.

Possible Solutions:

Check the following:
  1. You are running the freeradius -fxx -l stdout command as the FreeRADIUS user and you have executed the unset DISPLAY command beforehand. Without running unset DISPLAY, the TID client (TIDC) connection will fail. Additionally, you may see something similar to the below in your FreeRADIUS debug output:

    (0) tls_recv: Access-Request packet from host 127.0.0.1 port 38852, id=0, length=123
    Thread 3 handling request 3, (1 handled so far)
    User-Name = '@apc.moonshot.ja.net'
    GSS-Acceptor-Service-Name = 'trustidentity'
    GSS-Acceptor-Host-Name = '[your rp-realm]'
    EAP-Message = 0x020300061500
    State = 0x7195531f739646b79406b798ba6d1405
    Message-Authenticator = 0xebea14afb1c4804d9a6bd83f4746ec76
    (3) suffix : Looking up realm "apc.moonshot.ja.net" for User-Name = "@apc.moonshot.ja.net"
    Openning TIDC connection to tr1.moonshot.ja.net:0Error in tidc_open_connection.

    (3) suffix : No such realm "apc.moonshot.ja.net"
    (3) [suffix] = noop
     

  2. If you are using the attr_filter module, add the GSS-Acceptor-Host-Name, GSS-Acceptor-Service-Name, GSS-Acceptor-Realm-Name and GSS-Acceptor-Service-Specifics attributes to your pre-proxy and post-proxy filters. Modify the /etc/mods-config/attr_filter/pre-proxy and post-proxy files and add the following lines under DEFAULT:

    DEFAULT
    <tab>GSS-Acceptor-Service-Name =* ANY,

    <tab>GSS-Acceptor-Host-Name =* ANY,
    <tab>GSS-Acceptor-Service-Specifics =* ANY,
    <tab>GSS-Acceptor-Realm-Name =* ANY,


    The trust router requires the GSS-Acceptor-* attributes to be present in trust router authentication attempts. These entries are currently not in the standard distribution, but they will be soon.

 

Problem

I can't seem to be able to connect my service to the trust router infrastructure. I get the following error in my TIDS window when attempting to authenticate:

Authenticate failed: Operation not permitted (err = 1)
tids_auth_connection: Error from gsscon_passive_authenticate(), rc = 1.
tids_handle_connection: Error authorizing TID Server connection.
Error in tids_start(), rc = 0. Exiting.

Possible Solutions:

Check the following:
  1. If you are using the attr_filter module, you must not filter out the User-Name attribute. Check the /etc/mods-config/attr_filter/pre-proxy and post-proxy files and check that the User-Name attribute appears in both files.
  2. If you are using the cui module in the post-auth section of your default server (not the inner-tunnel server), check /etc/raddb/policy.d/cui for the below lines in the cui.post-auth stanza:

    update reply {
    User-Name -= "%{reply:User-Name}"

    }

    Comment them out, or move them to above the previous closing curly bracket. TIDS requires the username trustrouter@apc.moonshot.ja.net to be in its Accept-Accept reply from the RADIUS server.

  3. Alternatively, wrap the cui call in the post-auth section into a piece of unlang that prevents the cui module from running for trust router replies:

    if (!("%{request:GSS-Acceptor-Service-Name}" == 'trustidentity' && "%{request:GSS-Acceptor-Host-Name}" == '[your rp-realm]')) {
    cui
    }

 

More to come...

  • No labels