cdlogo
Departments | Computing Division | Fermilab at Work | Fermilab Home
_____________________________________________________________________________________________________
Computing Division

Strong Authentication at Fermilab
Frequently Asked Questions

Strong Authentication at Fermilab Welcome Page
Acknowledgments and References - Abstract - Updates

Topics:

General

Q: What's the procedure for requesting principals? There is a need (rarely) for 24x7 host principal regeneration.
A: Fill out the Form to Request Kerberos Principal and/or Related Items at http://www.fnal.gov/cd/forms/strongauth.html. Procedure for 24x7 support not yet in place. Off hours emergencies currently dealt with by normal emergency escalation (x2746)
Q: Can you have shared accounts?
A: Only through the krb5.login method.
Q: Can we define "group principals"?
A: No, the KDC can't handle them. Instead, create a group account on a machine, then in its krb5.login, include all principals who need to access that account.
Q: Explain what host and ftp principals are for.
Host and ftp principals are needed for offering services (and thus allow incoming kerberos connections) on a machine. Only if the host offers the ftp service does it need the ftp principal. Only if the host offers the rsh, rlogin or telnet service does it need the host principal. Often both are needed.
The host and ftp principals aren't for any particular account; they do not help to identify a user on the host in any way. The only connection to any account is that, since the keytab for the service key is readable only by root, a process running as root can use the key to authenticate as "host/node.dom.ain".
Q: When will the transition from PILOT.FNAL.GOV to FNAL.GOV occur?
A: It is occurring now, and is close to complete (as of Dec 2001).
Q: If I have Windows 2000 installed on my desktop now, am I Kerberized?
A: No. You will be Kerberized once you have been migrated to the Win2000 domain. See Migration from NT4 Domain to Windows 2000 Domain.
Q: How, when and by whom will access to Windows 2000 resources be supported for FNAL KRB5 Unix clients ? by MIT KRB5 clients ? by non Win2000 Windows machines ?
A: Needs discussion

Policy-Related Questions

Q: What's Fermilab's strong authentication policy in a nutshell?
A: See The Strong Authentication Policy in a Nutshell The Strong Authentication Policy in a Nutshell
Q: Regarding network infrastructure, components, peripherals, etc., what criteria do I use to determine if a particular machine needs to be Kerberized?
A: Our current working definition is: If you can log into it and run arbitrary code, it needs to be Kerberized.
Q: Can exemptions to the Fermilab policy on strong authentication be obtained? Under what circumstances?
A: For systems on which Kerberos authentication cannot be implemented, and alternate solutions (e.g., putting the system behind a firewall) are unworkable, you may apply for an exemption. Go to your experiment’s or your division’s computer security representative to request an exemption.
Q: What's the policy for transient machines (e.g., laptops that stay at Fermilab only short periods of time)?
Laptop machines brought in by visitors for short periods of time (eg. < 1 week) do not need to be registered or strong authenticated. Visitors may use their host's accounts with their permission at the host's responsibility. Local accounts that allow access only at the console will be permitted for visitors (no NIS accounts). Facilities primarily created for visitors may be granted wavers from the requirement for Kerberos validated users.
Q: What are the penalties of noncompliance with the policy on strong authentication?
A: First, if you're making the effort to comply but you won't make the 12/31/01 deadline, apply for an exemption. The Computing Policy states: Hosts found to be noncompliant may be barred from obtaining Kerberos tickets from our realm. If the noncompliance is deliberate or extremely careless it may be deemed to constitute blatant disregard for computer security.
Q: Can I use Kerberos V5 from sources other than Fermilab?
A. Yes, but you won't have all the Fermilab custom features (e.g., CRYPTOCard access). For UNIX machines of all the supported flavors, Kerberos V5 is most easily implemented via the Fermilab kerberos product. kerberos is available as a UPS product in the Fermilab Computing Division product repository KITS. For Linux 6.x and 7.x it's also available in RPM format.
For machines running operating systems not supported by the Computing Division, the MIT Kerberos product can be used. Check the MIT web site Kerberos: The Network Authentication Protocol at http://web.mit.edu/kerberos/www/, or the Heimdal site3 at http://www.pdc.kth.se/heimdal/. Look through the kerberos-pilot@fnal.gov mailing list archives at http://listserv.fnal.gov/archives/kerberos-pilot.html for some users' questions and ideas on this issue (some discussion occurred in March 2001).
Q: What becomes of ssh access such as RSAAuthentication and RhostsRSAAuthentication ?
A: They will not be allowed for on-site machines.
Q: What are my choices for implementing strong authentication? Are my choices different depending on whether the machine is on-site or off-site?

A: See Authentication Guidelines for On-site vs. Off-site Machines .

For Windows, we plan to replace the NT domain by a Windows 2000 domain, which implements Kerberos V5 authentication across the domain. WRQ Reflection software (the kerberized telnet and ftp clients) will still be necessary for accessing kerberized UNIX machines from a Windows machine. Accessing a Windows 2000 machine from UNIX is as yet unresolved.

Using Kerberos

Q: How do make sure my connection to a kerberized machine is encrypted?
A: If you're coming from a PC, go through a properly configured WRQ kerberized connection, or (off-site) use an encrypted ssh connection.
If you're using an X terminal, YOUR CONNECTION IS NOT ENCRYPTED, PERIOD! Don't ever type your Kerberos password on an X terminal.
If you're connecting from a non-Kerberized UNIX machine, use ssh with CryptoCard support.
If you're connecting from a Kerberized UNIX machine, set up the kerberized connection programs such that encryption is turned on, or use the -x (lowercase) option for telnet, rlogin, rsh, rcp. For ftp, set "protect level private" at the ftp> prompt.
See Encrypted vs. Unencrypted Connections.
Q: Problems with X authentication. Typically from someone who has been using non-Kerberos-aware ssh
A: Possible solutions: a) install Kerberos-aware ssh from KITS or ftp.funet.fi; b) instruct in using xauth, e.g., /usr/krb5/bin/rsh -n -x -l username target xauth add `xauth list $DISPLAY`; c) as fallback, "xhost +nodename"
Q: When I log in via WRQ Reflection telnet to a Kerberized UNIX machine that runs AFS, do I automatically get an AFS token?
A: If you've configured the software to forward tickets, yes.
Q: I'm running WRQ on my PC, and I have Reflection Admit One on my task bar and I can't kill it. Do I need it? If not, how do I get rid of it?
A: You generally don't need it. See http://support.wrq.com/techdocs/1291.html.
Q: Does the use of Kerberized ftp mean that we can no longer use wu-ftp for anonymous ftp configurations?
A: Yes. You can use wu-ftpd if the server is for anonymous access only. But until and unless it does Kerberos, it's an either/or. That is, wu-ftp and anonymous-only, or kerberos ftpd with its very limited configuration knobs.
Q: How are unattended processes (which require network access) started, e.g. at boot time? Are there special provisions for this, e.g. special principals?
A: See section 10.3 Automated Processes of the manual.
Q: Is there an (automated) way to forward updated tickets? I.e. can you renew tickets in one place and propagate them elsewhere? Is this desireable?
A: See 9.2.6 Push Local Tickets to Remote Machines .
Q: Is there any secure way to use an X terminal? .
A: Well, you can log into a Kerberized machine from an X terminal using a CRYPTOCard, but your connection is not encrypted. Therefore, never type your Kerberos password from the X terminal
Q: Issues about running Kerberos when you don't have root. Can you run clients when you don't control the rest of the machine? Or can you only use CryptoCard access?
A: Technical: Yes, Kerberos clients can be run without root access, except ksu. See:http://www.fnal.gov/cd/security/StrongAuth/OSS/img9.htm

Login and Passwords

Q: Are users notified when passwords are close to expiring? How long are passwords good for? What are all the rest of the password policies?
A: kinit with a password warns you if the expiration is coming within less than 30 days -- you don't even have to upgrade your kerberos version. You also get warned upon Kerberos login, either password or Cryptocard. Passwords are good for 400 days, once the user changes his/her initial password.
Q: Is there any account lockout for failed login attempts?
A: No account lockout.
Q: Are local accounts allowed for a person's desktop (for that person)? What about on NIS clusters? I.e. under what conditions are local accounts and passwords allowed? What do you do otherwise when the network is down?
A: FNAL Policy is that no reuseable login password should go across the public net. Local accounts would be permitted for login at the console only. OSS Policy should be to not administer local accounts other than to the machine "owner" or special cases restricted to console login only. No NIS passwords allowed.
Q: How does Kerberized login fall back if KDC is unreachable? Does it fail to local login?
A: A local login (at console) with the Kerberos password fails if the KDCs are unreachable. There is no automatic fallback, but you can login with standard UNIX password. Network logins, other than via Cryptocard, are unaffected by the host's inability to reach a KDC at that moment, assuming valid credentials are presented. If you enter the name "root" to the local login prompt, the password you subsequently give is not checked against Kerberos, only against the local password file (or NIS, or what-have-you).
Q: When should AFS Kerberos4 passwords "go away"? (Obviously not until everything that uses AFS is Kerberized.) Should (is) AKLOG=TRUE the default?
A: OSS Policy: For the time being, they are still needed and will not go away. They are however divorced from login passwords now. Technical: AKLOG=TRUE is the default for AFS systems (if AFS is installed when Kerberos is installed).
Q: Is there any potential of making some secure way of transferring passwords and/or making it so that those from off-site institutions with the correct kerberos credentials can view certain web pages that until now were restricted to on-site access only? clarify question
A: Technical: There is a method floating around for the generation of shortlived PKI certificates on presentation of a valid Kerberos token. This would allow standard browsers to present credentials that the standard https:// mechanisms could use. This is development work that is not viewed as critical for rollout, but interesting.
FNAL Policy: People are allowed to keep password files for restriction of web pages. Those passwords are NOT allowed to be ones that grant login access to machines.

Error Messages

Q: What causes: Error "Preauthentication failed while getting initial credentials"?
A: Nearly always caused by either: (a) wrong password-- contact compdiv@fnal.gov or 630-840-8118 to reset; or (b) system clock off by >5 minutes. Use xntp, or set clock by hand.
Q: Error "Cannot contact any KDC for requested realm".
A: Much less clear. Could be: a) Network problems, so can't reach KDC b) Name server problems--can't resolve "krb-pilot-1.fnal.gov" or etc. c) Behind a firewall that blocks one or more needed ports--see services file, e.g., ports 88, 543, 749.
Q: Attempt to connect gets "Password has expired while getting initial credentials".
A: This is usually just that, the user's Kerberos password has expired. Often happens with people who use only CryptoCards, and thus don't think about their Kerberos passwords. Solution is to use or borrow a workstation with Kerberos software, and "kpasswd [username]". (Or, since they often don't remember their Kerberos password, contact compdiv@fnal.gov or 630-840-8039 to get it reset.)
Q: No credentials cache found
A: This is the error you'd expect to see if you had no tickets, or if they got clobbered. If several principals are validated into the same account, they could probably clobber each other. Do a klist to see what the ticket caches are set to, and/or the value of the KRB5CCNAME environment variable. If they match, they're overwriting their ticket caches.
Q: Attempt to connect fails with: error getting credentials:
A: Incorrect net address. Often caused by offsite machines that use NAT (network address translation), so the address of the user's machine appears different on the user's side from the Fermilab side. Can work around by putting into the [libdefaults] section of /etc/krb5.conf the line: proxy_gateway=cust1735.evil-natting-isp.net
Q: Attempt to connect fails silently at client end. System log for target node shows something like: telnetd[52557945]: warning: can't verify hostname: gethostbyname(node.domain.net) failed
A: An ISP (or other network provider) hasn't registered the address properly, so reverse lookup fails. Have to get the ISP to fix this.
Q: Error: do_ypcall: clnt_call: RPC: Timed out
A: Local problem on your system or site network. Probably your machine is using YP, aka NIS, for host name-to-address resolution and you have a transient problem with your YP server(s).
Q: Kerberos V5: error getting forwarded creds - KDC can't fulfill requested option
You remembered to tell kinit not to ask for a forwardable ticket, but you forgot to tell telnet not to forward the ticket! Add "-N" to your telnet command.
Q: Couldn't authenticate to server: Server rejected authentication ... Key version number for principal in key table is incorrect
A: This means your ticket was obtained before "ups install-hostkeys kerberos" was done. Get rid of your ticket by doing kinit -R (if TGT is renewable), or kinit and your password (if not renewable, and IF YOUR CONNECTION IS ENCRYPTED). Otherwise log out/in again with CryptoCard and retry rlogin or whatever program you used.

For more info, see Troubleshooting your Authentication Problems .

Code Distribution

Q: What is the proper way to configure CVS and instruct CVS client users? Particularly for the case of a strengthened CVS repository and unstrengthened client.
A: See 10.5 CVS .
Q: Are rdist mechanisms supported ? In what modes (push/pull, strong/weak) ?
A: This was not raised earlier. Need to develop answer.
Q: How should ftp be handled for code/data distribution ? Are anonymous servers preferred over other methods. Will a centralized anonymous server be supported ?
A: needs discussion

Installation Issues

Q: What Fermi enhancements do we lose if we just go and get kerberos from MIT, or an existing FreeBSD port, or an existing Redhat rpm?
A: 1. Cryptocard logins through telnet and ftp.
2. The tools to do authentication of users' cron jobs. (You could do the same job without them, but it would amount to either reinventing the wheel or doing something dreadfully insecure.)
3. Flexible fallback to a non-Kerberized client if you default to encryption "on" but connect to a non-Kerberos server.
4. An ftp client that plays nicely with Emacs' efs mode.
5. Depending which MIT version your software base comes from, it may have buffer overflows or other bugs which are fixed here. (All but one of those bugs are fixed in MIT 1.2.2.)
There are probably a few other minor things. People are working on solutions.
Q: Does the default kerberos install use tcpwrappers when it adds the kerberos telnet and rsh services to inetd.conf?
A: It PRESERVES existing tcpwrappers on a service-by-service basis. If they're not already there, it will not create them.
Q: I don't understand this one; must be NON-Fermi KerberosLinux Can/do the Kerberos distributions of Fermi and RedHat coexist? What can/needs to be done to make them coexist? (Likewise for Solaris) Two questions here: Can I use Kerberos V5 from any source? and If I install Fermi UPS Kerberos on top of a OS with Kerberos native (what is this?) e.g., Soaris 6+, RH 7x, etc., will the Fermi Kerberos continue to work?
A: Technical: Yes, they can coexist at the price of some of the Fermi enhancements (CryptoCard, etc.) Reference: http://www.fnal.gov/cd/security/StrongAuth/OSS/img2.htm FNAL Policy: Any KRB5 client implimentation is fine. OSS Policy: We will only support the Fermi distributions. Distribution of "native" versions evaluated at Certification ?
Q: How do you upgrade an existing Kerberos installation? Is there any automated way to do this, e.g. autorpm (except Kerberos is distributed as a ups product ? (Maybe UPP is the way to do this ?)
A: UPS upgrade methods will work. AutoRPM is on the wish list.

Technical/Admin Issues

Q: What changes are required/recommended to account creation procedures? E.g. disabling local logins, creating .k5login files, etc.
A: Technical: account creation procedures should be modified to put unuseable hash (eg. "x") for the password hash as the default. Exceptions then require intervention.
OSS Policy: all account names must be registered with the central clearing house (compdiv@fnal.gov). This point has an algorithm for reconciling usernames and Kerberos principals.
Q: NIS Clusters: What are the issues in converting a cluster of systems to fully-strengthened?
A: This is a task to be done.
Q: Will PAM modules be developed at least for Solaris and Linux to enable the XDM tools, screensavers, etc.?
A: Done for Linux.
Q: How does one set up proxy access through a NAT? (For both UNIX and Windows (WRQ) home desktops) What ports does Kerberos use that must be tunneled through a firewall?
A: OSS Policy: Use your CryptoCard. MC adds: MIT is "buying back" some NAT-accommodating patches for Windows from ANL, and for Unix from Stanford. They don't make Kerberos completely invulnerable to NAT-induced failure, but they help. Whether WRQ picks up the Windows featues I cannot predict.
Q: What are all the issues when using DHCP?
A: Technical: Major problems are when host provides services since hostid is not fixed. No known problems with clients, just get new credentials when your IP address changes. Our advice: make sure your time sync is good, and don't offer services from a DHCP address.
Q: There are accounts used for file ownership/permissions, etc., that no one logs into. How do I make sure that these account names don't accidentally overlap the kerberos principals namespace and suddenly allow people to log into our machines?
A: Create an empty $HOME/.k5login file for each of these accounts.
Q: I want to add empty .k5login files for all my users that don't yet have assigned principals, in case their username was given out as a principal to someone else. Is there an easy way?
A: A little Perl script has been written to make a list of commands to create the .k5login files for all accounts in /etc/passwd. link to it in doc
Q: How does kerberos handle a machine which has multiple names that all resolve to one IP address?
A: If you're speaking of nicknames, like those defined with DNS "CNAME" records, they get resolved to the canonical name before forming the service principal name. For example, if
nick.fnal.gov. CNAME real.fnal.gov.
real.fnal.gov. A 131.225.1.1
then a telnet, rlogin, etc. to "nick" gets user a ticket for the service "host/real.fnal.gov".
Or do you mean that you have a case like
thing1.fnal.gov A 131.225.2.2
thing2.fnal.gov A 131.225.2.2 ?
If for some reason you have to do it, then multiple "host" principals will do the job.

Backup Issues

Q: Because kerberos installation will be a requirement, will there be a requirement for /etc/ and /usr to be backed up?
A: No. The stuff in /usr you get back by re-installing Kerberos. There are three important files in /etc: inetd.conf, that should also get fixed up by a Kerberos re-installation; krb5.conf which is all boilerplate from the krb5conf product unless you made local customizations; and krb5.keytab which should NOT be backed up unless the backup media are kept securely. An adversary in possession of krb5.keytab can impersonate any user -- but only for purposes of logging in to that one machine.
Q: Can we do backups in a unencrypted mode?
A: Assuming your backups do indeed use rsh, there's no need for the data to be encrypted. You can specify encrypt=false in krb5.conf, or if it's "true" there, override that with the "-X" flag. Unlike ssh, the authentication is still safe even if the data is in the clear.
Q: Does the fmb product use kerberized version of rsh?
A: See the web page http://www.fnal.gov/docs/products/fmb/kerberos_and_fmb.html.
Q: What is the policy for backups of keytab files ?
A: FNAL Policy: not yet formed, looking for input .
OSS Policy: Don't include keytab files in standard backup sets. They may be backed up seperately to other local disk areas and stored unencrypted if protected equivalently to the originals. Storage on removeable media is allowed if encrypted.
Q: Special issues for PalmPilot users, i.e. secure backups (what is recommended for storing the backup files), how to restore a PalmPilot PT-1. Are there problems doing this?
A: Technical: See http://www.fnal.gov/cd/security/StrongAuth/OSS/img8.htm FNAL Policy: There is no policy on backup integrity requirements. Exploits of system via this channel will be dealt with as observed.
Announcements - Services - Systems & Networking - Documentation & Software
Getting Started - About the Computing Division - Computing Division
Index - Search
This page last modified by Anne Heavey on December 5, 2001; answers to FAQs provided by OSS department, Matt Crawford, kerberos-pilot users (sometimes edited).
http://www.fnal.gov/docs/strongauth/misc/faq.html
For assistance contact helpdesk@fnal.gov
Mail comments about this page to cdlibrary@fnal.gov