127 lines
4.8 KiB
Plaintext
127 lines
4.8 KiB
Plaintext
@c $Id: misc.texi,v 1.13 2003/03/30 21:30:59 lha Exp $
|
|
|
|
@node Things in search for a better place, Kerberos 4 issues, Setting up a realm, Top
|
|
@chapter Things in search for a better place
|
|
|
|
@section 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:
|
|
|
|
@example
|
|
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
|
|
@end example
|
|
|
|
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 @samp{encode_as_rep_as_tgs_rep} flag in the
|
|
KDC. You will also have to specify that the router can't handle anything
|
|
but @samp{des-cbc-crc}. This can be done with the @samp{del_enctype}
|
|
command of @samp{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.
|
|
|
|
@section Making things work on Transarc/OpenAFS AFS
|
|
|
|
@subsection How to get a KeyFile
|
|
|
|
@file{ktutil -k AFSKEYFILE:KeyFile get afs@@MY.REALM}
|
|
|
|
or you can extract it with kadmin
|
|
|
|
@example
|
|
kadmin> ext -k AFSKEYFILE:/usr/afs/etc/KeyFile afs@@My.CELL.NAME
|
|
@end example
|
|
|
|
You have to make sure you have a @code{des-cbc-md5} encryption type since that
|
|
is the key that will be converted.
|
|
|
|
@subsection How to convert a srvtab to a KeyFile
|
|
|
|
You need a @file{/usr/vice/etc/ThisCell} containing the cellname of you
|
|
AFS-cell.
|
|
|
|
@file{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.
|
|
|
|
@section Using 2b tokens with AFS
|
|
|
|
@subsection 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.
|
|
|
|
@subsection Configuring Heimdal to use 2b tokens
|
|
|
|
Support for 2b tokens are turned on for specific principals by adding
|
|
them to the string list option @code{[kdc]use_2b} in the kdc's
|
|
@file{krb5.conf} file.
|
|
|
|
@example
|
|
[kdc]
|
|
use_2b = @{
|
|
afs@@SU.SE = yes
|
|
afs/it.su.se@@SU.SE = yes
|
|
@}
|
|
@end example
|
|
|
|
@subsection 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 @file{afslog}.
|