doc: Fix Texinfo docs; remove krb4 references

This commit is contained in:
Nicolas Williams
2022-03-16 17:48:23 -05:00
parent dcef1341d3
commit 0878a568f9
9 changed files with 27 additions and 278 deletions

@ -5,164 +5,10 @@
@chapter Applications
@menu
* Authentication modules::
* AFS::
@end menu
@node Authentication modules, AFS, Applications, Applications
@section Authentication modules
The problem of having different authentication mechanisms has been
recognised by several vendors, and several solutions have appeared. In
most cases these solutions involve some kind of shared modules that are
loaded at run-time. Modules for some of these systems can be found in
@file{lib/auth}. Presently there are modules for Digital's SIA,
and IRIX' @code{login} and @code{xdm} (in
@file{lib/auth/afskauthlib}).
@menu
* Digital SIA::
* IRIX::
@end menu
@node Digital SIA, IRIX, Authentication modules, Authentication modules
@subsection Digital SIA
How to install the SIA module depends on which OS version you're
running. Tru64 5.0 has a new command, @file{siacfg}, which makes this
process quite simple. If you have this program, you should just be able
to run:
@example
siacfg -a KRB5 /usr/athena/lib/libsia_krb5.so
@end example
On older versions, or if you want to do it by hand, you have to do the
following (not tested by us on Tru64 5.0):
@itemize @bullet
@item
Make sure @file{libsia_krb5.so} is available in
@file{/usr/athena/lib}. If @file{/usr/athena} is not on local disk, you
might want to put it in @file{/usr/shlib} or someplace else. If you do,
you'll have to edit @file{krb5_matrix.conf} to reflect the new location
(you will also have to do this if you installed in some other directory
than @file{/usr/athena}). If you built with shared libraries, you will
have to copy the shared @file{libkrb.so}, @file{libdes.so},
@file{libkadm.so}, and @file{libkafs.so} to a place where the loader can
find them (such as @file{/usr/shlib}).
@item
Copy (your possibly edited) @file{krb5_matrix.conf} to @file{/etc/sia}.
@item
Apply @file{security.patch} to @file{/sbin/init.d/security}.
@item
Turn on KRB5 security by issuing @kbd{rcmgr set SECURITY KRB5} and
@kbd{rcmgr set KRB5_MATRIX_CONF krb5_matrix.conf}.
@item
Digital thinks you should reboot your machine, but that really shouldn't
be necessary. It's usually sufficient just to run
@kbd{/sbin/init.d/security start} (and restart any applications that use
SIA, like @code{xdm}.)
@end itemize
Users with local passwords (like @samp{root}) should be able to login
safely.
When using Digital's xdm the @samp{KRB5CCNAME} environment variable isn't
passed along as it should (since xdm zaps the environment). Instead you
have to set @samp{KRB5CCNAME} to the correct value in
@file{/usr/lib/X11/xdm/Xsession}. Add a line similar to
@example
KRB5CCNAME=FILE:/tmp/krb5cc`id -u`_`ps -o ppid= -p $$`; export KRB5CCNAME
@end example
If you use CDE, @code{dtlogin} allows you to specify which additional
environment variables it should export. To add @samp{KRB5CCNAME} to this
list, edit @file{/usr/dt/config/Xconfig}, and look for the definition of
@samp{exportList}. You want to add something like:
@example
Dtlogin.exportList: KRB5CCNAME
@end example
@subsubheading Notes to users with Enhanced security
Digital's @samp{ENHANCED} (C2) security, and Kerberos solve two
different problems. C2 deals with local security, adds better control of
who can do what, auditing, and similar things. Kerberos deals with
network security.
To make C2 security work with Kerberos you will have to do the
following.
@itemize @bullet
@item
Replace all occurrences of @file{krb5_matrix.conf} with
@file{krb5+c2_matrix.conf} in the directions above.
@item
You must enable ``vouching'' in the @samp{default} database. This will
make the OSFC2 module trust other SIA modules, so you can login without
giving your C2 password. To do this use @samp{edauth} to edit the
default entry @kbd{/usr/tcb/bin/edauth -dd default}, and add a
@samp{d_accept_alternate_vouching} capability, if not already present.
@item
For each user who does @emph{not} have a local C2 password, you should
set the password expiration field to zero. You can do this for each
user, or in the @samp{default} table. To do this use @samp{edauth} to
set (or change) the @samp{u_exp} capability to @samp{u_exp#0}.
@item
You also need to be aware that the shipped @file{login}, @file{rcp}, and
@file{rshd}, don't do any particular C2 magic (such as checking for
various forms of disabled accounts), so if you rely on those features,
you shouldn't use those programs. If you configure with
@samp{--enable-osfc2}, these programs will, however, set the login
UID. Still: use at your own risk.
@end itemize
At present @samp{su} does not accept the vouching flag, so it will not
work as expected.
Also, kerberised ftp will not work with C2 passwords. You can solve this
by using both Digital's ftpd and our on different ports.
@strong{Remember}, if you do these changes you will get a system that
most certainly does @emph{not} fulfil the requirements of a C2
system. If C2 is what you want, for instance if someone else is forcing
you to use it, you're out of luck. If you use enhanced security because
you want a system that is more secure than it would otherwise be, you
probably got an even more secure system. Passwords will not be sent in
the clear, for instance.
@node IRIX, , Digital SIA, Authentication modules
@subsection IRIX
The IRIX support is a module that is compatible with Transarc's
@file{afskauthlib.so}. It should work with all programs that use this
library. This should include @command{login} and @command{xdm}.
The interface is not very documented but it seems that you have to copy
@file{libkafs.so}, @file{libkrb.so}, and @file{libdes.so} to
@file{/usr/lib}, or build your @file{afskauthlib.so} statically.
The @file{afskauthlib.so} itself is able to reside in
@file{/usr/vice/etc}, @file{/usr/afsws/lib}, or the current directory
(wherever that is).
IRIX 6.4 and newer seem to have all programs (including @command{xdm} and
@command{login}) in the N32 object format, whereas in older versions they
were O32. For it to work, the @file{afskauthlib.so} library has to be in
the same object format as the program that tries to load it. This might
require that you have to configure and build for O32 in addition to the
default N32.
Apart from this it should ``just work''; there are no configuration
files.
Note that recent Irix 6.5 versions (at least 6.5.22) have PAM,
including a @file{pam_krb5.so} module. Not all relevant programs use
PAM, though, e.g.@: @command{ssh}. In particular, for console
graphical login you need to turn off @samp{visuallogin} and turn on
@samp{xdm} with @command{chkconfig}.
@node AFS, , Authentication modules, Applications
@node AFS, , Applications, Applications
@section AFS
@cindex AFS
@ -223,48 +69,3 @@ AFS-cell.
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. It's 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
smaller than the maximum size that can fit in the token cache in the
OpenAFS/Transarc client. It is a 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 a Heimdal kdc to use 2b tokens
Support for 2b tokens in the kdc 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 for 2b support
There is no need to configure AFS clients for 2b support. The only
software that needs to be installed/upgrade is a Kerberos 5 enabled
@file{afslog}.

@ -10,9 +10,7 @@
@end macro
@node Copyrights and Licenses, , Acknowledgments, Top
@comment node-name, next, previous, up
@appendix Copyrights and Licenses
@heading Kungliga Tekniska Högskolan

@ -1,4 +1,5 @@
\input texinfo @c -*- texinfo -*-
@c %**start of header
@c $Id$
@setfilename heimdal.info
@ -7,9 +8,7 @@
@afourpaper
@end iftex
@c some sensible characters, please?
@tex
\input latin1.tex
@end tex
@documentencoding UTF-8
@setchapternewpage on
@syncodeindex pg cp
@c %**end of header
@ -73,7 +72,6 @@ This manual for version @value{VERSION} of Heimdal.
* Setting up a realm::
* Applications::
* Things in search for a better place::
* Kerberos 4 issues::
* Windows compatibility::
* Programming with Kerberos::
* Migration::
@ -106,19 +104,8 @@ Setting up a realm
Applications
* Authentication modules::
* AFS::
Authentication modules
* Digital SIA::
* IRIX::
Kerberos 4 issues
* Principal conversion issues::
* Converting a version 4 database::
Windows compatibility
* Configuring Windows to use a Heimdal KDC::
@ -140,14 +127,14 @@ Programming with Kerberos
@include setup.texi
@include apps.texi
@include misc.texi
@include kerberos4.texi
@include win2k.texi
@include programming.texi
@include migration.texi
@include ack.texi
@node Copyrights and Licenses, , Acknowledgments, Top
@comment node-name, next, previous, up
@include copyright.texi
@c @shortcontents
@contents
@bye

@ -7,9 +7,7 @@
@afourpaper
@end iftex
@c some sensible characters, please?
@tex
\input latin1.tex
@end tex
@documentencoding UTF-8
@setchapternewpage on
@syncodeindex pg cp
@c %**end of header
@ -39,12 +37,14 @@
@def@copyrightstart{}
@def@copyrightend{}
@end iftex
@ifnottex
@macro copynext
@end macro
@macro copyrightstart
@end macro
@macro copyrightend
@end macro
@end ifnottex
@page
@copyrightstart

@ -16,6 +16,10 @@ To load the MIT Kerberos dump file, use the following command:
kadmin can dump in MIT Kerberos format. Simply run:
@samp{kadmin -l dump -f MIT}.
There are some limitations in this functionality. Users should check
the input dump and a native dump after loading to check for
differences.
The Heimdal KDC and kadmind, as well as kadmin -l and the libkadm5srv
library can read and write MIT KDBs, and can read MIT stash files. To
build with KDB support requires having a standalone libdb from MIT
@ -35,8 +39,6 @@ and hpropd.
@section General issues
When migrating from a Kerberos 4 KDC.
@section Order in what to do things:
@itemize @bullet
@ -63,11 +65,5 @@ you can also check the kdc-log to check what ticket are checked out.
@item Burn the bridge and change the master.
@item Let all users use the Kerberos 5 tools by default.
@item Turn off services that do not need Kerberos 4 authentication.
Things that might be hard to get away is old programs with support for
Kerberos 4. Example applications are old Eudora installations using
KPOP, and Zephyr. Eudora can use the Kerberos 4 kerberos in the Heimdal
kdc.
@end itemize

@ -1,6 +1,6 @@
@c $Id$
@node Things in search for a better place, Kerberos 4 issues, Applications, Top
@node Things in search for a better place, Windows compatibility, Applications, Top
@chapter Things in search for a better place
@section Making things work on Ciscos

@ -84,11 +84,9 @@ are briefly described here.
The @samp{libdefaults} section contains a list of library configuration
parameters, such as the default realm and the timeout for KDC
responses. The @samp{realms} section contains information about specific
realms, such as where they hide their KDC@. This section serves the same
purpose as the Kerberos 4 @file{krb.conf} file, but can contain more
information. Finally the @samp{domain_realm} section contains a list of
mappings from domains to realms, equivalent to the Kerberos 4
@file{krb.realms} file.
realms, such as where they hide their KDC@.
Finally the @samp{domain_realm} section contains a list of
mappings from domains to realms.
To continue with the realm setup, you will have to create a configuration file,
with contents similar to the following.
@ -674,10 +672,6 @@ fixed size encryption key.
In Kerberos 5 the salt is determined by the encryption type, except in
some special cases.
In @code{des} there is the Kerberos 4 salt
(none at all) or the afs-salt (using the cell (realm in
AFS lingo)).
In @code{arcfour} (the encryption type that Microsoft Windows 2000 uses)
there is no salt. This is to be compatible with NTLM keys in Windows
NT 4.
@ -696,12 +690,6 @@ no salt at all).
Common types of salting include
@itemize @bullet
@item @code{v4} (or @code{des:pw-salt:})
The Kerberos 4 salting is using no salt at all. Reason there is colon
at the end of the salt string is that it makes the salt the empty
string (same as no salt).
@item @code{v5} (or @code{pw-salt})
@code{pw-salt} uses the default salt for each encryption type is

@ -29,28 +29,6 @@ services can authenticate each other.
@section Basic mechanism
@ifinfo
@macro sub{arg}
<\arg\>
@end macro
@end ifinfo
@iftex
@macro sub{arg}
@textsubscript{\arg\}
@end macro
@end iftex
@ifhtml
@macro sub{arg}
@html
<sub>\arg\</sub>
@end html
@end macro
@end ifhtml
@c ifdocbook
@c macro sub{arg}
@c docbook
@ -133,8 +111,10 @@ It would be possible to add a @dfn{replay cache}
to the server side. The idea is to save the authenticators sent during
the last few minutes, so that @var{B} can detect when someone is trying
to retransmit an already used message. This is somewhat impractical
(mostly regarding efficiency), and is not part of Kerberos 4; MIT
Kerberos 5 contains it.
(mostly regarding performance); MIT Kerberos 5 has a replay cache,
while Heimdal does not.
However, most GSS-API applicatons do not need a replay cache at all.
To authenticate @var{B}, @var{A} might request that @var{B} sends
something back that proves that @var{B} has access to the session

@ -1,7 +1,7 @@
@c $Id$
@node Windows compatibility, Programming with Kerberos, Kerberos 4 issues, Top
@node Windows compatibility, Programming with Kerberos, Things in search for a better place, Top
@comment node-name, next, previous, up
@chapter Windows compatibility
@ -126,8 +126,7 @@ You also need to add the inter-realm keys to the Heimdal KDC. But take
care to the encryption types and salting used for those keys. There should be
no encryption type stronger than the one configured on Windows side for this
relationship, itself limited to the ones supported by this specific version of
Windows, nor any Kerberos 4 salted hashes, as Windows does not seem to
understand them. Otherwise, the trust will not works.
Windows. Otherwise, the trust will not works.
Here are the version-specific needed information:
@enumerate
@ -235,11 +234,11 @@ analysing the data.
@comment node-name, next, previous, up
@section Quirks of Windows 2000 KDC
There are some issues with salts and Windows 2000. Using an empty salt---which is the only one that Kerberos 4 supported, and is therefore known
as a Kerberos 4 compatible salt---does not work, as far as we can tell
from out experiments and users' reports. Therefore, you have to make
sure you keep around keys with all the different types of salts that are
required. Microsoft have fixed this issue post Windows 2003.
There are some issues with salts and Windows 2000. Using an empty salt does
not work, as far as we can tell from out experiments and users' reports.
Therefore, you have to make sure you keep around keys with all the different
types of salts that are required. Microsoft have fixed this issue post Windows
2003.
Microsoft seems also to have forgotten to implement the checksum
algorithms @samp{rsa-md4-des} and @samp{rsa-md5-des}. This can make Name