Computing at SLAC
Search SLAC
SLAC Home | Computing Home | Unix at SLAC

Single-Sign-On at SLAC

SLAC has recently started supporting ssh2 with kerberos5 ticket forwarding to allow access to AFS on SLAC unix. The tools described in this section work well together to provide convenient access to SLAC Unix from Windows machines. Using these tools, it is possible to sign on once using MIT kerberos with your unix username/password and use that token for access to AFS, ssh, cvs and scp.

EXPORT LAW WARNINGS:
 
  • Export of MIT Kerberos software from the United States of America may be subject to the Export Administration Regulations of the United States Department of Commerce, currently (October 2003) codified as Title 15 CFR Parts 730-774.
  • You are responsible for complying with all applicable export regulations, including obtaining an export license if required.
  • You may not download this software if you are located in, or are a citizen or national of, any country for which the US government prohibits the export of encryption source code, currently (October 2003) Cuba, Iran, Iraq, Libya, North Korea, Sudan, or Syria. (15 CFR Sections 734(b)(3), 740.13(e)(4))

 

 

Kerberos Setup at SLAC

Download M.I.T.'s MIT NetIdMgr (1.3.0.0)

 

 

Unix Side

SLAC.STANFORD.EDU = {
    kdc = k5auth1.slac.stanford.edu:88 k5auth2.slac.stanford.edu:88 k5auth3.slac.stanford.edu:88
    admin_server = k5admin.slac.stanford.edu
    kpasswd_server = k5passwd.slac.stanford.edu
    default_domain = slac.stanford.edu
}

Windows Side

WIN.SLAC.STANFORD.EDU = {
    kdc = winmaster2.win.slac.stanford.edu
    default_domain = win.slac.stanford.edu
    krb4_get_tickets = false
}



Windows Configurations

To make any of the following work, you need to install the MIT Kerberos for Windows software. In its Network Identity Manager, you need toselect the MIT credentials as the default ones. This will allow the listed programs to access the non-Windows credentials and forward them to the Unix side.
The Windows Kerberos credentials are stored in the SSPI credential cache. The MIT Kerberos credentials are stored in a different cache.
All Windows native tools will access the SSPI cache and therefore the MIT software will not interfere with the Windows native software. Firefox is the only application I know of so far that can be configured to access either credential cache but only one at a time (see below).

Configuring Kerberized Services/Servers

IIS needs to be configured to do SPNEGO for Kerberos credentials and not NTLM.
This Microsoft document seems to describe the configuration of IIS: http://support.microsoft.com/kb/215383

Configuring Clients

Kerberos Software

To obtain Kerberos credentials for any other than the native Windows AD realm, you need special tools. Tools from the "Windows 2003 Resource Kit" might be used for this but I found them really awkward and archaic. Instead, I have installed MIT's Kerberos for Windows from http://web.mit.edu/Kerberos/dist/index.html#kfw-3.2 Its Network Identity Manager does an excellent job integrating with other tools like PuTTY or SecureCRT.

 

WARNING: Jeff Altman says: "MIT KFW 3.2.1 should not be used. My recommended version is 3.2.0."
This older version can be downloaded from http://web.mit.edu/Kerberos/dist/kfw/3.2/kfw-3.2/

Here is a screenshot with my native Windows credentials and additional Kerberos credentials obtained via MIT's KfW shown in Network Identity Manager. Note that the Unix Kerberos credentials are the default credentials.
Network Identity Manager

SSH clients

PuTTY

PuTTY needs to have a patch for GSSAPI credential forwarding. There are several versions out there. The one from http://sweb.cz/v_t_m/#putty might not work all the time. It refuses to use the MIT Kerberos credentials once in a while when they were used by it before. Onle re-obtaining these credentials makes this problem go away for a while.

Jeff Altman's PuTTY from http://web.mit.edu/jaltman/Public/putty-with-gssapi/ worked with Fedora Core 6 target systems but not with the standard SLAC system.

No matter which PuTTY you are using, its configuration needs to be changed to

  • "Attempt Kerberos 5 GSSAPI/SSPI auth (SSH-2)" in the "Authentication methods" and
  • "Attempt Kerberos 5 ticket forwarding in GSSAPI/SSF" in the "Authentication parameters"

(see screenshot below)

PuTTY with enabled GSSAPI