Intended for: Offsite users who need to access Fermilab strengthened realm
Scenario/Use case:
This article describes what offsite users need to do in order to access Fermilab's strengthened realm, and some of the issues they may encounter.
Instructions:
Since offsite machines at universities may be shared by many people, some of whom do not access Fermilab at all, offsite users are not required to install a Kerberos 5 server. Offsite machines participating in Fermilab's strengthened realm have a choice of authentication methods, including ssh with passwords, public/private keys, host-based keys or Kerberos. Access to a system onsite at Fermilab is more limited, requiring Kerberos credentials or an RSA token.
Description of Choices for Offsite Machines
The choices for off-site machines include:
- Install the Kerberos client and the Kerberized ssh client software on your machines and sign up to be part of the FNAL.GOV strengthened realm and install the Fermilab Kerberos configuration file. This means you can authenticate to Kerberos locally and connect to Fermilab computers using the Kerberized version of a network connection program.
- Leave your machines unstrengthened and always log in to Fermilab via a gateway system (like FNALU) using your RSA SecureID token (see Using RSA SecureID Token). Note that if you choose to do this, you will need to use ssh as the transport program. You must NEVER type in your password if you are on an unencrypted channel! There is no way to perform any Kerberos command that requires a password while logged in using an X-terminal. And please, as much as possible, try to limit performing operations that involve typing your Kerberos password over the network.
- Your site may have its own version of strong authentication which may be acceptable to Fermilab and then you could become a trusted realm.
Export of MIT Kerberos V5 might still be restricted in some cases; see the MIT Kerberos Distribution page. Heimdal Kerberos is another v5-compatile implementation that was explicitly developed outside the United States to avoid export regulations; see the Heimdal site.
If people need to log in from your site to change their passwords, there should be at least one local machine on which there is software which will allow it to be done locally (best) or over an encrypted connection to a Fermilab machine (second best).
Obtaining RSA SecureID Tokens
All users, onsite and offsite, can request an RSA SecureID token using the RSA Token Request form at ServiceNow Service Catalog: RSA Token Request. If you visit Fermilab occasionally, come by Wilson Hall Ground Floor to pick it up when it's ready. For those experimenters or other users who will not be visiting Fermilab, an RSA token can be mailed to you. Each group or experiment should have a person designated to mail RSA Token; contact the appropriate person to request mailing.
If you lose your RSA SecureID token or it becomes unusable for any reason, please open a Service Desk ticket (ServiceNow or email servicedesk@fnal.gov) to request a new one. Then ask the person designated for your group or experiment to pick it up and mail it to you. Currently we do not have a way of restoring your access more quickly.
Network Address Translation
There is an issue concerning users who maintain a small network of computers at home and whose ISP subjects them to NAT (Network Address Translation). NAT creates a firewall of sorts in which one computer (or the router itself) sits on your assigned IP address and routes traffic to a number of machines inside your house (wireless or not), all at the same time, using that one IP address.
When you authenticate, normally your IP address is part of that authentication. But that would be your local IP address, the one the machine knows, not the one that the outside world knows you by. Authentication won't work in this case. You can get an addressless ticket that doesn't have this problem.
A remote process (e.g., X Client) must be able to send its messages back to the correct machine through the NAT. The two simplest ways to do this are:
- Use Fermilab's VPN (Virtual Private Network) to tunnel through the NAT. This gives you a Fermilab address (...fnal.gov) for Fermilab machines, but to the rest of the world, your address is still the one your ISP gave you. You must use VPN for tasks such as connecting to Windows disk servers on site, changing your Windows password, etc.
- Tunnel through the NAT using ssh.
Kerberos 5 has the ability to natively generate addressless tickets So you can use kinit -A instead of plain kinit to obtain a Kerberos ticket not bound to a particular IP address, which can then be passed through your firewall. In this case, the problem described above doesn't arise.
Firewalls
Another possible hurdle for off-site users is that their Kerberos clients being used to connect to Fermilab systems are located behind restrictive firewalls at their local site. These firewalls need to have rules modified to permit Kerberos to communicate with KDC and other authentication services at Fermilab. The list of the IP ports that need to be opened through the firewall can be found in the article Ports Needed by Kerberos.
See Also: