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 [email protected]
● 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