Kerberos 5 at DESY

Andreas Haupt

Wolfgang Friebel

May 20, 2003 1

Motivation● Work started at CERN to use Kerberos5 with AFS● Kerberos4 used internal to AFS

● no easy replacement available● is superseded by Kerberos5● has security weaknesses

● Kerberos5 is a supported standard● lots of tools are K5 enabled (or prepared)

● token extension in LSF, SGEEE, UW-imap server, lprNG, Cisco Routers,…

● AFS can be configured to work with K5● K5 offers desired features missing in K4● K5 comes with an implementation of the GSS-API

(another one is the GSI from Globus)

May 20, 2003 1

Available Software

● Kerberos Servers:● MIT distribution● Heimdal distribution● DCE● A KDC comes with Windows 2000

● Kerberos Clients● Collection of clients contained in all server packs● At least 5 different PAM implementations● Standalone Software that is Kerberos enabled

through the use of GSS-API (useful for Grid) or through native Kerberos calls (MIT and Heimdal differ!)

May 20, 2003 1

Kerberos Servers● Heimdal

● Integrated Kerberos4 and AFS support● Easy conversion of the K4 user database● Incremental propagation of database changes● Comes precompiled with SuSE● Fewer applications available which

successfully build against Heimdal K5 libs than against MIT libraries

● Poor documentation● Some features still unimplemented● KDC does not implement

ka_maintenance_service database administration with kas will not work

● CLI differs from MIT and from W2000 ones

May 20, 2003 1

Kerberos Servers (2)● MIT

● A separate daemon needed for AFS, otherwise AFS-K5 integration provided

● Complicated procedure to convert AFS users to K5

● Comes precompiled with Linux (Redhat)● Some applications ready to use MIT libraries

only● No integrated server replication, it is done

dumping the full database regularly (e.g for CERN > 10MB each time)

● Used by many US sites (Fermilab)

May 20, 2003 1

Kerberos Servers (3)

● W2000● No way to run it on AFS DB servers● No smooth migration of AFS accounts to

W2000, users without W2000 accounts need to get new account and password

● Authentication for AFS with Windows password

● Separate daemon required to obtain AFS tokens (tested and working: gssklog)

● Almost no Windows applications known that use the Kerberos protocol

● TGT contains data internal to W2000, this rules out to use non W2000 KDC's

May 20, 2003 1

Design decisions● Slow migration from K4 to K5

● Start with a limited number of hosts (PAM configured for K5)

● Free choice between K4 and K5 for users● All changes in the user base must be in K4

● Use Heimdal for the following reasons:● Incremental and synchronous K5 DB

propagation● One daemon only for K5, K4, AFS● Sync of K4 and K5 without service interrupt

possible, could be triggered by K4 DB change● Use PAM to get Tickets and AFS token

● Transparent for the users● No change in PAM aware applications

May 20, 2003 1

Implementation

● Built Kerberos 5 realm IFH.DE (heimdal)

● Master KDC is on Solaris 8● Two slave servers (Solaris 8, Solaris 6)

● Software compiled for Linux + Solaris

● Server and clients Heimdal ● Heimdal compliant PAM

May 20, 2003 1

Implementation (2)

● Client and server configuration● using cfengine for that purpose● krb5setuphd (ksh script) available as well

● Synchronization of K4 and K5 DB● heimdal_sync (perl script), only required in

migration phase when still kaserver running● Init scripts to start KDC and slaves

● Needed only during test phase● Maintained by cfengine (deployment to

hosts)● In production phase KDC is controlled by

OpenAFS bosserver

May 20, 2003 1

Implementation (3)

● Ticket lifetimes● Need to be short for security reasons● Need to be renewable for a long time for

batch jobs (now from AFS ka database converted accounts unlimited, new accounts: 30d)

● Users could make use of it to refresh AFS tokens almost forever without typing a password (security concerns?)

● Default ticket lifetime now in sync with AFS (25h)

May 20, 2003 1

Problems solved

● Set up production environment at DESY Zeuthen with 3 servers

● First integrated Realm with Heimdal and AFS in HEP(?)

● OpenAFS kaserver replaced by Heimdal KDC

● Compliance of KDC with old kaserver● Patched KDC not to check addresses in K4

tickets (kaserver does not do this either)● Heimdal provides a global option only for

disabling both K4 and K5 address checking

May 20, 2003 1

Problems solved (2)● Working PAM configuration

● including K4 ticket and AFS token handling● Solaris8, Linux in production, Solaris6 with

minor problems on individual machines● OpenSSH

● version 3.6.1p1 with heimdal-patch● does K5, K4, AFS token forwarding (with

patch also with older version of OpenSSH)● kas no longer available

● replaced kas commands in user and password management using Heimdal-Kadm5 perl module

● IMAP server and Client (pine) with K4/5

May 20, 2003 1

Problems solved (3)

● Login with one time passwords● Host with special PAM configuration● Provides K5, K4 and AFS token ● Users generate S/Key list after K5

authentication● Keys of users stored in keytab (are copied

nightly to login server)● PAM modules used:

● Pam-skey S/Key authentication● Pam-krb5keytab (own development) Ticket

generation from keytab

● Looked at FNAL solution, came up with this one

May 20, 2003 1

Differences to old scheme

● Master/slave concept for KDC● No load balancing of KDC requests● No DB manipulation if master is down● No counter for unsuccessful Kerberos

authentication attempts● Locking of users can be done at the K5

level● When using kinit tickets for foreign

cells/realms get destroyed (AFS tokens in memory survive)

May 20, 2003 1

No cross realm trust● Needed to do mutual authentication

between different sites (e.g CERN-DESY) or on site Unix and Windows realms

● Realms share a common secret stored in keys krbtgt/realmA@realmB and ..B@..A

● User from realm A is trusted in realm B after obtaining ticket from realm A

● User has also in realmB only a ticket user@realmA

● AFS ACL's in realm B will not be honored and the user is not in system:authuser

● Needs to be handled by extra PTS entries

May 20, 2003 1

Next steps● Provide a native K5 arc server and

client● Working version available from SLAC

● Tighter integration with Windows 2003 server● Planned for June in collaboration with

CASPUR

May 20, 2003 1

Conclusions

● K5 deployment is fairly easy● Real switch took less than an hour● Very short service interruption (authentication)● Porting of existing scripts a bigger problem

● K5 integration with services was more tedious

● PAM configuration, ssh, IMAP● Not yet finished: batch (SGEEE), other

potentially Kerberos5 aware services● W2000 interoperability is possible

● harder and less useful than thought

May 20, 2003 1

Conclusions (2)

● Users did not notice a difference in behaviour (except e.g. different output of klist)

● No multi realm support with kinit (AFS users will prefer K4 klog)

● Sessions with long living AFS tokens will become possible (without storing passwords), not yet used

May 20, 2003 1

Useful URL's

Patches and tools:ftp://ftp.ifh.de/pub/unix/kerberosK5 protocol:http://www.isi.edu/people/bcn/krb-

revisionsFAQ:http://www.nrl.navy.mil/CCS/people/kenh/

kerberos-faq.htmlMIT K5:http://web.mit.edu/kerberos/wwwKTH K4:http://www.pdc.kth.se/kth-krbHeimdal K5:http://www.pdc.kth.se/heimdalKerberos Projects:http://www.nectar.cc/krbHeimdal

PAM:http://www.rit.bme.hu/~balsa/pam_krb5GSS-API:http://docs.sun.com (search for GSSAPI)gssklog:ftp://achilles.ctd.anl.gov/pub/DEE