(heimdal.info) Things in search for a better place

 
 Things in search for a better place
 ***********************************
 
 Making things work on Ciscos
 ============================
 
 Modern versions of Cisco IOS has some support for authenticating via
 Kerberos 5. This can be used both by having the router get a ticket when
 you login (boring), and by using Kerberos authenticated telnet to access
 your router (less boring). The following has been tested on IOS
 11.2(12), things might be different with other versions. Old versions
 are known to have bugs.
 
 To make this work, you will first have to configure your router to use
 Kerberos (this is explained in the documentation). A sample
 configuration looks like the following:
 
      aaa new-model
      aaa authentication login default krb5-telnet krb5 enable
      aaa authorization exec krb5-instance
      kerberos local-realm FOO.SE
      kerberos srvtab entry host/router.foo.se 0 891725446 4 1 8 012345678901234567
      kerberos server FOO.SE 10.0.0.1
      kerberos instance map admin 15
 
 This tells you (among other things) that when logging in, the router
 should try to authenticate with kerberised telnet, and if that fails try
 to verify a plain text password via a Kerberos ticket exchange (as
 opposed to a local database, RADIUS or something similar), and if that
 fails try the local enable password. If you're not careful when you
 specify the `login default' authentication mechanism, you might not be
 able to login at all. The `instance map' and `authorization exec' lines
 says that people with `admin' instances should be given `enabled' shells
 when logging in.
 
 The numbers after the principal on the `srvtab' line are principal type,
 time stamp (in seconds since 1970), key version number (4), keytype (1
 == des), key length (always 8 with des), and then the key.
 
 To make the Heimdal KDC produce tickets that the Cisco can decode you
 might have to turn on the `encode_as_rep_as_tgs_rep' flag in the KDC.
 You will also have to specify that the router can't handle anything but
 `des-cbc-crc'. This can be done with the `del_enctype' command of
 `kadmin'.
 
 This all fine and so, but unless you have an IOS version with encryption
 (available only in the U.S) it doesn't really solve any problems. Sure
 you don't have to send your password over the wire, but since the telnet
 connection isn't protected it's still possible for someone to steal your
 session. This won't be fixed until someone adds integrity to the telnet
 protocol.
 
 A working solution would be to hook up a machine with a real operating
 system to the console of the Cisco and then use it as a backwards
 terminal server.
 
 Making things work on Transarc/OpenAFS AFS
 ==========================================
 
 How to get a KeyFile
 --------------------
 
 `ktutil -k AFSKEYFILE:KeyFile get afs@MY.REALM'
 
 or you can extract it with kadmin
 
      kadmin> ext -k AFSKEYFILE:/usr/afs/etc/KeyFile afs@My.CELL.NAME
 
 You have to make sure you have a `des-cbc-md5' encryption type since
 that is the key that will be converted.
 
 How to convert a srvtab to a KeyFile
 ------------------------------------
 
 You need a `/usr/vice/etc/ThisCell' containing the cellname of you
 AFS-cell.
 
 `ktutil copy krb4:/root/afs-srvtab AFSKEYFILE:/usr/afs/etc/KeyFile'.
 
 If keyfile already exists, this will add the new key in afs-srvtab to
 KeyFile.
 
 Using 2b tokens with AFS
 ========================
 
 What is 2b ?
 ------------
 
 2b is the name of the proposal that was implemented to give basic
 Kerberos 5 support to AFS in rxkad. Its not real Kerberos 5 support
 since it still uses fcrypt for data encryption and not Kerberos
 encryption types.
 
 Its only possible (in all cases) to do this for DES encryption types
 because only then the token (the AFS equivalent of a ticket) will be be
 smaller than the maximum size that can fit in the token cache in
 OpenAFS/Transarc client. Its so tight fit that some extra wrapping on
 the ASN1/DER encoding is removed from the Kerberos ticket.
 
 2b uses a Kerberos 5 EncTicketPart instead of a Kerberos 4 ditto for
 the part of the ticket that is encrypted with the service's key. The
 client doesn't know what's inside the encrypted data so to the client
 it doesn't matter.
 
 To  differentiate between Kerberos 4 tickets and Kerberos 5 tickets 2b
 uses a special kvno, 213 for 2b tokens and 255 for Kerberos 5 tokens.
 
 Its a requirement that all AFS servers that support 2b also support
 native Kerberos 5 in rxkad.
 
 Configuring Heimdal to use 2b tokens
 ------------------------------------
 
 Support for 2b tokens are turned on for specific principals by adding
 them to the string list option `[kdc]use_2b' in the kdc's `krb5.conf'
 file.
 
      [kdc]
      	use_2b = {
      		afs@SU.SE = yes
      		afs/it.su.se@SU.SE = yes
      	}
 
 Configuring AFS clients
 -----------------------
 
 There is no need to configure AFS clients. The only software that needs
 to be installed/upgrade is a Kerberos 5 enabled `afslog'.
Info Catalog
(heimdal.info) Setting up a realm
(heimdal.info) Top
(heimdal.info) Kerberos 4 issues
automatically generated byinfo2html