heimdal/doc/apps.texi

@c $Id$

@node Applications, Things in search for a better place, Setting up a realm, Top

@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 has 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 have 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 solves 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 occurencies 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 that 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}, doesn't do any particular C2 magic (such as checking to
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} fulfill 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 @file{login} and @file{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 seems to have all programs (including @file{xdm} and
@file{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.

Appart from this it should ``just work'', there are no configuration
files.

@node AFS, , Authentication modules, Applications
@section AFS

@cindex AFS
AFS is a distributed filesystem that uses Kerberos for authentication.

@cindex OpenAFS
@cindex Arla
For more information about AFS see OpenAFS
@url{http://www.openafs.org/} and Arla
@url{http://www.stacken.kth.se/projekt/arla/}.

@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 enctype 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 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}.