Kerberos for sysadmins

Last updated -[Sun Oct 9 10:47:40 2005 by cxh]-

Places to go

  • My Toplevel Kerberos Page
  • Secure Shell (ssh)
  • Steve Rothwell's Nov. 96 Kerberos meeting notes.
  • MIT - Kerberos DLLs
  • Contents

  • Using Kerberos to Su
  • Changing Root Ticket Passwords
  • Schemes for managing kerberos only machines
  • Mac Kerberos Bugs
  • Kerberos and Home IP
  • Kerberos and ftp
  • Kerberos and rdist
  • Sww Kerberos Debugging
  • Installing and Backing Kerberos out
  • CNS Kerberos
  • Pop
  • Cybersafe
  • Kerberos 5

  • This page is for system administrators on kerberized machines. You might want to consult the Kerberos User's Guide

    Using Kerberos to Su

    To login as root, one must

  • Be in the wheel group. To be added to the wheel, edit /etc/group as root on mho and do (cd /var/yp; make)
  • Have a root kerberos instance. To get a root kerberos instance, you can ask kerberos-questions@eecs
  • /.klogin should have an entry for each person who is to su to root. /.klogin should look like:

    cxh.root@eecs.berkeley.edu and be readable only by root.

    There are several ways to become root.

  • Get a root ticket with kinit youruid.root. Then use a kerberized rlogin, such as the one at /usr/kerb.local/bin/rlogin: rlogin -l root hostname cxh@markov 3% kinit cxh.root Kerberos Initialization for "cxh.root" WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos Password: cxh@markov 4% rlogin -l root markov
  • You can use the ksu command to su.

    If you use ksu, then you will be prompted to type in your kerberos password. If you are logged in over the net, then this defeats the purpose of kerberos, so the trick is to get a username.root ticket on your local machine, by ksu-ing, and then do do rsh -x remotemachine.

    Alternatively, you can do kinit username.root, and then do rsh -x -l root remotemachine

    If you keep one window open where you've ksu'd, then you need not keep doing kinit and kinit username.root over and over again, since each kinit will wipe out your previous ticket. If you have a separate window with a ksu, then you own one ticket, and root owns the other.

    (Many thanks to Rob McNicholas for clarifying this)

  • If you wish to be insecure and send the root password over the net, you can use su -. Note that the - is necessary under Solaris so that you get the root environment. If you just do su, then the NAME environment variable will be incorrectly set.
  • Changing Root Ticket Passwords

    1. Get a root ticket with kinit yourname.root
    2. Run kpasswd yourname/root
    For example
    cxh@maury 7% kinit cxh.root
    Kerberos Initialization for "cxh.root"
    WARNING: Your password may be exposed if you enter it here and are logged 
             in remotely using an unsecure (non-encrypted) channel.
    Kerberos Password: 
    cxh@maury 8% kpasswd cxh/root
    kpasswd: Changing password for cxh/root.
    Old password:
    New password:
    New password (again):
    Kerberos password changed.
    cxh@maury 9% kdestroy
    Tickets destroyed.
    cxh@maury 10% kinit cxh.root
    Kerberos Initialization for "cxh.root"
    WARNING: Your password may be exposed if you enter it here and are logged 
             in remotely using an unsecure (non-encrypted) channel.
    Kerberos Password: 
    cxh@maury 11% klist
    Ticket file:    /tmp/tkt6269
    Principal:      cxh.root@EECS.BERKELEY.EDU
    
      Issued           Expires          Principal
    Feb 28 10:43:41  Feb 28 19:43:41  krbtgt.EECS.BERKELEY.EDU@EECS.BERKELEY.EDU
    cxh@maury 12% 
    
    
  • Schemes for managing kerberos only machines

    If you have your machines setup so that you must use kerberos to rlogin or rsh, then root will not be able to rsh to other machines. This is a problem if you want to backup your clients, or you want to run nightly cron jobs. Below are some suggestions
  • Use the time-to-live option in kinit to create a root ticket with a very long time to live: watson.eecs 11# /usr/kerberos/bin/kinit -l -v cxh.root Kerberos Initialization for "cxh.root" Kerberos ticket lifetime (minutes): 100000 WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos Password: Kerberos realm EECS.BERKELEY.EDU: No Error watson.eecs 12# The kinit man page says: -l kinit prompts you for a ticket lifetime in minutes. Due to protocol restrictions in Kerberos Version 4, this value must be between 5 and 1275 minutes. So it could be that a 10000 minute lifetime will not work
  • Use ksrvtgt to get a ticket granting ticket /usr/kerberos/bin/ksrvtgt rcmd `hostname|awk -F. '{print $1}' `; /usr/kerberos/bin/rsh /usr/kerberos/bin/klist -t will return 0 if a ticket-granting-ticket is available, otherwise it will return 1.

    Note that at first glance, it would seem like it would be a good idea to put /usr/kerberos/bin in root's path, however, since this is a NFS mounted directory, if your machine is not on the net, or sww is down, then you might not be able to do much as root. So, it is best if you don't put /usr/kerberos/bin in root's .cshrc The Sygnus ksrvtgt documentation has a good explanation of what to do. (local copy) Basically, you add rcmd.watson@eecs.berkeley.edu to the /.klogin file.

  • Using kled

    Craig Lant wrote:

    I've installed on SWW a simple tool for managing /.klogin files on groups of workstations.

    /usr/sww/share/etc/kled [ HostName | -f File ] { -a Instance | -d Instance }...

    If no HostName or File is given, the local /.klogin is modified. Otherwise, the /.klogin on HostName is modified or the /.klogins on each machine listed in File are modified. -a Instance means add the given instance and -d Instance means delete it. Of course, you need to be root when you run it and you need to have a ticket that will get you onto any remote machines named. Also, all machines have to have SWW mounted.


    Mac/kerberos bugs

    See the Kerberos User's page for Mac installation instructions.

    Problems with pine and NCSA telnet

    One problem is that one cannot cancel messages:
    1. Login from a mac via NCSA telnet
    2. start pine
    3. Hit C to compose a message
    4. Hit Control-C to cancel
    You won't be able to cancel!

    The fix is to change the session parameters: Inside NCSA telnet, go to the Edit menu, then select Preferences and then Sessions, and change the default session so that

  • The translation table is set to US ASCII
  • Turn off Allow Linemode
  • Turn on BSD4.3 Mode
  • Problems with Mac Comet

    Tom Parks points out that instead of using the "map return to newline" option (which does not seem to work) define a macro so that return sends newline

    Solaris kerberized rlogin takes both passwds

    Tom Parks also discovered that under Solaris2, using the kerberized rlogin will allow one to log in with both the regular passwd and the kerberized passwd. This does not happen under Ultrix.

    Control-S does not work in a kerberized rlogin

    Use rlogin -8 to start your session.

    Kerberos and Home IP

    Apparently, if you have kerberos binaries installed on your home machine, and everything is configured to talk to the campus kerberos servers, you can run kinit at home and then connect to campus.x1

    Also, kerberized Macintosh NCSA telnet should work from home.


    Kerberos and ftp

  • SWW does not have a kerberized ftp or ftpd installed.
  • Cygnus CNS does have a a kerberized ftp or ftpd available. To use CNS ftpd, I set up /etc/inetd.conf so had the line: ftp stream tcp nowait root /usr/local/etc/ftpd.cns ftpd.cns -r /etc/krb.realms -s /etc/krb.srvtab -l
  • I found a kerberized ftp and wu-ftpd via the CMU kerberos page at ftp://bitsy.mit.edu/user/tytso/ftp-wg/. I had a hard time compiling these programs under Solaris.
  • To get a kerberized ftp to work, I needed to set my .klogin so that it looked like: cxh cxh@EECS cxh.root@EECS

    ange-ftp and kerberos

    ange-ftp is a emacs package that allows the user to use ftp and grab files. I've set up the Cygnus kerberized ftp and ftpd.
  • ange-ftp checks the return values of ftp, and "S:" was getting inserted which was causing no end of trouble. The fix was to edit ftp.c and change if (verbose) printf("%c:", safe ? 'S' : 'P'); to if (debug) printf("%c:", safe ? 'S' : 'P'); The problem is that verbose gets incremented in main() if we are connected to a tty. Apparently ange-ftp is using a tty or pseudo-tty, so verbose gets set.
  • I installed the Cygnus kerberized ftp in /usr/local/bin/ftp.cns and then added the following to my .emacs file. (setq ange-ftp-ftp-program-name "/usr/local/bin/ftp.cns") (setq ange-ftp-ftp-program-args '("-i" "-g")) (setq ange-ftp-good-msgs "^231 \\|^220 \\|^230 \\|^226 \\|^25. \\|^221 \\|^200 \\|^[Hh]ash mark") (setq ange-ftp-skip-msgs (concat "^ADAT\\|^KERBEROS_V4 \\|^Kerberos \\|^S:231 \\|^350 \\|" "^200 \\(PORT\\|Port\\) \\|^331 \\|^150 \\|^350 \\|^[0-9]+ bytes \\|" "^Connected \\|^$\\|^Remote system\\|^Using\\|^ \\|Password:\\|" "^Data connection \\|" "^local:\\|^Trying\\|^125 \\|^550-\\|^221 .*oodbye")) Bugs and gotchas
  • Your ~/.netrc file must mention the machine you want to ftp into. For example, if I want to log into the machine named forney, then my .netrc would contain machine forney login cxh (Note that my password is not present)
  • If you are having problems ftp-ing into a machine, try doing rkinit hostname to send over a ticket

  • Kerberos and rdist

    Locally, we use the nrdist program off the net, rather than the vanilla rdist. nrdist uses rsh rather than rcmd. Also, nrdist does not need to be suid root.

    To run nrdist as root, you will need to use ksrvtgt:

    /usr/kerberos/bin/ksrvtgt rcmd `hostname|/usr/bin/awk -F. '{print $1}' `
    

    If you only allow kerberized rshs and logins, then nrdist will fail:

    denon: updating host denon
    denon: LOCAL ERROR: Unexpected input from server: "denon.eecs.berkeley.edu: Connection refused".
    denon: updating of denon finished
    

    If you run nrdist with the -D flag, which turns on debugging, you will see that nrdist is using /usr/ucb/rsh instead of /usr/kerberos/bin/rsh. The fix is to do

    /usr/kerberos/bin/ksrvtgt rcmd `hostname|/usr/bin/awk -F. '{print $1}' `
    nrdist -P /usr/kerberos/bin/rsh
    

    There are two forms of Kerberos around, one from SWW, and one from Cygnus.


    SWW Kerberos debugging

    SWW Kerberos sources

    The kerberos sources are on sww in /usr/sww/share/src/kerberosIV. /usr/sww/share/src is mounted on po and cory.

    /users/cxh/src/Makefile includes some rules to get kerberos sources and build the binaries, including:

    pmake -I/users/cxh/src/kerberosIV/pmake MACHINE=sun4 OSTYPE=Solaris "COPTS=-DSOL2_5_1 -DHAS_LOCKF"
  • Makefile - substitute $(MAKE) for make
  • While compiling compat/getenv.c: In file included from /export/watson/watson3/cxh/src/kerberosIV/compat/getenv.c:49: /export/watson/watson3/cxh/src/kerberosIV/compat/../include/sys_proto.h:240: conflicting types for `gettimeofday' /usr/include/sys/time.h:263: previous declaration of `gettimeofday' /export/watson/watson3/cxh/src/kerberosIV/compat/../include/sys_proto.h:399: conflicting types for `setitimer' /usr/include/sys/time.h:243: previous declaration of `setitimer' /export/watson/watson3/cxh/src/kerberosIV/compat/getenv.c: In function `__findenv': /export/watson/watson3/cxh/src/kerberosIV/compat/getenv.c:88: warning: passing arg 3 of `strncmp' as unsigned due to prototype The fix is to put #ifndef SOL2_5_1 .. #end around the duplicate definitions.
  • HAS_LOCKF is used in kerberosIV/krb/tf_util.c to use lockf instead of flock. The code to add in tf_util.c is: #ifdef HAS_LOCKF if ( (retval = lockf(fd, F_TLOCK, 0)) < 0) { if (retval != EDEADLK) { perror("lockf failed:") ; } sleep(TF_LCK_RETRY); if (lockf(fd, F_TLOCK, 0) < 0) { (void) close(fd); fd = -1; return TKT_FIL_LCK; } } #else and in tf_close(): #ifdef HAS_LOCKF lockf(fd, F_ULOCK, 0); #else (void) flock(fd, LOCK_UN); #endif Also, the open() call should open the file for reading and writing. The error message I was seeing was Kerberos V4 krb_mk_req failed: Can't lock ticket file; try later
  • Message: Kerberos V4 krb_rd_safe failed: Message integrity error
  • If kinit fails with:
    WARNING: Your password may be exposed if you enter it here and are logged 
             in remotely using an unsecure (non-encrypted) channel.
    kinit: Can't send request
    
    then make sure that you have name service. One way to check is to use the nslookup command: nslookup ftp.uu.net is a good test.
    You may find it useful to add the kerberos hosts, such as kerberos1.cs to your /etc/hosts file.
  • Various /usr/kerberos/bin commands

    telnet

    To turn on debugging, use /usr/kerberos/bin/telnet -a

    telnetd

    kerberos telnetd can be run with certain debugging options, here is a list Usage: telnetd [-a (debug|other|user|valid|off|none)] [-debug] [-D (options|report|exercise|netdata|ptydata)] [-edebug] [-h] [-l] [-n] [-X auth-type] [-u utmp_hostname_length] [-U] [port] If, as root, you start up telnetd with: ~cxh/src/kerberosIV/libexec/telnetd/obj/telnetd -Dreport -debug 5206 Then you can use telnet markov 5206 to connect to that telnetd.

    Sww Kerberos bugs

    I believe that these bugs were fixed on sww in January 1996, but I'm leaving them as notes for the time being.

    Motd seen twice

    If you use /usr/kerberos/bin/telnet to log into markov, then /etc/motd is printed, and /bin/csh prints Warning: no access to tty; thus no job control in this shell... and then /etc/motd is printed again. Running klogin triggers the same behaviour cxh@markov 58% /usr/kerberos/bin/klogin /usr/kerberos/bin/klogin login: cxh Password: Last login: Mon Jun 19 15:24:11 on pts/17 Welcome to the mho cluster running Solaris 2.4 See /usr/cluster/doc for cluster documentation. Please report system problems to cxh at eecs. Warning: no access to tty; thus no job control in this shell... Welcome to the mho cluster running Solaris 2.4 See /usr/cluster/doc for cluster documentation. Please report system problems to cxh at eecs. Erase set to Ctrl-H cxh@markov 7%

    In sww kerberos, the motd problem can be fixed by editing kerberosIV/usr.bin/login/login.c and

    rcsdiff -c login.c =================================================================== RCS file: RCS/login.c,v retrieving revision 1.10 diff -c -r1.10 login.c *** /tmp/T0a001ig Sun Jun 25 17:29:15 1995 --- login.c Sun Jun 25 17:26:50 1995 *************** *** 487,493 **** "The Regents of the University of California. ", "All rights reserved."); #endif /* SWW_KERBEROS */ ! #ifndef __hpux motd(); #endif /* __hpux */ (void)snprintf(tbuf, --- 487,493 ---- "The Regents of the University of California. ", "All rights reserved."); #endif /* SWW_KERBEROS */ ! #if !defined( __hpux) && !(defined(__sun) && (defined(__SVR4) || defined(__svr4__))) motd(); #endif /* __hpux */ (void)snprintf(tbuf,

    If I set my shell to /usr/local/bin/csh.tst, which contains

    #!/bin/sh truss -o /tmp/tr csh and add /usr/local/bin/csh.tst to /etc/shells I get the following when I log in: fcntl(2, F_DUPFD, 0x00000012) = 18 getpid() = 14302 [14301] fcntl(18, F_SETFD, 0x00000001) = 0 [. . .] ioctl(18, TCGETA, 0xEFFFFC5C) = 0 ioctl(18, TIOCGPGRP, 0x00047A88) Err#25 ENOTTY ioctl(17, TIOCLGET, 0xEFFFFB5C) = 0 write(17, " W a r n i n g : n o ".., 64) = 64

    The termio man page says:

    ENOTTY The file associated with fildes is not a ter- minal.

    It looks like running /usr/ucb/telnet to a host running /usr/kerberos/libexec/telnet exhibits the same behaviour (motd-no job-control-motd) It turns out that for CNS telnetd and krlogin use different code to set up the controlling terminal. For CNS, I edited rlogind.c:

    685c709 < #ifdef __SCO__ --- > #if defined(__SCO__) || defined(solaris20) 690a715,719 > /* solaris20: FIXME: Is this really right? If we don't have this, then rlogin > * spits up messages about > * Warning: no access to tty (Inappropriate ioctl for device). > * cxh > */ 695a725,737 > /* start cxh */ > /* > * We get our controlling tty assigned as a side-effect > * of opening up a tty device. But on BSD based systems, > * this only happens if our process group is zero. The > * setsid() call above may have set our pgrp, so clear > * it out before opening the tty... > */ > > if (krb_setpgrp(0, 0) == -1) { > perror("rlogind: krb_setpgrp(0,0) failed:"); > } > /*end cxh*/

    For sww telnetd kerberos, to fix the job control problem, the trick is to change kerberosIV/libexec/telnetd/sys_term.c

    RCS file: RCS/sys_term.c,v retrieving revision 1.8 diff -c -r1.8 sys_term.c *** /tmp/T0a00159 Fri Jun 23 11:02:24 1995 --- sys_term.c Thu Jun 22 16:54:15 1995 *************** *** 142,147 **** --- 142,155 ---- #include "compat-proto.h" #include "sys_proto.h" + /*#define DEBUG2*/ + #ifdef DEBUG2 + #define DBG(X) X + FILE * fdebug; + #else + #define DBG(X) + #endif + #ifndef SOLARIS static char *ptyline = NULL; static char ptybuf[MAXPATHLEN]; *************** *** 1358,1363 **** --- 1366,1373 ---- # endif /* __hpux || SOLARIS */ # ifndef SOLARIS close(open(ptyline, O_RDWR)); + # else + close(open(line, O_RDWR)); # endif /* !SOLARIS */ # endif if (t != 0)

    Output speed on diva is 0

    If I use /usr/kerberos/bin/telnet diva, then cxh@diva.EECS.Berkeley.EDU> stty new tty, input speed 38400 baud output speed 0 baud ; tabs crtbs crterase crtkill ctlecho decctlq However, /usr/kerberos/bin/telnet -a diva, seems to set the output speed properly:

    /usr/kerberos/bin/rlogin -K solmachine fails

    cxh@markov 7% /usr/kerberos/bin/rlogin -K markov No utmpx entry. You must exec "login" from the lowest level "shell". rlogin: connection closed. cxh@markov 8% cxh@markov 145% strings /usr/bin/login | grep 'No utmpx' No utmpx entry. You must exec "login" from the lowest level "shell". However rlogin -k markovworks from diva

    To fix sww kerberos, kerberosIV/usr.bin/rlogin/rlogin.c needs to get the output speed, not the input speed. The patch below should do the trick.

    RCS file: RCS/rlogin.c,v retrieving revision 1.9 diff -c -r1.9 rlogin.c *** /tmp/T0a0017L Fri Jun 23 11:18:48 1995 --- rlogin.c Fri Jun 23 11:18:11 1995 *************** *** 468,474 **** --- 468,478 ---- #ifdef __hpux return (speeds[tt.c_cflag & CBAUD]); #else /* !__hpux */ + #if defined(__sun) && (defined(__SVR4) || defined(__svr4__)) + return (speeds[(int)cfgetospeed(&tt)]); + #else return (speeds[(int)cfgetispeed(&tt)]); + #endif #endif /* __hpux */ #endif /* MIPSEL */ }

    Craig Lant has another fix for the stty problem:

    It seems that the problem here is with the solaris version of in.rlogind. I, ofcourse, don't have the source to fix that, but a simple solution is to replace it with the kerberos rlogind in the inetd.conf file.

    Can't telnet into local accounts, such as PPP accounts

    If an account is not in the NIS map, then you might not be able to telnet into it, but you will be able to rlogin in.

    The problem is that our kerberized telnetd does not seem to ever look at /etc/shadow so if a user is not in the NIS passwd map, then they will not be able to log in. The workaround is to place the accounts into the yp maps. The real fix would be to modify how telnetd verifies passwords.

    SWW kerberos and Solaris2.5

  • The /usr/sww/etc/kerberize script does not handle the fact that Solaris2.5 has inetd.conf and services in /etc/inet rather than in /etc. /etc/services and /etc/inetd.conf are links to the real files in /etc/inet. The kerberize script breaks the links and leaves files in /etc rather than updating the files in /etc/inet. The fix is to copy the new files in by hand and remake the links.
  • Make sure that you have a /etc/resolv.conf file, or kerberos commands will take a long time. For the mho cluster, we use: domain eecs.berkeley.edu search EECS.Berkeley.EDU CS.Berkeley.EDU Berkeley.EDU nameserver 128.32.240.171
  • Installing and deinstalling kerberos

    Backing kerberos out

    As root on dewitt cd /users/cxh/sa/bin/doall ./doall "rm /etc/inetd.conf; cd /etc; ln -s /usr/cluster/etc/inetd.conf.pre-krb inetd.conf; /users/cxh/bin/restart-sm inetd; ls -l /etc/inetd.conf" `cat sol2`

    Setting up kerberos

    As root on dewitt cd /users/cxh/sa/bin/doall ./doall "rm /etc/inetd.conf; cd /etc; ln -s inet/inetd.conf .; /users/cxh/bin/restart-sm inetd; ls -l /etc/inetd.conf" `cat sol2.tmp`

    Cygnus CNS Kerberos

    Differences between Cygnus and Sww kerberos

  • CNS has /usr/kerberos/lib/krb.conf, where as SWW has /etc/krb.conf. Ditto for /usr/kerberos/lib/krb.realms and /etc/krb.realms. You can copy these files.
  • CNS kinit prompts for the user name first, SWW's kinit does not
  • CNS uses /etc/krb-srvtab, whereas SWW uses /etc/krb.srvtab. A link will fix this.
  • CNS daemons such as telnetd are in /usr/kerberos/lib. For SWW, telnetd is at /usr/kerberos/libexec. You will need to change /etc/inetd.conf, see the CNS installationdocs

  • Problems with CNS

    telnet echos motd twice

    However, there are no bogus messages about access to tty, so this is better than the Kerberos on SWW. This is because CNStelnetd runs /bin/login, not the kerberos login.

    rlogind exits

    cxh@diva.EECS.Berkeley.EDU> /usr/kerberos/bin/rlogin maury Last login: Tue Jun 20 17:37:16 from markov.eecs.berk rlogin: connection closed. cxh@diva.EECS.Berkeley.EDU> login.krb was calling initgroups() which was failing. Using myinitgroups() works around this.

    However, now I'm getting the access to tty problems. I believe that tcgetpgrp() is failing.

    Looking at the tcsh source code, I can see where tcgetpgrp() is going failing.


    Debugging CNS

    inetd

    Under solaris, you can use /usr/sbin/inetd -s -d -t to turn on debugging and packet tracing.

    You can also change /etc/inetd.conf to pass various arguments to the daemons. For instance, you can have klogind run your own login script with

    klogin stream tcp nowait root /usr/kerberos/etc/klogind klogind -l /tmp/mylogin

    POP

    Eudora has the ability to use kerberos with POP. However, I was never able to get Kerberos POP to work. Eudora understands APOP, which is fairly easy to setup.
  • Local POP page.
  • windows kerberos client dlls
  • Qpopper
  • Qpop FAQ
  • I think I need some sort of change to my srvtab file to get it to work. My terminology might be wrong here, but /etc/krb.srvtab has a 'rcmd' key(?), I think I need a 'pop' key.

    Cybersafe

    Cybersafe has a Window/NT kerberos client

    Cybersafe's phone number is 206-391-6000 (Jim Hanem: 415 391 7137).

    Cybersafe problems

  • When I try to login, I get a message "Cannot contact any KDC for requested realm while getting initial credentials"
    The installation guide says:
    CyberSAFE Challenger is unable to establish a connection with the KDC. It has found the specified KDC, but received no response back.
    1. Check your TCP/IP configuration
    2. Contact your Kerberos administrator. The KDC System may not be up.
    I checked the logs on kerberos1.cd, and it looks like my machine, nobel was never connecting.

    Running snoop nobel and then trying to get a ticket results in:

    nobel.eecs.berkeley.edu -> kerberos1.cs.berkeley.edu UDP D=88 S=2872 LEN=241
    kerberos1.cs.berkeley.edu -> nobel.eecs.berkeley.edu ICMP Destination unreachable (Bad port)
    nobel.eecs.berkeley.edu -> kerberos1.cs.berkeley.edu UDP D=88 S=2872 LEN=241
    kerberos1.cs.berkeley.edu -> nobel.eecs.berkeley.edu ICMP Destination unreachable (Bad port)
    
    Using snoop -v kerberos1 shows that nobel is trying to talk to port 88, but kerberos1 is saying that is a bad port. /etc/services on kerberos1 shows that it is listening for kerberos requests on port 750. The kerberos faq says
    "kerberos" has officially been moved to port 88, although people will have to listen on port 750 for some time to come, and assume that many servers won't be converted to listen to port 88 for some time.

    The windows release notes say that this version of Cybersafe does not work with KerberosIV, which is what the department is running.

    The krb5diag program can be used to modify the NT services file at c:\winnt\system32\drivers\etc\services. I tried editing this file by hand so that the kerberos5 entry was on port 750, but that resulted in an error.


  • Kerberos V

    http://www-inst.eecs.berkeley.edu/usr/pub/kerberos.help says:
    In July 1997, EECS upgraded the Kerberos servers to version 5.0. The programs for the new version are in /usr/sww/krb5/bin. Kerberos 5 is backwards-compatible with Kerberos 4 (ie, users who are on a computer running Kerberos 5 can connect to other computers that are running Kerberos 4 or Kerberos 5). However, computers running Kerberos 4 cannot connect to a Kerberos 5 computer using Kerberos.

    Why use Kerberos V?

  • Cybersafe, a commercial product for Windows needs Kerberos V.
  • The NT version of kerberos requires Kerberos V.
  • Kerberos V is the wave of the future.
  • Kerberos V Setup

    http://www-inst.eecs.berkeley.edu/usr/pub/kerberos.help has a good summary about the various changes between Kerberos IV and Kerberos V.

    As of 1/8/98, the only Kerberos Daemons that were thought to be 'safe' are telnetd and ftpd. In the short term, I decide to only use telnetd, since that is what the Windows clients used.

    1. /etc/services - Comment out the Kerberos IV services and add in the Kerberos V services.
      #
      # Kerberos V services
      #
      #kerberos-sec    88/udp          # Kerberos V5
      #kerberos-sec    88/tcp          # Kerberos V5
      kerberos	88/udp    kdc      # Kerberos V5
      kerberos	88/tcp    kdc      # Kerberos V5
      klogin		543/tcp         # Kerberos login
      kshell          544/tcp         cmd             # and remote shell
      kerberos-adm    749/tcp         # Kerberos 5 admin/changepw
      kerberos-adm    749/udp         # Kerberos 5 admin/changepw
      #kerberos        750/tcp  kdc    # Kerberos authentication--tcp (same as k4)
      #kerberos        750/udp  kdc    # Kerberos authentication--udp (same as k4)
      hesupd          751/tcp         # hesiod update daemon
      kerberos_master 751/tcp         # Kerberos authentication (same as k4)
      kerberos_master 751/udp         # Kerberos authentication (same as k4)
      passwd_server   752/udp         # Kerberos passwd server (same as k4)
      userreg_server  753/udp         # Kerberos userreg server (same as k4)
      krb_prop        754/tcp         # Kerberos slave propagation (same as k4)
      krbupdate       760/tcp  kreg   # Kerberos registration
      kpasswd         761/tcp  kpwd   # Kerberos "passwd" (same as k4)
      kpop            1109/tcp        # Pop with Kerberos (same as k4)
      kpop3           1110/tcp            # Pop3 with Kerberos
      knetd           2053/tcp        # Kerberos de-multiplexor (same as k4)
      eklogin         2105/tcp        # Kerberos encrypted rlogin (same as k4)
      rkinit          2108/tcp        # Kerberos remote initialization (same as k4)
      krb524          4444/tcp        # Kerberos 5 to 4 ticket translator
      
    2. /etc/inet/inetd.conf - commment out the Kerberos IV telnetd and add in the Kerberos V telnetd:
      #
      # Kerberos IV telnet
      #
      #telnet stream  tcp     nowait  root    /usr/kerberos/libexec/telnetd    telnet\
      d -h -U -a user
      #
      # Kerberos V telnet
      #
      # -h Don't print host specific info before the login was completed
      # -U Only accept connections from addresses that can be mapped w/ gethostbyaddr 
      telnet  stream tcp nowait root /usr/sww/krb5/sbin/telnetd telnetd -h -U -a vali\
      d
      
      
    3. Do kill -1 on the inetd pid.
    4. Create /etc/krb5.keytab files from /etc/krb.srvtab. The ktutil binary will do this, below is a script that uses ktutil:
      #! /bin/sh
      # Convert Kerberos 4 srvtabs to Kerberos 5 keytabs 
      /usr/sww/krb5/sbin/ktutil << 'EOF'
      rst /etc/krb.srvtab
      wkt /etc/krb5.keytab
      EOF
      chmod 0400 /etc/krb5.keytab
      
    5. Create a link from /usr/krb5 to /usr/sww/krb5
    6. There is no need to put /usr/sww/krb5/bin or /usr/krb5/bin into your path.

    Testing telnet

    From Unix, do the following:
    /usr/sww/krb5/bin/kinit
    /usr/sww/krb5/bin/telnet  -a -c host
    

    cxh at eecs