diff --git a/doc/apps.texi b/doc/apps.texi index 98585c4d0..2b48edaaf 100644 --- a/doc/apps.texi +++ b/doc/apps.texi @@ -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}. diff --git a/doc/copyright.texi b/doc/copyright.texi index d9f1a8c2e..886bf2cda 100644 --- a/doc/copyright.texi +++ b/doc/copyright.texi @@ -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 diff --git a/doc/heimdal.texi b/doc/heimdal.texi index c8ef24969..00041ca76 100644 --- a/doc/heimdal.texi +++ b/doc/heimdal.texi @@ -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 diff --git a/doc/hx509.texi b/doc/hx509.texi index 0a90cb735..4d0f05682 100644 --- a/doc/hx509.texi +++ b/doc/hx509.texi @@ -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 diff --git a/doc/migration.texi b/doc/migration.texi index 2fa7ede59..7c3e1e70e 100644 --- a/doc/migration.texi +++ b/doc/migration.texi @@ -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 diff --git a/doc/misc.texi b/doc/misc.texi index 1ad6aaab0..2d976f45d 100644 --- a/doc/misc.texi +++ b/doc/misc.texi @@ -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 diff --git a/doc/setup.texi b/doc/setup.texi index 0b3a860ed..8600d3471 100644 --- a/doc/setup.texi +++ b/doc/setup.texi @@ -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 diff --git a/doc/whatis.texi b/doc/whatis.texi index 902344b03..aed3d81f5 100644 --- a/doc/whatis.texi +++ b/doc/whatis.texi @@ -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 -\arg\ -@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 diff --git a/doc/win2k.texi b/doc/win2k.texi index 0fefeee3f..d4ab2fecd 100644 --- a/doc/win2k.texi +++ b/doc/win2k.texi @@ -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