665 lines
24 KiB
Plaintext
665 lines
24 KiB
Plaintext
@c $Id: setup.texi,v 1.27.2.2 2003/10/21 21:37:56 lha Exp $
|
|
|
|
@node Setting up a realm, Things in search for a better place, Building and Installing, Top
|
|
|
|
@chapter Setting up a realm
|
|
|
|
@menu
|
|
* Configuration file::
|
|
* Creating the database::
|
|
* keytabs::
|
|
* Serving Kerberos 4/524/kaserver::
|
|
* Remote administration::
|
|
* Password changing::
|
|
* Testing clients and servers::
|
|
* Slave Servers::
|
|
* Incremental propagation::
|
|
* Salting::
|
|
* Cross realm::
|
|
* Transit policy::
|
|
* Setting up DNS::
|
|
@end menu
|
|
|
|
A
|
|
@cindex realm
|
|
realm is an administrative domain. The name of a Kerberos realm is
|
|
usually the Internet domain name in uppercase. Call your realm the same
|
|
as your Internet domain name if you do not have strong reasons for not
|
|
doing so. It will make life easier for you and everyone else.
|
|
|
|
@node Configuration file, Creating the database, Setting up a realm, Setting up a realm
|
|
@section Configuration file
|
|
|
|
To setup a realm you will first have to create a configuration file:
|
|
@file{/etc/krb5.conf}. The @file{krb5.conf} file can contain many
|
|
configuration options, some of which are described here.
|
|
|
|
There is a sample @file{krb5.conf} supplied with the distribution.
|
|
|
|
The configuration file is a hierarchical structure consisting of
|
|
sections, each containing a list of bindings (either variable
|
|
assignments or subsections). A section starts with
|
|
@samp{[section-name]}. A binding consists of a left hand side, an equal
|
|
(@samp{=}) and a right hand side (the left hand side tag must be
|
|
separated from the equal with some whitespace.) Subsections has a
|
|
@samp{@{} as the first non-whitespace character after the equal. All
|
|
other bindings are treated as variable assignments. The value of a
|
|
variable extends to the end of the line.
|
|
|
|
@example
|
|
[section1]
|
|
a-subsection = @{
|
|
var = value1
|
|
other-var = value with @{@}
|
|
sub-sub-section = @{
|
|
var = 123
|
|
@}
|
|
@}
|
|
var = some other value
|
|
[section2]
|
|
var = yet another value
|
|
@end example
|
|
|
|
In this manual, names of sections and bindings will be given as strings
|
|
separated by slashes (@samp{/}). The @samp{other-var} variable will thus
|
|
be @samp{section1/a-subsection/other-var}.
|
|
|
|
For in-depth information about the contents of the configuration file, refer to
|
|
the @file{krb5.conf} manual page. Some of the more important sections
|
|
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.
|
|
|
|
To continue with the realm setup, you will have to create a configuration file,
|
|
with contents similar to the following.
|
|
|
|
@example
|
|
[libdefaults]
|
|
default_realm = MY.REALM
|
|
[realms]
|
|
MY.REALM = @{
|
|
kdc = my.kdc my.slave.kdc
|
|
kdc = my.third.kdc
|
|
@}
|
|
[domain_realm]
|
|
.my.domain = MY.REALM
|
|
|
|
@end example
|
|
|
|
If you use a realm name equal to your domain name, you can omit the
|
|
@samp{libdefaults}, and @samp{domain_realm}, sections. If you have a
|
|
SRV-record for your realm, or your Kerberos server has CNAME called
|
|
@samp{kerberos.my.realm}, you can omit the @samp{realms} section too.
|
|
|
|
@node Creating the database, keytabs, Configuration file, Setting up a realm
|
|
@section Creating the database
|
|
|
|
The database library will look for the database in the directory
|
|
@file{/var/heimdal}, so you should probably create that directory.
|
|
Make sure the directory have restrictive permissions.
|
|
|
|
@example
|
|
# mkdir /var/heimdal
|
|
@end example
|
|
|
|
The keys of all the principals are stored in the database. If you
|
|
choose to, these can be encrypted with a master key. You do not have to
|
|
remember this key (or password), but just to enter it once and it will
|
|
be stored in a file (@file{/var/heimdal/m-key}). If you want to have a
|
|
master key, run @samp{kstash} to create this master key:
|
|
|
|
@example
|
|
# kstash
|
|
Master key:
|
|
Verifying password - Master key:
|
|
@end example
|
|
|
|
To initialise the database use the @code{kadmin} program, with the
|
|
@samp{-l} option (to enable local database mode). First issue a
|
|
@kbd{init MY.REALM} command. This will create the database and insert
|
|
default principals for that realm. You can have more than one realm in
|
|
one database, so @samp{init} does not destroy any old database.
|
|
|
|
Before creating the database, @samp{init} will ask you some questions
|
|
about max ticket lifetimes.
|
|
|
|
After creating the database you should probably add yourself to it. You
|
|
do this with the @samp{add} command. It takes as argument the name of a
|
|
principal. The principal should contain a realm, so if you haven't setup
|
|
a default realm, you will need to explicitly include the realm.
|
|
|
|
@example
|
|
# kadmin -l
|
|
kadmin> init MY.REALM
|
|
Realm max ticket life [unlimited]:
|
|
Realm max renewable ticket life [unlimited]:
|
|
kadmin> add me
|
|
Max ticket life [unlimited]:
|
|
Max renewable life [unlimited]:
|
|
Attributes []:
|
|
Password:
|
|
Verifying password - Password:
|
|
@end example
|
|
|
|
Now start the KDC and try getting a ticket.
|
|
|
|
@example
|
|
# kdc &
|
|
# kinit me
|
|
me@@MY.REALMS's Password:
|
|
# klist
|
|
Credentials cache: /tmp/krb5cc_0
|
|
Principal: me@@MY.REALM
|
|
|
|
Issued Expires Principal
|
|
Aug 25 07:25:55 Aug 25 17:25:55 krbtgt/MY.REALM@@MY.REALM
|
|
@end example
|
|
|
|
If you are curious you can use the @samp{dump} command to list all the
|
|
entries in the database. It should look something similar to the
|
|
following example (note that the entries here are truncated for
|
|
typographical reasons):
|
|
|
|
@smallexample
|
|
kadmin> dump
|
|
me@@MY.REALM 1:0:1:0b01d3cb7c293b57:-:0:7:8aec316b9d1629e3baf8 ...
|
|
kadmin/admin@@MY.REALM 1:0:1:e5c8a2675b37a443:-:0:7:cb913ebf85 ...
|
|
krbtgt/MY.REALM@@MY.REALM 1:0:1:52b53b61c875ce16:-:0:7:c8943be ...
|
|
kadmin/changepw@@MY.REALM 1:0:1:f48c8af2b340e9fb:-:0:7:e3e6088 ...
|
|
@end smallexample
|
|
|
|
@node keytabs, Serving Kerberos 4/524/kaserver, Creating the database, Setting up a realm
|
|
@section keytabs
|
|
|
|
To extract a service ticket from the database and put it in a keytab you
|
|
need to first create the principal in the database with @samp{ank}
|
|
(using the @kbd{--random-key} flag to get a random key) and then
|
|
extract it with @samp{ext_keytab}.
|
|
|
|
@example
|
|
kadmin> add --random-key host/my.host.name
|
|
Max ticket life [unlimited]:
|
|
Max renewable life [unlimited]:
|
|
Attributes []:
|
|
kadmin> ext host/my.host.name
|
|
# ktutil list
|
|
Version Type Principal
|
|
1 des-cbc-md5 host/my.host.name@@MY.REALM
|
|
1 des-cbc-md4 host/my.host.name@@MY.REALM
|
|
1 des-cbc-crc host/my.host.name@@MY.REALM
|
|
1 des3-cbc-sha1 host/my.host.name@@MY.REALM
|
|
@end example
|
|
|
|
@node Serving Kerberos 4/524/kaserver, Remote administration, keytabs, Setting up a realm
|
|
@section Serving Kerberos 4/524/kaserver
|
|
|
|
Heimdal can be configured to support 524, Kerberos 4 or kaserver. All
|
|
theses services are default turned off. Kerberos 4 support also
|
|
depends on if Kerberos 4 support is compiled in with Heimdal.
|
|
|
|
@subsection 524
|
|
|
|
524 is a service that allows the KDC to convert Kerberos 5 tickets to
|
|
Kerberos 4 tickets for backward compatibility. See also Using 2b
|
|
tokens with AFS in @xref{Things in search for a better place}.
|
|
|
|
524 can be turned on by adding this to the configuration file
|
|
|
|
@example
|
|
[kdc]
|
|
enable-524 = yes
|
|
@end example
|
|
|
|
@subsection Kerberos 4
|
|
|
|
Kerberos 4 is the predecessor to to Kerberos 5. It only support single
|
|
DES. You should only enable Kerberos 4 support if you have a need for
|
|
for compatibility with an installed base of Kerberos 4 clients/servers.
|
|
|
|
Kerberos 4 can be turned on by adding this to the configuration file
|
|
|
|
@example
|
|
[kdc]
|
|
enable-kerberos4 = yes
|
|
@end example
|
|
|
|
@subsection kaserver
|
|
|
|
Kaserver is a Kerberos 4 that is used in AFS, the protocol have some
|
|
features over plain Kerberos 4, but like Kerberos 4 only use single
|
|
DES too.
|
|
|
|
You should only enable Kerberos 4 support if you have a need for for
|
|
compatibility with an installed base of AFS machines.
|
|
|
|
Kaserver can be turned on by adding this to the configuration file
|
|
|
|
@example
|
|
[kdc]
|
|
enable-kaserver = yes
|
|
@end example
|
|
|
|
@node Remote administration, Password changing, Serving Kerberos 4/524/kaserver, Setting up a realm
|
|
@section Remote administration
|
|
|
|
The administration server, @samp{kadmind}, can be started by
|
|
@samp{inetd} (which isn't recommended) or run as a normal daemon. If you
|
|
want to start it from @samp{inetd} you should add a line similar to the
|
|
one below to your @file{/etc/inetd.conf}.
|
|
|
|
@example
|
|
kerberos-adm stream tcp nowait root /usr/heimdal/libexec/kadmind kadmind
|
|
@end example
|
|
|
|
You might need to add @samp{kerberos-adm} to your @file{/etc/services}
|
|
as 749/tcp.
|
|
|
|
Access to the administration server is controlled by an acl-file, (default
|
|
@file{/var/heimdal/kadmind.acl}.) The lines in the access file, has the
|
|
following syntax:
|
|
@smallexample
|
|
principal [priv1,priv2,...] [glob-pattern]
|
|
@end smallexample
|
|
|
|
The matching is from top to bottom for matching principal (and if given,
|
|
glob-pattern). When there is a match, the rights of that lines are
|
|
used.
|
|
|
|
The privileges you can assign to a principal are: @samp{add},
|
|
@samp{change-password} (or @samp{cpw} for short), @samp{delete},
|
|
@samp{get}, @samp{list}, and @samp{modify}, or the special privilege
|
|
@samp{all}. All of these roughly corresponds to the different commands
|
|
in @samp{kadmin}.
|
|
|
|
If a @var{glob-pattern} is given on a line, it restricts the right for
|
|
the principal to only apply for the subjects that match the pattern.
|
|
The patters are of the same type as those used in shell globbing, see
|
|
@url{none,,fnmatch(3)}.
|
|
|
|
In the example below @samp{lha/admin} can change every principal in the
|
|
database. @samp{jimmy/admin} can only modify principals that belong to
|
|
the realm @samp{E.KTH.SE}. @samp{mille/admin} is working at the
|
|
help desk, so he should only be able to change the passwords for single
|
|
component principals (ordinary users). He will not be able to change any
|
|
@samp{/admin} principal.
|
|
|
|
@example
|
|
lha/admin@@E.KTH.SE all
|
|
jimmy/admin@@E.KTH.SE all *@@E.KTH.SE
|
|
jimmy/admin@@E.KTH.SE all */*@@E.KTH.SE
|
|
mille/admin@@E.KTH.SE change-password *@@E.KTH.SE
|
|
@end example
|
|
|
|
@node Password changing, Testing clients and servers, Remote administration, Setting up a realm
|
|
@section Password changing
|
|
|
|
To allow users to change their passwords, you should run @samp{kpasswdd}.
|
|
It is not run from @samp{inetd}.
|
|
|
|
You might need to add @samp{kpasswd} to your @file{/etc/services} as
|
|
464/udp.
|
|
|
|
@subsection Password quality assurance
|
|
|
|
It is important that users have good passwords, both to make it harder
|
|
to guess them and to avoid off-line attacks (pre-authentication provides
|
|
some defense against off-line attacks). To ensure that the users choose
|
|
good passwords, you can enable password quality controls in
|
|
@samp{kpasswdd}. The controls themselves are done in a shared library
|
|
that is used by @samp{kpasswdd}. To configure in these controls, add
|
|
lines similar to the following to your @file{/etc/krb5.conf}:
|
|
|
|
@example
|
|
[password_quality]
|
|
check_library = @var{library}
|
|
check_function = @var{function}
|
|
@end example
|
|
|
|
The function @var{function} in the shared library @var{library} will be
|
|
called for proposed new passwords. The function should be declared as:
|
|
|
|
@example
|
|
const char *
|
|
function(krb5_context context, krb5_principal principal, krb5_data *pwd);
|
|
@end example
|
|
|
|
The function should verify that @var{pwd} is a good password for
|
|
@var{principal} and if so return @code{NULL}. If it is deemed to be of
|
|
low quality, it should return a string explaining why that password
|
|
should not be used.
|
|
|
|
Code for a password quality checking function that uses the cracklib
|
|
library can be found in @file{lib/kadm5/sample_password_check.c} in the
|
|
source code distribution. It requires the cracklib library built with
|
|
the patch available at
|
|
@url{ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch}.
|
|
|
|
If no password quality checking function is configured, it is only
|
|
verified that it is at least six characters of length.
|
|
|
|
@node Testing clients and servers, Slave Servers, Password changing, Setting up a realm
|
|
@section Testing clients and servers
|
|
|
|
Now you should be able to run all the clients and servers. Refer to the
|
|
appropriate man pages for information on how to use them.
|
|
|
|
@node Slave Servers, Incremental propagation, Testing clients and servers, Setting up a realm
|
|
@section Slave servers, Incremental propagation, Testing clients and servers, Setting up a realm
|
|
|
|
It is desirable to have at least one backup (slave) server in case the
|
|
master server fails. It is possible to have any number of such slave
|
|
servers but more than three usually doesn't buy much more redundancy.
|
|
|
|
All Kerberos servers for a realm shall have the same database so that
|
|
they present the same service to all the users. The
|
|
@pindex hprop
|
|
@code{hprop} program, running on the master, will propagate the database
|
|
to the slaves, running
|
|
@pindex hpropd
|
|
@code{hpropd} processes.
|
|
|
|
Every slave needs a database directory, the master key (if it was used
|
|
for the database) and a keytab with the principal
|
|
@samp{hprop/@var{hostname}}. Add the principal with the
|
|
@pindex ktutil
|
|
@code{ktutil} command and start
|
|
@pindex hpropd
|
|
@code{propd}, as follows:
|
|
|
|
@example
|
|
slave# ktutil get -p foo/admin hprop/`hostname`
|
|
slave# mkdir /var/heimdal
|
|
slave# hpropd
|
|
@end example
|
|
|
|
The master will use the principal @samp{kadmin/hprop} to authenticate to
|
|
the slaves. This principal should be added when running @kbd{kadmin -l
|
|
init} but if you do not have it in your database for whatever reason,
|
|
please add it with @kbd{kadmin -l add}.
|
|
|
|
Then run
|
|
@pindex hprop
|
|
@code{hprop} on the master:
|
|
|
|
@example
|
|
master# hprop slave
|
|
@end example
|
|
|
|
This was just an on-hands example to make sure that everything was
|
|
working properly. Doing it manually is of course the wrong way and to
|
|
automate this you will want to start
|
|
@pindex hpropd
|
|
@code{hpropd} from @code{inetd} on the slave(s) and regularly run
|
|
@pindex hprop
|
|
@code{hprop} on the master to regularly propagate the database.
|
|
Starting the propagation once an hour from @code{cron} is probably a
|
|
good idea.
|
|
|
|
@node Incremental propagation, Salting , Slave Servers, Setting up a realm
|
|
@section Incremental propagation
|
|
|
|
There is also a newer and still somewhat experimental mechanism for
|
|
doing incremental propagation in Heimdal. Instead of sending the whole
|
|
database regularly, it sends the changes as they happen on the master to
|
|
the slaves. The master keeps track of all the changes by assigned a
|
|
version number to every change to the database. The slaves know which
|
|
was the latest version they saw and in this way it can be determined if
|
|
they are in sync or not. A log of all the changes is kept on the master
|
|
and when a slave is at an older versioner than the oldest one in the
|
|
log, the whole database has to be sent.
|
|
|
|
Protocol-wise, all the slaves connects to the master and as a greeting
|
|
tell it the latest version that they have (@samp{IHAVE} message). The
|
|
master then responds by sending all the changes between that version and
|
|
the current version at the master (a series of @samp{FORYOU} messages)
|
|
or the whole database in a @samp{TELLYOUEVERYTHING} message.
|
|
|
|
@subsection Configuring incremental propagation
|
|
|
|
The program that runs on the master is @code{ipropd-master} and all
|
|
clients run @code{ipropd-slave}.
|
|
|
|
Create the file @file{/var/heimdal/slaves} on the master containing all
|
|
the slaves that the database should be propagated to. Each line contains
|
|
the full name of the principal (for example
|
|
@samp{iprop/hemligare.foo.se@@FOO.SE}).
|
|
|
|
You should already have @samp{iprop/tcp} defined as 2121, in your
|
|
@file{/etc/services}. Otherwise, or if you need to use a different port
|
|
for some peculiar reason, you can use the @kbd{--port} option. This is
|
|
useful when you have multiple realms to distribute from one server.
|
|
|
|
Then you need to create these principals that you added in the
|
|
configuration file. Create one @samp{iprop/hostname} for the master and
|
|
for every slave.
|
|
|
|
|
|
@example
|
|
master# /usr/heimdal/sbin/ktutil get iprop/`hostname`
|
|
@end example
|
|
|
|
The next step is to start the @code{ipropd-master} process on the master
|
|
server. The @code{ipropd-master} listens on the UNIX-socket
|
|
@file{/var/heimdal/signal} to know when changes have been made to the
|
|
database so they can be propagated to the slaves. There is also a
|
|
safety feature of testing the version number regularly (every 30
|
|
seconds) to see if it has been modified by some means that do not raise
|
|
this signal. Then, start @code{ipropd-slave} on all the slaves:
|
|
|
|
@example
|
|
master# /usr/heimdal/libexec/ipropd-master &
|
|
slave# /usr/heimdal/libexec/ipropd-slave master &
|
|
@end example
|
|
|
|
@node Salting, Cross realm, Incremental propagation, Setting up a realm
|
|
@section Salting
|
|
@cindex Salting
|
|
|
|
Salting is used to make it harder to precalculate all possible
|
|
keys. Using a salt increases the search space to make it almost
|
|
impossible to precalculate all keys. Salting is the process of mixing a
|
|
public string (the salt) with the password, then sending it through an
|
|
encryption-type specific string-to-key function that will output the
|
|
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.
|
|
|
|
@code{[kadmin]default_keys} in @file{krb5.conf} controls
|
|
what salting to use,
|
|
|
|
The syntax of @code{[kadmin]default_keys} is
|
|
@samp{[etype:]salt-type[:salt-string]}. @samp{etype} is the encryption
|
|
type (des, des3, arcfour), @code{salt-type} is the type of salt (pw-salt
|
|
or afs3-salt), and the salt-string is the string that will be used as
|
|
salt (remember that if the salt is appended/prepended, the empty salt ""
|
|
is the same thing as no salt at all).
|
|
|
|
Common types of salting includes
|
|
|
|
@itemize @bullet
|
|
@item @code{v4} (or @code{des:pw-salt:})
|
|
|
|
The Kerberos 4 salting is using no salt att all. Reason there is colon
|
|
that the end or 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} means all regular encryption-types that is regular
|
|
|
|
@item @code{afs3-salt}
|
|
|
|
@code{afs3-salt} is the salting that is used with Transarc kaserver. Its
|
|
the cell appended to the password.
|
|
|
|
@end itemize
|
|
|
|
@node Cross realm, Transit policy , Salting, Setting up a realm
|
|
@section Cross realm
|
|
@cindex Cross realm
|
|
|
|
Suppose you are residing in the realm @samp{MY.REALM}, how do you
|
|
authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in
|
|
@samp{MY.REALM} allows you to communicate with kerberised services in that
|
|
realm. However, the computer in the other realm does not have a secret
|
|
key shared with the Kerberos server in your realm.
|
|
|
|
It is possible to add a share keys between two realms that trust each
|
|
other. When a client program, such as @code{telnet} or @code{ssh},
|
|
finds that the other computer is in a different realm, it will try to
|
|
get a ticket granting ticket for that other realm, but from the local
|
|
Kerberos server. With that ticket granting ticket, it will then obtain
|
|
service tickets from the Kerberos server in the other realm.
|
|
|
|
For a two way trust between @samp{MY.REALM} and @samp{OTHER.REALM}
|
|
add the following principals to each realm. The principals should be
|
|
@samp{krbtgt/OTHER.REALM@@MY.REALM} and
|
|
@samp{krbtgt/MY.REALM@@OTHER.REALM} in @samp{MY.REALM}, and
|
|
@samp{krbtgt/MY.REALM@@OTHER.REALM} and
|
|
@samp{krbtgt/OTHER.REALM@@MY.REALM}in @samp{OTHER.REALM}.
|
|
|
|
In Kerberos 5 the trust can be one configured to be one way. So that
|
|
users from @samp{MY.REALM} can authenticate to services in
|
|
@samp{OTHER.REALM}, but not the opposite. In the example above, the
|
|
@samp{krbtgt/MY.REALM@@OTHER.REALM} then should be removed.
|
|
|
|
The two principals must have the same key, key version number, and the
|
|
same set of encryption types. Remember to transfer the two keys in a
|
|
safe manner.
|
|
|
|
@example
|
|
@cartouche
|
|
vr$ klist
|
|
Credentials cache: FILE:/tmp/krb5cc_913.console
|
|
Principal: lha@@E.KTH.SE
|
|
|
|
Issued Expires Principal
|
|
May 3 13:55:52 May 3 23:55:54 krbtgt/E.KTH.SE@@E.KTH.SE
|
|
|
|
vr$ telnet -l lha hummel.it.su.se
|
|
Trying 2001:6b0:5:1095:250:fcff:fe24:dbf...
|
|
Connected to hummel.it.su.se.
|
|
Escape character is '^]'.
|
|
Waiting for encryption to be negotiated...
|
|
[ Trying mutual KERBEROS5 (host/hummel.it.su.se@@SU.SE)... ]
|
|
[ Kerberos V5 accepts you as ``lha@@E.KTH.SE'' ]
|
|
Encryption negotiated.
|
|
Last login: Sat May 3 14:11:47 from vr.l.nxs.se
|
|
hummel$ exit
|
|
|
|
vr$ klist
|
|
Credentials cache: FILE:/tmp/krb5cc_913.console
|
|
Principal: lha@@E.KTH.SE
|
|
|
|
Issued Expires Principal
|
|
May 3 13:55:52 May 3 23:55:54 krbtgt/E.KTH.SE@@E.KTH.SE
|
|
May 3 13:55:56 May 3 23:55:54 krbtgt/SU.SE@@E.KTH.SE
|
|
May 3 14:10:54 May 3 23:55:54 host/hummel.it.su.se@@SU.SE
|
|
|
|
@end cartouche
|
|
@end example
|
|
|
|
@node Transit policy, Setting up DNS , Cross realm, Setting up a realm
|
|
@section Transit policy
|
|
@cindex Transit policy
|
|
|
|
If you want to use cross realm authentication through an intermediate
|
|
realm it must be explicitly allowed by either the KDCs or the server
|
|
receiving the request. This is done in @file{krb5.conf} in the
|
|
@code{[capaths]} section.
|
|
|
|
When the ticket transits through a realm to another realm, the
|
|
destination realm adds its peer to the "transited-realms" field in the
|
|
ticket. The field is unordered, this is since there is no way to know if
|
|
know if one of the transited-realms changed the order of the list.
|
|
|
|
The syntax for @code{[capaths]} section:
|
|
|
|
@example
|
|
@cartouche
|
|
[capaths]
|
|
CLIENT-REALM = @{
|
|
SERVER-REALM = PERMITTED-CROSS-REALMS ...
|
|
@}
|
|
@end cartouche
|
|
@end example
|
|
|
|
The realm @code{STACKEN.KTH.SE} allows clients from @code{SU.SE} and
|
|
@code{DSV.SU.SE} to cross in. Since @code{STACKEN.KTH.SE} only have
|
|
direct cross realm with @code{KTH.SE}, and @code{DSV.SU.SE} only have direct cross
|
|
realm with @code{SU.SE} they need to use both @code{SU.SE} and
|
|
@code{KTH.SE} as transit realms.
|
|
|
|
@example
|
|
@cartouche
|
|
[capaths]
|
|
SU.SE = @{
|
|
STACKEN.KTH.SE = KTH.SE
|
|
@}
|
|
DSV.SU.SE = @{
|
|
STACKEN.KTH.SE = SU.SE KTH.SE
|
|
@}
|
|
|
|
@end cartouche
|
|
@end example
|
|
|
|
@c To test the cross realm configuration, use:
|
|
@c kmumble transit-check client server transit-realms ...
|
|
|
|
@node Setting up DNS, , Transit policy, Setting up a realm
|
|
@section Setting up DNS
|
|
@cindex Setting up DNS
|
|
|
|
If there is information about where to find the KDC or kadmind for a
|
|
realm in the @file{krb5.conf} for a realm, that information will be
|
|
preferred and DNS will not be queried.
|
|
|
|
Heimdal will try to use DNS to find the KDCs for a realm. First it
|
|
will try to find @code{SRV} resource record (RR) for the realm. If no
|
|
SRV RRs are found, it will fall back to looking for a @code{A} RR for
|
|
a machine named kerberos.REALM, and then kerberos-1.REALM, etc
|
|
|
|
Adding this information to DNS makes the client have less
|
|
configuration (in the common case, no configuration) and allows the
|
|
system administrator to change the number of KDCs and on what machines
|
|
they are running without caring about clients.
|
|
|
|
The backside of using DNS that the client might be fooled to use the
|
|
wrong server if someone fakes DNS replies/data, but storing the IP
|
|
addresses of the KDC on all the clients makes it very hard to change
|
|
the infrastructure.
|
|
|
|
Example of the configuration for the realm @code{EXAMPLE.COM},
|
|
|
|
@example
|
|
|
|
$ORIGIN example.com.
|
|
_kerberos._tcp SRV 10 1 88 kerberos.example.com.
|
|
_kerberos._udp SRV 10 1 88 kerberos.example.com.
|
|
_kerberos._tcp SRV 10 1 88 kerberos-1.example.com.
|
|
_kerberos._udp SRV 10 1 88 kerberos-1.example.com.
|
|
_kpasswd._udp SRV 10 1 464 kerberos.example.com.
|
|
_kerberos-adm._tcp SRV 10 1 749 kerberos.example.com.
|
|
|
|
@end example
|
|
|
|
More information about DNS SRV resource records can be found in
|
|
RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).
|
|
|