Ticket based SSO-authentication at the MPI CBS

Summary: This page describes, how the institutes's software recognizes users.

Overview

When you log into some system (Google Mail, your computer at home,...), the system usually takes your username and password after which you are inside a session which is usable "forever".

In a networked environment, your data usually resides on a remote computer and your workstation needs to prove to the file server that you are actually you. State-of-the-art-method for that is using a secret data structure - a "ticket" - which is created when you log in. It has these features:

• The ticket is only valid for a certain time ( 72 hours [3 days] in the MPI CBS).
• A central authentication server is needed to create the ticket. It's not just a mathematical function of your password.
• Your password cannot be reconstructed from the ticket.
• If a bad person acquires the ticket, they will be able to impersonate you - until the ticket times out.
  • It's not possible to change your password with just the ticket. You have to know the old password for that.
  • In comparison: A bad person acquiring your password, they are able to impersonate you until you change your password (which is usually a lot longer).
• A new ticket is acquired, whenever you unlock your screensaver.
• A ticket can be extended for a certain amount of time.
  • The maximum time of validity will never exceed 7 days after the ticket's original creation time. This is a hard guarantee.
  • There must be a process in the context of the ticket doing the extension - it's not done automatically.
  • The institute's Batch processing system automatically uses this features to enable jobs running for up to seven days.

The whole concept of "tickets" is actually a bit more complicated than the explanations on this page. However, the details being left out are not required to understand the concept and are only relevant to IT personnel and developers.

FAQ

Why 72 hours?

When logging intoa Linux workstation, a ticket is being created and stored safely in your session. It's initialized with a validity of 72 hours. Upon unlocking your screensaver, the ticket is refreshed. The idea is to cover a whole weekend. When you leave for home on Friday, you leave a valid ticket behind. When you come back in the morning, the ticket is refreshed. You sessions has a valid ticket all the time which means, running jobs will always have access to your folders.

Where is ticket authentication used in the institute?

When you open a new Linux session or connect via RemoteLinux to it, a ticket is created. It is then used to

• connect to other machines without a password being needed (Example: ssh somehost or getserver -sL )
  • In this case, a copy of the ticket is sent to the remote machine and stored in the remote session.
  • It's even better than that: Whenever you receive a new ticket on your local workstation, it's automatically sent to remote SSH sessions. (This is called gssapi-keyex ).
• Access secure storage (i.e. /data or /afs )
• Connect to the Jabber-Server
• Request data from the user directory (i.e. via the phone command)

Why is access to files suddenly lost? (and SSH to other computers no longer possible)

Getting an unexpected Permission Denied error when accessing data in /data or /afs is usually caused by a ticket that exceeded its lifetime. Quick solution:

user@host > tokenmgr -l

You'll be asked for your password which will then be converted into a brand new ticket.

How to avoid a ticket getting invalid?

There is a wrapper that can be used to guarantee that a given command always has a valid ticket:

user@host > tokenmgr -rKP mycommand.sh

If you need command line arguments for your script, use -- to separate tokenmgr options from the command:

user@host > tokenmgr -rKP -- mycommand.sh --some-option ...

or in case you want a whole shell including all subprocesses to be re-authenticated:

user@host > tokenmgr -rKP bash

This acquired AFS/Kerberos-Identity is only valid for subprocesses (i.e. in a single terminal window). The wrapper will work perfectly fine in remote SSH sessions.

Be aware that all credentials on the server side are deleted when a SSH connection terminates. Applications running remotely will not just get a terminating HUP-signal but SSH actively removes all credentials as well. To be clear: Just using screen is not of help. Find the solution here.

How to avoid jobs being interrupted when the terminal window closes?

When a terminal window closes, the default behavior is to kill all processes running in it. This includes shutting down SSH sessions to remote computers and killing processes running there. There is a way to protect running processes using a terminal multiplexer but it's necessary to protect your Kerberos ticket as well - otherwise your processes might still run but loose access to their data. The solution is tokenmgr -R. Example:

user@host > getserver -s

user@someserver > tokenmgr -R

I: tokenmgr is going to create a re-authenticated screen-session now.

I: You have to enter your password twice now.Short list of 'screen'-commands:

[...]

tokenmgr: Kerberos password for user@CBS.MPG.DE: [Password]

tokenmgr: Kerberos password for burk2@CBS.MPG.DE: [Password]

Ctrl+A c

user@someserver> my_computation.sh

You will be asked for your password twice. Make sure to have a look the command list that is shown when you have to enter the password for the first time. You'll have to use Ctrl+A c to open a new virtual terminal after you entered your password the second time.

The running example process my_computation.sh is protected against

• your ticket becoming invalid (as long as your institute account is valid and your password stays the same)
• the terminal window being closed
• you local computer crashing

To re-connect to your running script, you'll have to connect to server explicitly and re-attach the virtual terminal session:

user@host > ssh someserver

user@someserver > screen -r

How to enable ticket authentication in Firefox?

Firefox needs some configuration options set before attempting to use Kerberos authentication on web sites. These options can be set in the about:config view:

• network.negotiate-auth.allow-proxies : (boolean) true
• network.negotiate-auth.trusted-uris : (string) cbs.mpg.de
• network.negotiate-auth.delegation-uris : (string) cbs.mpg.de