spelling and text fixes, from Dave Love
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14411 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
@@ -5,4 +5,18 @@ include $(top_srcdir)/Makefile.am.common
|
|||||||
AUTOMAKE_OPTIONS = no-texinfo.tex
|
AUTOMAKE_OPTIONS = no-texinfo.tex
|
||||||
|
|
||||||
info_TEXINFOS = heimdal.texi
|
info_TEXINFOS = heimdal.texi
|
||||||
heimdal_TEXINFOS = intro.texi install.texi setup.texi kerberos4.texi apps.texi
|
heimdal_TEXINFOS = \
|
||||||
|
ack.texi \
|
||||||
|
apps.texi \
|
||||||
|
heimdal.texi \
|
||||||
|
install.texi \
|
||||||
|
install.texi \
|
||||||
|
intro.texi \
|
||||||
|
kerberos4.texi \
|
||||||
|
migration.texi \
|
||||||
|
misc.texi \
|
||||||
|
programming.texi \
|
||||||
|
setup.texi \
|
||||||
|
setup.texi \
|
||||||
|
whatis.texi \
|
||||||
|
win2k.texi
|
||||||
|
218
doc/setup.texi
218
doc/setup.texi
@@ -42,9 +42,9 @@ There is a sample @file{krb5.conf} supplied with the distribution.
|
|||||||
The configuration file is a hierarchical structure consisting of
|
The configuration file is a hierarchical structure consisting of
|
||||||
sections, each containing a list of bindings (either variable
|
sections, each containing a list of bindings (either variable
|
||||||
assignments or subsections). A section starts with
|
assignments or subsections). A section starts with
|
||||||
@samp{[section-name]}. A binding consists of a left hand side, an equal
|
@samp{[@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
|
(@samp{=}) and a right hand side (the left hand side tag must be
|
||||||
separated from the equal with some whitespace.) Subsections has a
|
separated from the equal with some whitespace). Subsections has a
|
||||||
@samp{@{} as the first non-whitespace character after the equal. All
|
@samp{@{} as the first non-whitespace character after the equal. All
|
||||||
other bindings are treated as variable assignments. The value of a
|
other bindings are treated as variable assignments. The value of a
|
||||||
variable extends to the end of the line.
|
variable extends to the end of the line.
|
||||||
@@ -74,7 +74,7 @@ are briefly described here.
|
|||||||
The @samp{libdefaults} section contains a list of library configuration
|
The @samp{libdefaults} section contains a list of library configuration
|
||||||
parameters, such as the default realm and the timeout for KDC
|
parameters, such as the default realm and the timeout for KDC
|
||||||
responses. The @samp{realms} section contains information about specific
|
responses. The @samp{realms} section contains information about specific
|
||||||
realms, such as where they hide their KDC. This section serves the same
|
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
|
purpose as the Kerberos 4 @file{krb.conf} file, but can contain more
|
||||||
information. Finally the @samp{domain_realm} section contains a list of
|
information. Finally the @samp{domain_realm} section contains a list of
|
||||||
mappings from domains to realms, equivalent to the Kerberos 4
|
mappings from domains to realms, equivalent to the Kerberos 4
|
||||||
@@ -97,8 +97,8 @@ with contents similar to the following.
|
|||||||
@end example
|
@end example
|
||||||
|
|
||||||
If you use a realm name equal to your domain name, you can omit the
|
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
|
@samp{libdefaults}, and @samp{domain_realm}, sections. If you have a DNS
|
||||||
SRV-record for your realm, or your Kerberos server has CNAME called
|
SRV-record for your realm, or your Kerberos server has DNS CNAME
|
||||||
@samp{kerberos.my.realm}, you can omit the @samp{realms} section too.
|
@samp{kerberos.my.realm}, you can omit the @samp{realms} section too.
|
||||||
|
|
||||||
@node Creating the database, keytabs, Configuration file, Setting up a realm
|
@node Creating the database, keytabs, Configuration file, Setting up a realm
|
||||||
@@ -106,7 +106,7 @@ SRV-record for your realm, or your Kerberos server has CNAME called
|
|||||||
|
|
||||||
The database library will look for the database in the directory
|
The database library will look for the database in the directory
|
||||||
@file{/var/heimdal}, so you should probably create that directory.
|
@file{/var/heimdal}, so you should probably create that directory.
|
||||||
Make sure the directory have restrictive permissions.
|
Make sure the directory has restrictive permissions.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
# mkdir /var/heimdal
|
# mkdir /var/heimdal
|
||||||
@@ -126,23 +126,23 @@ Verifying password - Master key:
|
|||||||
|
|
||||||
If you want to generate a random master key you can use the
|
If you want to generate a random master key you can use the
|
||||||
--random-key to kstash. This will make sure you have a good key
|
--random-key to kstash. This will make sure you have a good key
|
||||||
attackers can't do a dictionary attack on the master key.
|
on which attackers can't do a dictionary attack.
|
||||||
|
|
||||||
If you have a master key, make sure you make a backup of your master
|
If you have a master key, make sure you make a backup of your master
|
||||||
key file, without it, backups of the database is of no use.
|
key file; without it backups of the database are of no use.
|
||||||
|
|
||||||
To initialise the database use the @code{kadmin} program, with the
|
To initialise the database use the @command{kadmin} program, with the
|
||||||
@samp{-l} option (to enable local database mode). First issue a
|
@samp{-l} option (to enable local database mode). First issue a
|
||||||
@kbd{init MY.REALM} command. This will create the database and insert
|
@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
|
default principals for that realm. You can have more than one realm in
|
||||||
one database, so @samp{init} does not destroy any old database.
|
one database, so @samp{init} does not destroy any old database.
|
||||||
|
|
||||||
Before creating the database, @samp{init} will ask you some questions
|
Before creating the database, @samp{init} will ask you some questions
|
||||||
about max ticket lifetimes.
|
about maximum ticket lifetimes.
|
||||||
|
|
||||||
After creating the database you should probably add yourself to it. You
|
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
|
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
|
principal. The principal should contain a realm, so if you haven't set up
|
||||||
a default realm, you will need to explicitly include the realm.
|
a default realm, you will need to explicitly include the realm.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -188,7 +188,7 @@ kadmin/changepw@@MY.REALM 1:0:1:f48c8af2b340e9fb:-:0:7:e3e6088 ...
|
|||||||
@node keytabs, Serving Kerberos 4/524/kaserver, Creating the database, Setting up a realm
|
@node keytabs, Serving Kerberos 4/524/kaserver, Creating the database, Setting up a realm
|
||||||
@section keytabs
|
@section keytabs
|
||||||
|
|
||||||
To extract a service ticket from the database and put it in a keytab you
|
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}
|
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
|
(using the @kbd{--random-key} flag to get a random key) and then
|
||||||
extract it with @samp{ext_keytab}.
|
extract it with @samp{ext_keytab}.
|
||||||
@@ -199,6 +199,7 @@ Max ticket life [unlimited]:
|
|||||||
Max renewable life [unlimited]:
|
Max renewable life [unlimited]:
|
||||||
Attributes []:
|
Attributes []:
|
||||||
kadmin> ext host/my.host.name
|
kadmin> ext host/my.host.name
|
||||||
|
kadmin> exit
|
||||||
# ktutil list
|
# ktutil list
|
||||||
Version Type Principal
|
Version Type Principal
|
||||||
1 des-cbc-md5 host/my.host.name@@MY.REALM
|
1 des-cbc-md5 host/my.host.name@@MY.REALM
|
||||||
@@ -211,8 +212,8 @@ Version Type Principal
|
|||||||
@section Serving Kerberos 4/524/kaserver
|
@section Serving Kerberos 4/524/kaserver
|
||||||
|
|
||||||
Heimdal can be configured to support 524, Kerberos 4 or kaserver. All
|
Heimdal can be configured to support 524, Kerberos 4 or kaserver. All
|
||||||
theses services are default turned off. Kerberos 4 support also
|
these services turned off by default. Kerberos 4 support also
|
||||||
depends on if Kerberos 4 support is compiled in with Heimdal.
|
depends on if Kerberos 4 support being compiled in with Heimdal.
|
||||||
|
|
||||||
@subsection 524
|
@subsection 524
|
||||||
|
|
||||||
@@ -229,8 +230,8 @@ tokens with AFS in @xref{Things in search for a better place}.
|
|||||||
|
|
||||||
@subsection Kerberos 4
|
@subsection Kerberos 4
|
||||||
|
|
||||||
Kerberos 4 is the predecessor to to Kerberos 5. It only support single
|
Kerberos 4 is the predecessor to to Kerberos 5. It only supports single
|
||||||
DES. You should only enable Kerberos 4 support if you have a need for
|
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.
|
for compatibility with an installed base of Kerberos 4 clients/servers.
|
||||||
|
|
||||||
Kerberos 4 can be turned on by adding this to the configuration file
|
Kerberos 4 can be turned on by adding this to the configuration file
|
||||||
@@ -242,11 +243,11 @@ Kerberos 4 can be turned on by adding this to the configuration file
|
|||||||
|
|
||||||
@subsection kaserver
|
@subsection kaserver
|
||||||
|
|
||||||
Kaserver is a Kerberos 4 that is used in AFS, the protocol have some
|
Kaserver is a Kerberos 4 that is used in AFS@. The protocol have some extra
|
||||||
features over plain Kerberos 4, but like Kerberos 4 only use single
|
features over plain Kerberos 4, but like Kerberos 4, only use single
|
||||||
DES too.
|
DES@.
|
||||||
|
|
||||||
You should only enable Kerberos 4 support if you have a need for for
|
You should only enable Kaserver support if you have a need for for
|
||||||
compatibility with an installed base of AFS machines.
|
compatibility with an installed base of AFS machines.
|
||||||
|
|
||||||
Kaserver can be turned on by adding this to the configuration file
|
Kaserver can be turned on by adding this to the configuration file
|
||||||
@@ -259,9 +260,9 @@ Kaserver can be turned on by adding this to the configuration file
|
|||||||
@node Remote administration, Password changing, Serving Kerberos 4/524/kaserver, Setting up a realm
|
@node Remote administration, Password changing, Serving Kerberos 4/524/kaserver, Setting up a realm
|
||||||
@section Remote administration
|
@section Remote administration
|
||||||
|
|
||||||
The administration server, @samp{kadmind}, can be started by
|
The administration server, @command{kadmind}, can be started by
|
||||||
@samp{inetd} (which isn't recommended) or run as a normal daemon. If you
|
@command{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
|
want to start it from @command{inetd} you should add a line similar to the
|
||||||
one below to your @file{/etc/inetd.conf}.
|
one below to your @file{/etc/inetd.conf}.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -269,28 +270,28 @@ kerberos-adm stream tcp nowait root /usr/heimdal/libexec/kadmind kadmin
|
|||||||
@end example
|
@end example
|
||||||
|
|
||||||
You might need to add @samp{kerberos-adm} to your @file{/etc/services}
|
You might need to add @samp{kerberos-adm} to your @file{/etc/services}
|
||||||
as 749/tcp.
|
as @samp{749/tcp}.
|
||||||
|
|
||||||
Access to the administration server is controlled by an acl-file, (default
|
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
|
@file{/var/heimdal/kadmind.acl}.) The lines in the access file, have the
|
||||||
following syntax:
|
following syntax:
|
||||||
@smallexample
|
@smallexample
|
||||||
principal [priv1,priv2,...] [glob-pattern]
|
principal [priv1,priv2,...] [glob-pattern]
|
||||||
@end smallexample
|
@end smallexample
|
||||||
|
|
||||||
The matching is from top to bottom for matching principal (and if given,
|
The matching is from top to bottom for matching principals (and if given,
|
||||||
glob-pattern). When there is a match, the rights of that lines are
|
glob-pattern). When there is a match, the access rights of that line are
|
||||||
used.
|
used.
|
||||||
|
|
||||||
The privileges you can assign to a principal are: @samp{add},
|
The privileges you can assign to a principal are: @samp{add},
|
||||||
@samp{change-password} (or @samp{cpw} for short), @samp{delete},
|
@samp{change-password} (or @samp{cpw} for short), @samp{delete},
|
||||||
@samp{get}, @samp{list}, and @samp{modify}, or the special privilege
|
@samp{get}, @samp{list}, and @samp{modify}, or the special privilege
|
||||||
@samp{all}. All of these roughly corresponds to the different commands
|
@samp{all}. All of these roughly corresponds to the different commands
|
||||||
in @samp{kadmin}.
|
in @command{kadmin}.
|
||||||
|
|
||||||
If a @var{glob-pattern} is given on a line, it restricts the right for
|
If a @var{glob-pattern} is given on a line, it restricts the access rights for
|
||||||
the principal to only apply for the subjects that match the pattern.
|
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
|
The patterns are of the same type as those used in shell globbing, see
|
||||||
@url{none,,fnmatch(3)}.
|
@url{none,,fnmatch(3)}.
|
||||||
|
|
||||||
In the example below @samp{lha/admin} can change every principal in the
|
In the example below @samp{lha/admin} can change every principal in the
|
||||||
@@ -310,20 +311,21 @@ mille/admin@@E.KTH.SE change-password *@@E.KTH.SE
|
|||||||
@node Password changing, Testing clients and servers, Remote administration, Setting up a realm
|
@node Password changing, Testing clients and servers, Remote administration, Setting up a realm
|
||||||
@section Password changing
|
@section Password changing
|
||||||
|
|
||||||
To allow users to change their passwords, you should run @samp{kpasswdd}.
|
To allow users to change their passwords, you should run @command{kpasswdd}.
|
||||||
It is not run from @samp{inetd}.
|
It is not run from @command{inetd}.
|
||||||
|
|
||||||
You might need to add @samp{kpasswd} to your @file{/etc/services} as
|
You might need to add @samp{kpasswd} to your @file{/etc/services} as
|
||||||
464/udp.
|
@samp{464/udp}.
|
||||||
|
|
||||||
@subsection Password quality assurance
|
@subsection Password quality assurance
|
||||||
|
|
||||||
It is important that users have good passwords, both to make it harder
|
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
|
to guess them and to avoid off-line attacks (although
|
||||||
|
pre-authentication provides
|
||||||
some defense against off-line attacks). To ensure that the users choose
|
some defense against off-line attacks). To ensure that the users choose
|
||||||
good passwords, you can enable password quality controls in
|
good passwords, you can enable password quality controls in
|
||||||
@samp{kpasswdd}. The controls themselves are done in a shared library
|
@command{kpasswdd}. The controls themselves are done in a shared library
|
||||||
that is used by @samp{kpasswdd}. To configure in these controls, add
|
that is used by @command{kpasswdd}. To configure in these controls, add
|
||||||
lines similar to the following to your @file{/etc/krb5.conf}:
|
lines similar to the following to your @file{/etc/krb5.conf}:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -341,7 +343,7 @@ function(krb5_context context, krb5_principal principal, krb5_data *pwd);
|
|||||||
@end example
|
@end example
|
||||||
|
|
||||||
The function should verify that @var{pwd} is a good password for
|
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
|
@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
|
low quality, it should return a string explaining why that password
|
||||||
should not be used.
|
should not be used.
|
||||||
|
|
||||||
@@ -352,7 +354,7 @@ the patch available at
|
|||||||
@url{ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch}.
|
@url{ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch}.
|
||||||
|
|
||||||
If no password quality checking function is configured, it is only
|
If no password quality checking function is configured, it is only
|
||||||
verified that it is at least six characters of length.
|
verified that it is at least six characters long.
|
||||||
|
|
||||||
@node Testing clients and servers, Slave Servers, Password changing, Setting up a realm
|
@node Testing clients and servers, Slave Servers, Password changing, Setting up a realm
|
||||||
@section Testing clients and servers
|
@section Testing clients and servers
|
||||||
@@ -367,21 +369,21 @@ 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
|
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.
|
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
|
All Kerberos servers for a realm must have the same database so that
|
||||||
they present the same service to all the users. The
|
they present the same service to all the users. The
|
||||||
@pindex hprop
|
@pindex hprop
|
||||||
@code{hprop} program, running on the master, will propagate the database
|
@command{hprop} program, running on the master, will propagate the database
|
||||||
to the slaves, running
|
to the slaves, running
|
||||||
@pindex hpropd
|
@pindex hpropd
|
||||||
@code{hpropd} processes.
|
@command{hpropd} processes.
|
||||||
|
|
||||||
Every slave needs a database directory, the master key (if it was used
|
Every slave needs a database directory, the master key (if it was used
|
||||||
for the database) and a keytab with the principal
|
for the database) and a keytab with the principal
|
||||||
@samp{hprop/@var{hostname}}. Add the principal with the
|
@samp{hprop/@var{hostname}}. Add the principal with the
|
||||||
@pindex ktutil
|
@pindex ktutil
|
||||||
@code{ktutil} command and start
|
@command{ktutil} command and start
|
||||||
@pindex hpropd
|
@pindex hpropd
|
||||||
@code{propd}, as follows:
|
@command{propd}, as follows:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
slave# ktutil get -p foo/admin hprop/`hostname`
|
slave# ktutil get -p foo/admin hprop/`hostname`
|
||||||
@@ -402,39 +404,40 @@ Then run
|
|||||||
master# hprop slave
|
master# hprop slave
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
This was just an on-hands example to make sure that everything was
|
This was just an hands-on example to make sure that everything was
|
||||||
working properly. Doing it manually is of course the wrong way and to
|
working properly. Doing it manually is of course the wrong way, and to
|
||||||
automate this you will want to start
|
automate this you will want to start
|
||||||
@pindex hpropd
|
@pindex hpropd
|
||||||
@code{hpropd} from @code{inetd} on the slave(s) and regularly run
|
@command{hpropd} from @command{inetd} on the slave(s) and regularly run
|
||||||
@pindex hprop
|
@pindex hprop
|
||||||
@code{hprop} on the master to regularly propagate the database.
|
@command{hprop} on the master to regularly propagate the database.
|
||||||
Starting the propagation once an hour from @code{cron} is probably a
|
Starting the propagation once an hour from @command{cron} is probably a
|
||||||
good idea.
|
good idea.
|
||||||
|
|
||||||
@node Incremental propagation, Salting , Slave Servers, Setting up a realm
|
@node Incremental propagation, Salting , Slave Servers, Setting up a realm
|
||||||
@section Incremental propagation
|
@section Incremental propagation
|
||||||
|
|
||||||
There is also a newer and still somewhat experimental mechanism for
|
There is also a newer, and still somewhat experimental, mechanism for
|
||||||
doing incremental propagation in Heimdal. Instead of sending the whole
|
doing incremental propagation in Heimdal. Instead of sending the whole
|
||||||
database regularly, it sends the changes as they happen on the master to
|
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
|
the slaves. The master keeps track of all the changes by assigning a
|
||||||
version number to every change to the database. The slaves know which
|
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
|
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
|
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
|
and when a slave is at an older version than the oldest one in the
|
||||||
log, the whole database has to be sent.
|
log, the whole database has to be sent.
|
||||||
|
|
||||||
Protocol-wise, all the slaves connects to the master and as a greeting
|
Protocol-wise, all the slaves connect to the master and as a greeting
|
||||||
tell it the latest version that they have (@samp{IHAVE} message). The
|
tell it the latest version that they have (@samp{IHAVE} message). The
|
||||||
master then responds by sending all the changes between that version and
|
master then responds by sending all the changes between that version and
|
||||||
the current version at the master (a series of @samp{FORYOU} messages)
|
the current version at the master (a series of @samp{FORYOU} messages)
|
||||||
or the whole database in a @samp{TELLYOUEVERYTHING} message.
|
or the whole database in a @samp{TELLYOUEVERYTHING} message. There is
|
||||||
|
also a keep alive protocol that make sure all slaves are upp and running.
|
||||||
|
|
||||||
@subsection Configuring incremental propagation
|
@subsection Configuring incremental propagation
|
||||||
|
|
||||||
The program that runs on the master is @code{ipropd-master} and all
|
The program that runs on the master is @command{ipropd-master} and all
|
||||||
clients run @code{ipropd-slave}.
|
clients run @command{ipropd-slave}.
|
||||||
|
|
||||||
Create the file @file{/var/heimdal/slaves} on the master containing all
|
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 slaves that the database should be propagated to. Each line contains
|
||||||
@@ -446,7 +449,7 @@ You should already have @samp{iprop/tcp} defined as 2121, in your
|
|||||||
for some peculiar reason, you can use the @kbd{--port} option. This is
|
for some peculiar reason, you can use the @kbd{--port} option. This is
|
||||||
useful when you have multiple realms to distribute from one server.
|
useful when you have multiple realms to distribute from one server.
|
||||||
|
|
||||||
Then you need to create these principals that you added in the
|
Then you need to create those principals that you added in the
|
||||||
configuration file. Create one @samp{iprop/hostname} for the master and
|
configuration file. Create one @samp{iprop/hostname} for the master and
|
||||||
for every slave.
|
for every slave.
|
||||||
|
|
||||||
@@ -455,13 +458,13 @@ for every slave.
|
|||||||
master# /usr/heimdal/sbin/ktutil get iprop/`hostname`
|
master# /usr/heimdal/sbin/ktutil get iprop/`hostname`
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
The next step is to start the @code{ipropd-master} process on the master
|
The next step is to start the @command{ipropd-master} process on the master
|
||||||
server. The @code{ipropd-master} listens on the UNIX-socket
|
server. The @command{ipropd-master} listens on the UNIX domain socket
|
||||||
@file{/var/heimdal/signal} to know when changes have been made to the
|
@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
|
database so they can be propagated to the slaves. There is also a
|
||||||
safety feature of testing the version number regularly (every 30
|
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
|
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:
|
this signal. Then, start @command{ipropd-slave} on all the slaves:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
master# /usr/heimdal/libexec/ipropd-master &
|
master# /usr/heimdal/libexec/ipropd-master &
|
||||||
@@ -476,7 +479,7 @@ Salting is used to make it harder to precalculate all possible
|
|||||||
keys. Using a salt increases the search space to make it almost
|
keys. Using a salt increases the search space to make it almost
|
||||||
impossible to precalculate all keys. Salting is the process of mixing a
|
impossible to precalculate all keys. Salting is the process of mixing a
|
||||||
public string (the salt) with the password, then sending it through an
|
public string (the salt) with the password, then sending it through an
|
||||||
encryption-type specific string-to-key function that will output the
|
encryption type specific string-to-key function that will output the
|
||||||
fixed size encryption key.
|
fixed size encryption key.
|
||||||
|
|
||||||
In Kerberos 5 the salt is determined by the encryption-type, except
|
In Kerberos 5 the salt is determined by the encryption-type, except
|
||||||
@@ -484,7 +487,7 @@ in some special cases.
|
|||||||
|
|
||||||
In @code{des} there is the Kerberos 4 salt
|
In @code{des} there is the Kerberos 4 salt
|
||||||
(none at all) or the afs-salt (using the cell (realm in
|
(none at all) or the afs-salt (using the cell (realm in
|
||||||
afs-lingo)).
|
AFS lingo)).
|
||||||
|
|
||||||
In @code{arcfour} (the encryption type that Microsoft Windows 2000 uses)
|
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
|
there is no salt. This is to be compatible with NTLM keys in Windows
|
||||||
@@ -500,23 +503,25 @@ 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 ""
|
salt (remember that if the salt is appended/prepended, the empty salt ""
|
||||||
is the same thing as no salt at all).
|
is the same thing as no salt at all).
|
||||||
|
|
||||||
Common types of salting includes
|
Common types of salting include
|
||||||
|
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
@item @code{v4} (or @code{des:pw-salt:})
|
@item @code{v4} (or @code{des:pw-salt:})
|
||||||
|
|
||||||
The Kerberos 4 salting is using no salt att all. Reason there is colon
|
The Kerberos 4 salting is using no salt at all. Reason there is colon
|
||||||
that the end or the salt string is that it makes the salt the empty
|
at the end of the salt string is that it makes the salt the empty
|
||||||
string (same as no salt).
|
string (same as no salt).
|
||||||
|
|
||||||
@item @code{v5} (or @code{pw-salt})
|
@item @code{v5} (or @code{pw-salt})
|
||||||
|
|
||||||
@code{pw-salt} means all regular encryption-types that is regular
|
@code{pw-salt} uses the default salt for each encryption type is
|
||||||
|
specified for. If the encryption type @samp{etype} isn't given, all
|
||||||
|
default encryption will be used.
|
||||||
|
|
||||||
@item @code{afs3-salt}
|
@item @code{afs3-salt}
|
||||||
|
|
||||||
@code{afs3-salt} is the salting that is used with Transarc kaserver. Its
|
@code{afs3-salt} is the salt that is used with Transarc kaserver. Its
|
||||||
the cell appended to the password.
|
the cell name appended to the password.
|
||||||
|
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
@@ -524,14 +529,14 @@ the cell appended to the password.
|
|||||||
@section Cross realm
|
@section Cross realm
|
||||||
@cindex Cross realm
|
@cindex Cross realm
|
||||||
|
|
||||||
Suppose you are residing in the realm @samp{MY.REALM}, how do you
|
Suppose you reside in the realm @samp{MY.REALM}, how do you
|
||||||
authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in
|
authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in
|
||||||
@samp{MY.REALM} allows you to communicate with kerberised services in that
|
@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
|
realm. However, the computer in the other realm does not have a secret
|
||||||
key shared with the Kerberos server in your realm.
|
key shared with the Kerberos server in your realm.
|
||||||
|
|
||||||
It is possible to add a share keys between two realms that trust each
|
It is possible to share keys between two realms that trust each
|
||||||
other. When a client program, such as @code{telnet} or @code{ssh},
|
other. When a client program, such as @command{telnet} or @command{ssh},
|
||||||
finds that the other computer is in a different realm, it will try to
|
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
|
get a ticket granting ticket for that other realm, but from the local
|
||||||
Kerberos server. With that ticket granting ticket, it will then obtain
|
Kerberos server. With that ticket granting ticket, it will then obtain
|
||||||
@@ -544,7 +549,7 @@ add the following principals to each realm. The principals should be
|
|||||||
@samp{krbtgt/MY.REALM@@OTHER.REALM} and
|
@samp{krbtgt/MY.REALM@@OTHER.REALM} and
|
||||||
@samp{krbtgt/OTHER.REALM@@MY.REALM}in @samp{OTHER.REALM}.
|
@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
|
In Kerberos 5 the trust can be configured to be one way. So that
|
||||||
users from @samp{MY.REALM} can authenticate to services in
|
users from @samp{MY.REALM} can authenticate to services in
|
||||||
@samp{OTHER.REALM}, but not the opposite. In the example above, the
|
@samp{OTHER.REALM}, but not the opposite. In the example above, the
|
||||||
@samp{krbtgt/MY.REALM@@OTHER.REALM} then should be removed.
|
@samp{krbtgt/MY.REALM@@OTHER.REALM} then should be removed.
|
||||||
@@ -590,13 +595,13 @@ May 3 14:10:54 May 3 23:55:54 host/hummel.it.su.se@@SU.SE
|
|||||||
@cindex Transit policy
|
@cindex Transit policy
|
||||||
|
|
||||||
If you want to use cross realm authentication through an intermediate
|
If you want to use cross realm authentication through an intermediate
|
||||||
realm it must be explicitly allowed by either the KDCs or the server
|
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
|
receiving the request. This is done in @file{krb5.conf} in the
|
||||||
@code{[capaths]} section.
|
@code{[capaths]} section.
|
||||||
|
|
||||||
When the ticket transits through a realm to another realm, the
|
When the ticket transits through a realm to another realm, the
|
||||||
destination realm adds its peer to the "transited-realms" field in 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
|
ticket. The field is unordered, since there is no way to know if
|
||||||
know if one of the transited-realms changed the order of the list.
|
know if one of the transited-realms changed the order of the list.
|
||||||
|
|
||||||
The syntax for @code{[capaths]} section:
|
The syntax for @code{[capaths]} section:
|
||||||
@@ -611,7 +616,7 @@ The syntax for @code{[capaths]} section:
|
|||||||
@end example
|
@end example
|
||||||
|
|
||||||
The realm @code{STACKEN.KTH.SE} allows clients from @code{SU.SE} and
|
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
|
@code{DSV.SU.SE} to cross it. Since @code{STACKEN.KTH.SE} only have
|
||||||
direct cross realm with @code{KTH.SE}, and @code{DSV.SU.SE} only have direct cross
|
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
|
realm with @code{SU.SE} they need to use both @code{SU.SE} and
|
||||||
@code{KTH.SE} as transit realms.
|
@code{KTH.SE} as transit realms.
|
||||||
@@ -632,8 +637,8 @@ realm with @code{SU.SE} they need to use both @code{SU.SE} and
|
|||||||
The order of the @code{PERMITTED-CROSS-REALMS} is not important when
|
The order of the @code{PERMITTED-CROSS-REALMS} is not important when
|
||||||
doing transit cross realm verification.
|
doing transit cross realm verification.
|
||||||
|
|
||||||
But the order is important when the @code{[capaths]} section is used
|
However the order is important when the @code{[capaths]} section is used
|
||||||
to figure out the intermediate realm to go to when doing multi realm
|
to figure out the intermediate realm to go to when doing multi-realm
|
||||||
transit. When figuring out the next realm, the first realm of the list
|
transit. When figuring out the next realm, the first realm of the list
|
||||||
of @code{PERMITTED-CROSS-REALMS} is chosen. This is done in both the
|
of @code{PERMITTED-CROSS-REALMS} is chosen. This is done in both the
|
||||||
client kerberos library and the KDC.
|
client kerberos library and the KDC.
|
||||||
@@ -649,11 +654,11 @@ client kerberos library and the KDC.
|
|||||||
|
|
||||||
If there is information about where to find the KDC or kadmind for a
|
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
|
realm in the @file{krb5.conf} for a realm, that information will be
|
||||||
preferred and DNS will not be queried.
|
preferred, and DNS will not be queried.
|
||||||
|
|
||||||
Heimdal will try to use DNS to find the KDCs for a realm. First it
|
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
|
will try to find a @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
|
SRV RRs are found, it will fall back to looking for an @code{A} RR for
|
||||||
a machine named kerberos.REALM, and then kerberos-1.REALM, etc
|
a machine named kerberos.REALM, and then kerberos-1.REALM, etc
|
||||||
|
|
||||||
Adding this information to DNS makes the client have less
|
Adding this information to DNS makes the client have less
|
||||||
@@ -661,12 +666,12 @@ configuration (in the common case, no configuration) and allows the
|
|||||||
system administrator to change the number of KDCs and on what machines
|
system administrator to change the number of KDCs and on what machines
|
||||||
they are running without caring about clients.
|
they are running without caring about clients.
|
||||||
|
|
||||||
The backside of using DNS that the client might be fooled to use the
|
The down side of using DNS that the client might be fooled to use the
|
||||||
wrong server if someone fakes DNS replies/data, but storing the IP
|
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
|
addresses of the KDC on all the clients makes it very hard to change
|
||||||
the infrastructure.
|
the infrastructure.
|
||||||
|
|
||||||
Example of the configuration for the realm @code{EXAMPLE.COM},
|
An example of the configuration for the realm @code{EXAMPLE.COM},
|
||||||
|
|
||||||
@example
|
@example
|
||||||
|
|
||||||
@@ -685,15 +690,15 @@ RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).
|
|||||||
|
|
||||||
@subsection Using DNS to map hostname to Kerberos realm
|
@subsection Using DNS to map hostname to Kerberos realm
|
||||||
|
|
||||||
Heimdal also support a way to lookup realm from a hostname. This to
|
Heimdal also supports a way to lookup a realm from a hostname. This to
|
||||||
minimize configuration needed on clients. Using this have the backdraw
|
minimize configuration needed on clients. Using this has the drawback
|
||||||
that clients can be redirect by an attacker to realms within the same
|
that clients can be redirected by an attacker to realms within the
|
||||||
cross realm trust and made belive they talk to the right server (since
|
same cross realm trust and made to believe they are talking to the
|
||||||
kerberos authentication will succeed).
|
right server (since Kerberos authentication will succeed).
|
||||||
|
|
||||||
Example configuration that informs clients that for the realms
|
An example configuration that informs clients that for the realms
|
||||||
it.example.com and srv.example.com, they should use the realm
|
it.example.com and srv.example.com, they should use the realm
|
||||||
EXAMPLE.COM.
|
EXAMPLE.COM:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
|
|
||||||
@@ -708,7 +713,7 @@ _kerberos.srv TXT "EXAMPLE.COM"
|
|||||||
@cindex Using the LDAP backend
|
@cindex Using the LDAP backend
|
||||||
|
|
||||||
This document describes how to install the LDAP backend for
|
This document describes how to install the LDAP backend for
|
||||||
Heimdal. Note that, before attempting to configure such an
|
Heimdal. Note that before attempting to configure such an
|
||||||
installation, you should be aware of the implications of storing
|
installation, you should be aware of the implications of storing
|
||||||
private information (such as users' keys) in a directory service
|
private information (such as users' keys) in a directory service
|
||||||
primarily designed for public information. Nonetheless, with a
|
primarily designed for public information. Nonetheless, with a
|
||||||
@@ -716,7 +721,7 @@ suitable authorization policy, it is possible to set this up in a
|
|||||||
secure fashion. A knowledge of LDAP, Kerberos, and C is necessary to
|
secure fashion. A knowledge of LDAP, Kerberos, and C is necessary to
|
||||||
install this backend. The HDB schema was devised by Leif Johansson.
|
install this backend. The HDB schema was devised by Leif Johansson.
|
||||||
|
|
||||||
Requirements
|
Requirements:
|
||||||
|
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
|
|
||||||
@@ -725,14 +730,15 @@ A current release of Heimdal, configured with
|
|||||||
@code{--with-openldap=/usr/local} (adjust according to where you have
|
@code{--with-openldap=/usr/local} (adjust according to where you have
|
||||||
installed OpenLDAP).
|
installed OpenLDAP).
|
||||||
|
|
||||||
You can verify that you manage to configure ldap support by running
|
You can verify that you manage to configure LDAP support by running
|
||||||
@file{kdc --builtin-hdb}, ``ldap:'' as one entry in the list.
|
@file{kdc --builtin-hdb}, and checking that @samp{ldap:} is one entry
|
||||||
|
in the list.
|
||||||
|
|
||||||
Its also possible to configure the ldap backend as a shared module,
|
Its also possible to configure the ldap backend as a shared module,
|
||||||
see option --hdb-openldap-module to configure.
|
see option --hdb-openldap-module to configure.
|
||||||
|
|
||||||
@item
|
@item
|
||||||
OpenLDAP 2.0.x. Configure OpenLDAP with --enable-local to enable the
|
OpenLDAP 2.0.x. Configure OpenLDAP with @kbd{--enable-local} to enable the
|
||||||
local transport. (A patch to support SASL EXTERNAL authentication is
|
local transport. (A patch to support SASL EXTERNAL authentication is
|
||||||
necessary in order to use OpenLDAP 2.1.x.)
|
necessary in order to use OpenLDAP 2.1.x.)
|
||||||
|
|
||||||
@@ -755,14 +761,14 @@ sasl-regexp "uidNumber=0\\\+gidNumber=.*,cn=peercred,cn=external,cn=auth"
|
|||||||
The sasl-regexp is for mapping between the SASL/EXTERNAL and a user in
|
The sasl-regexp is for mapping between the SASL/EXTERNAL and a user in
|
||||||
a tree. The user that the key is mapped to should be have a
|
a tree. The user that the key is mapped to should be have a
|
||||||
krb5Principal aux object with krb5PrincipalName set so that the
|
krb5Principal aux object with krb5PrincipalName set so that the
|
||||||
``creator'' and ``modifier'' gets right in @file{kadmin}.
|
``creator'' and ``modifier'' is right in @file{kadmin}.
|
||||||
|
|
||||||
Another option is to create an admins group and add the dn to that
|
Another option is to create an admins group and add the dn to that
|
||||||
group.
|
group.
|
||||||
|
|
||||||
You also needs to make sure its possible for the KDC to connect
|
You also needs to make sure it is possible for the KDC to connect
|
||||||
without encryption, the connection is already secure, its done over a
|
without encryption, the connection is already secure---its done over a
|
||||||
local unix socket. Comment out ``sasl-secprops minssf'' in the
|
UNIX domain socket. Comment out ``sasl-secprops minssf'' in the
|
||||||
configuration file.
|
configuration file.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -777,19 +783,19 @@ Make sure you include the schema:
|
|||||||
include /usr/local/etc/openldap/schema/hdb.schema
|
include /usr/local/etc/openldap/schema/hdb.schema
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
Start the slapd with the local listener (as well as the default TCP/IP
|
Start @command{slapd} with the local listener (as well as the default TCP/IP
|
||||||
listener on port 389) as follows:
|
listener on port 389) as follows:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
slapd -h "ldapi:/// ldap:///"
|
slapd -h "ldapi:/// ldap:///"
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
Note: These is a bug in slapd where it appears to corrupt the krb5Key
|
Note: These is a bug in @command{slapd} where it appears to corrupt the krb5Key
|
||||||
binary attribute on shutdown. This may be related to our use of the V3
|
binary attribute on shutdown. This may be related to our use of the V3
|
||||||
schema definition syntax instead of the old UMich-style, V2 syntax.
|
schema definition syntax instead of the old UMich-style, V2 syntax.
|
||||||
|
|
||||||
@item
|
@item
|
||||||
You should specify a the distinguished name under which your
|
You should specify the distinguished name under which your
|
||||||
principals will be stored in @file{krb5.conf}:
|
principals will be stored in @file{krb5.conf}:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -800,7 +806,7 @@ principals will be stored in @file{krb5.conf}:
|
|||||||
@}
|
@}
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
mkey_file can be excluded if you feel that you trust your ldap
|
@samp{mkey_file} can be excluded if you feel that you trust your ldap
|
||||||
directory to have the raw keys inside it.
|
directory to have the raw keys inside it.
|
||||||
|
|
||||||
|
|
||||||
@@ -825,7 +831,7 @@ Verifying password - lukeh@@PADL.COM's Password:
|
|||||||
kadmin> exit
|
kadmin> exit
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
Verify that the principal database has indeed been stored at the
|
Verify that the principal database has indeed been stored in the
|
||||||
directory with the following command:
|
directory with the following command:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -850,7 +856,7 @@ Now consider adding indexes to the database to speed up the access.
|
|||||||
|
|
||||||
Write text here.
|
Write text here.
|
||||||
|
|
||||||
Note that the samba domain and the realm realm can have diffrent names
|
Note that the Samba domain and the Kerberos realm can have diffrent names
|
||||||
since arcfour's string to key function principal/realm independent.
|
since arcfour's string to key function principal/realm independent.
|
||||||
|
|
||||||
|
|
||||||
|
147
doc/win2k.texi
147
doc/win2k.texi
@@ -10,12 +10,13 @@ peculiarities, and bugs. This chapter is a short summary of the things
|
|||||||
that we have found out while trying to test Heimdal against Windows
|
that we have found out while trying to test Heimdal against Windows
|
||||||
2000. Another big problem with the Kerberos implementation in Windows
|
2000. Another big problem with the Kerberos implementation in Windows
|
||||||
2000 is that the available documentation is more focused on getting
|
2000 is that the available documentation is more focused on getting
|
||||||
things to work rather than how they work and not that useful in figuring
|
things to work rather than how they work, and not that useful in figuring
|
||||||
out how things really work.
|
out how things really work.
|
||||||
|
|
||||||
This information should apply to Heimdal @value{VERSION} and Windows
|
This information should apply to Heimdal @value{VERSION} and Windows
|
||||||
2000 Professional. It's of course subject all the time and mostly consists of
|
2000 Professional. It's of course subject to change all the time and
|
||||||
our not so inspired guesses. Hopefully it's still somewhat useful.
|
mostly consists of our not so inspired guesses. Hopefully it's still
|
||||||
|
somewhat useful.
|
||||||
|
|
||||||
@menu
|
@menu
|
||||||
* Configuring Windows 2000 to use a Heimdal KDC::
|
* Configuring Windows 2000 to use a Heimdal KDC::
|
||||||
@@ -31,15 +32,15 @@ our not so inspired guesses. Hopefully it's still somewhat useful.
|
|||||||
@comment node-name, next, precious, up
|
@comment node-name, next, precious, up
|
||||||
@section Configuring Windows 2000 to use a Heimdal KDC
|
@section Configuring Windows 2000 to use a Heimdal KDC
|
||||||
|
|
||||||
You need the command line program called @code{ksetup.exe} which is available
|
You need the command line program called @command{ksetup.exe} which is available
|
||||||
in the file @code{SUPPORT/TOOLS/SUPPORT.CAB} on the Windows 2000 Professional
|
in the file @file{SUPPORT/TOOLS/SUPPORT.CAB} on the Windows 2000 Professional
|
||||||
CD-ROM. This program is used to configure the Kerberos settings on a
|
CD-ROM. This program is used to configure the Kerberos settings on a
|
||||||
Workstation.
|
Workstation.
|
||||||
|
|
||||||
@code{Ksetup} store the domain information under the registry key:
|
@command{Ksetup} store the domain information under the registry key:
|
||||||
@code{HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains}.
|
@code{HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains}.
|
||||||
|
|
||||||
Use the kadmin program in Heimdal to create a host principal in the
|
Use the @command{kadmin} program in Heimdal to create a host principal in the
|
||||||
Kerberos realm.
|
Kerberos realm.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -47,7 +48,7 @@ unix% kadmin
|
|||||||
kadmin> ank --password=password host/datan.example.com
|
kadmin> ank --password=password host/datan.example.com
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
The name @code{datan.example.com} should be replaced with DNS name of
|
The name @samp{datan.example.com} should be replaced with DNS name of
|
||||||
the workstation.
|
the workstation.
|
||||||
|
|
||||||
You must configure the workstation as a member of a workgroup, as opposed
|
You must configure the workstation as a member of a workgroup, as opposed
|
||||||
@@ -58,26 +59,26 @@ C:> ksetup /setdomain EXAMPLE.COM
|
|||||||
C:> ksetup /addkdc EXAMPLE.COM kdc.example.com
|
C:> ksetup /addkdc EXAMPLE.COM kdc.example.com
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
Set the machine password, i.e. create the local keytab:
|
Set the machine password, i.e.@: create the local keytab:
|
||||||
@example
|
@example
|
||||||
C:> ksetup /setmachpassword password
|
C:> ksetup /setmachpassword password
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
The password used in @code{ksetup /setmachpassword} must be the same
|
The password used in @kdb{ksetup /setmachpassword} must be the same
|
||||||
as the password used in the @code{kadmin ank} command.
|
as the password used in the @kdb{kadmin ank} command.
|
||||||
|
|
||||||
The workstation must now be rebooted.
|
The workstation must now be rebooted.
|
||||||
|
|
||||||
A mapping between local NT users and Kerberos principals must be specified,
|
A mapping between local NT users and Kerberos principals must be specified.
|
||||||
you have two choices:
|
You have two choices. First:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
C:> ksetup /mapuser user@@MY.REALM nt_user
|
C:> ksetup /mapuser user@@MY.REALM nt_user
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
This will map a user to a specific principal, this allows you to have
|
This will map a user to a specific principal; this allows you to have
|
||||||
other usernames in the realm than in your NT user database. (Don't ask
|
other usernames in the realm than in your NT user database. (Don't ask
|
||||||
me why on earth you would want that...)
|
me why on earth you would want that@enddots{})
|
||||||
|
|
||||||
You can also say:
|
You can also say:
|
||||||
@example
|
@example
|
||||||
@@ -98,18 +99,18 @@ Server) for the domain.
|
|||||||
|
|
||||||
By default the trust will be non-transitive. This means that only users
|
By default the trust will be non-transitive. This means that only users
|
||||||
directly from the trusted domain may authenticate. This can be changed
|
directly from the trusted domain may authenticate. This can be changed
|
||||||
to transitive by using the @code{netdom.exe} tool. @code{netdom.exe}
|
to transitive by using the @command{netdom.exe} tool. @command{netdom.exe}
|
||||||
can also be used to add the trust between two realms.
|
can also be used to add the trust between two realms.
|
||||||
|
|
||||||
You need to tell Windows 2000 on what hosts to find the KDCs for the
|
You need to tell Windows 2000 on what hosts to find the KDCs for the
|
||||||
non-Windows realm with @code{ksetup}, see @xref{Configuring Windows 2000
|
non-Windows realm with @command{ksetup}, see @xref{Configuring Windows 2000
|
||||||
to use a Heimdal KDC}.
|
to use a Heimdal KDC}.
|
||||||
|
|
||||||
This need to be done on all computers that want enable cross-realm
|
This needs to be done on all computers that want enable cross-realm
|
||||||
login with @code{Mapped Names}.
|
login with @code{Mapped Names}. @c XXX probably shouldn't be @code
|
||||||
|
|
||||||
Then you need to add the inter-realm keys on the Windows kdc. Start the
|
Then you need to add the inter-realm keys on the Windows KDC@. Start the
|
||||||
Domain Tree Management tool. (Found in Programs, Administrative tools,
|
Domain Tree Management tool (found in Programs, Administrative tools,
|
||||||
Active Directory Domains and Trusts).
|
Active Directory Domains and Trusts).
|
||||||
|
|
||||||
Right click on Properties of your domain, select the Trust tab. Press
|
Right click on Properties of your domain, select the Trust tab. Press
|
||||||
@@ -117,10 +118,10 @@ Add on the appropriate trust windows and enter domain name and
|
|||||||
password. When prompted if this is a non-Windows Kerberos realm, press
|
password. When prompted if this is a non-Windows Kerberos realm, press
|
||||||
OK.
|
OK.
|
||||||
|
|
||||||
Do not forget to add trusts in both directions.
|
Do not forget to add trusts in both directions (if that's what you want).
|
||||||
|
|
||||||
If you want to use @code{netdom.exe} instead of the Domain Tree
|
If you want to use @command{netdom.exe} instead of the Domain Tree
|
||||||
Management tool, you do it like this,
|
Management tool, you do it like this:
|
||||||
|
|
||||||
@example
|
@example
|
||||||
netdom trust NT.REALM.EXAMPLE.COM /Domain:EXAMPLE.COM /add /realm /passwordt:TrustPassword
|
netdom trust NT.REALM.EXAMPLE.COM /Domain:EXAMPLE.COM /add /realm /passwordt:TrustPassword
|
||||||
@@ -131,12 +132,12 @@ some tweaks that you need to do to @file{krb5.conf} beforehand.
|
|||||||
|
|
||||||
@example
|
@example
|
||||||
[libdefaults]
|
[libdefaults]
|
||||||
default_etypes = des-cbc-crc
|
default_etypes = des-cbc-crc
|
||||||
default_etypes_des = des-cbc-crc
|
default_etypes_des = des-cbc-crc
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
since otherwise checksum types that are not understood by Windows 2000
|
since otherwise checksum types that are not understood by Windows 2000
|
||||||
will be generated (@xref{Quirks of Windows 2000 KDC}.).
|
will be generated (@pxref{Quirks of Windows 2000 KDC}).
|
||||||
|
|
||||||
Another issue is salting. Since Windows 2000 does not seem to
|
Another issue is salting. Since Windows 2000 does not seem to
|
||||||
understand Kerberos 4 salted hashes you might need to turn off anything
|
understand Kerberos 4 salted hashes you might need to turn off anything
|
||||||
@@ -144,10 +145,22 @@ similar to the following if you have it, at least while adding the
|
|||||||
principals that are going to share keys with Windows 2000.
|
principals that are going to share keys with Windows 2000.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
[kadmin]default_keys = v5 v4
|
[kadmin]
|
||||||
|
default_keys = v5 v4
|
||||||
@end example
|
@end example
|
||||||
|
|
||||||
You must also set:
|
So remove v4 from default keys.
|
||||||
|
|
||||||
|
What you probably want to use is this:
|
||||||
|
|
||||||
|
@example
|
||||||
|
[kadmin]
|
||||||
|
default_keys = des-cbc-crc:pw-salt arcfour-hmac-md5:pw-salt
|
||||||
|
@end example
|
||||||
|
|
||||||
|
@c XXX check this
|
||||||
|
Note that before Windows 2003, arcfour-hmac-md5 wasn't supported
|
||||||
|
beteen Windows realms and Non Windows realms.
|
||||||
|
|
||||||
Once that is also done, you can add the required inter-realm keys:
|
Once that is also done, you can add the required inter-realm keys:
|
||||||
|
|
||||||
@@ -158,9 +171,9 @@ kadmin add krbtgt/REALM.EXAMPLE.COM@@NT.EXAMPLE.COM
|
|||||||
|
|
||||||
Use the same passwords for both keys.
|
Use the same passwords for both keys.
|
||||||
|
|
||||||
Do not forget to reboot before trying the new realm-trust (after running
|
Do not forget to reboot before trying the new realm-trust (after
|
||||||
@code{ksetup}). It looks like it might work, but packets are never sent to the
|
running @command{ksetup}). It looks like it might work, but packets are
|
||||||
non-Windows KDC.
|
never sent to the non-Windows KDC.
|
||||||
|
|
||||||
@node Create account mappings, Encryption types, Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Windows 2000 compatability
|
@node Create account mappings, Encryption types, Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Windows 2000 compatability
|
||||||
@comment node-name, next, precious, up
|
@comment node-name, next, precious, up
|
||||||
@@ -174,21 +187,23 @@ are going to do a name mapping for and choose Name mapping.
|
|||||||
Click on the Kerberos Names tab and add a new principal from the
|
Click on the Kerberos Names tab and add a new principal from the
|
||||||
non-Windows domain.
|
non-Windows domain.
|
||||||
|
|
||||||
|
@c XXX check entry name then I have network again
|
||||||
|
This adds @samp{authorizationNames} entry to the users LDAP entry to
|
||||||
|
the Active Directory LDAP catalog. When you create users by script you
|
||||||
|
can add this entry instead.
|
||||||
|
|
||||||
@node Encryption types, Authorization data, Create account mappings, Windows 2000 compatability
|
@node Encryption types, Authorization data, Create account mappings, Windows 2000 compatability
|
||||||
@comment node-name, next, previous, up
|
@comment node-name, next, previous, up
|
||||||
@section Encryption types
|
@section Encryption types
|
||||||
|
|
||||||
Windows 2000 supports both the standard DES encryptions (des-cbc-crc and
|
Windows 2000 supports both the standard DES encryptions (@samp{des-cbc-crc} and
|
||||||
des-cbc-md5) and its own proprietary encryption that is based on MD4 and
|
@samp{des-cbc-md5}) and its own proprietary encryption that is based on MD4 and
|
||||||
rc4 that is documented in and is supposed to be described in
|
RC4 that is documented in and is supposed to be described in
|
||||||
@file{draft-brezak-win2k-krb-rc4-hmac-03.txt}. New users will get both
|
@file{draft-brezak-win2k-krb-rc4-hmac-03.txt}. New users will get both
|
||||||
MD4 and DES keys. Users that are converted from a NT4 database, will
|
MD4 and DES keys. Users that are converted from a NT4 database, will
|
||||||
only have MD4 passwords and will need a password change to get a DES
|
only have MD4 passwords and will need a password change to get a DES
|
||||||
key.
|
key.
|
||||||
|
|
||||||
Heimdal implements both of these encryption types, but since DES is the
|
|
||||||
standard and the hmac-code is somewhat newer, it is likely to work better.
|
|
||||||
|
|
||||||
@node Authorization data, Quirks of Windows 2000 KDC, Encryption types, Windows 2000 compatability
|
@node Authorization data, Quirks of Windows 2000 KDC, Encryption types, Windows 2000 compatability
|
||||||
@comment node-name, next, previous, up
|
@comment node-name, next, previous, up
|
||||||
@section Authorization data
|
@section Authorization data
|
||||||
@@ -210,7 +225,7 @@ database. Make sure it has a DES key.
|
|||||||
@item Run @kbd{ktutil add} to add the key for that principal to a
|
@item Run @kbd{ktutil add} to add the key for that principal to a
|
||||||
keytab.
|
keytab.
|
||||||
@item Run @kbd{appl/test/nt_gss_server -p 2000 -s authsamp
|
@item Run @kbd{appl/test/nt_gss_server -p 2000 -s authsamp
|
||||||
--dump-auth=file} where file is an appropriate file.
|
--dump-auth=@var{file}} where @var{file} is an appropriate file.
|
||||||
@item It should authenticate and dump for you the authorization data in
|
@item It should authenticate and dump for you the authorization data in
|
||||||
the file.
|
the file.
|
||||||
@item The tool @kbd{lib/asn1/asn1_print} is somewhat useful for
|
@item The tool @kbd{lib/asn1/asn1_print} is somewhat useful for
|
||||||
@@ -221,18 +236,17 @@ analyzing the data.
|
|||||||
@comment node-name, next, previous, up
|
@comment node-name, next, previous, up
|
||||||
@section Quirks of Windows 2000 KDC
|
@section Quirks of Windows 2000 KDC
|
||||||
|
|
||||||
There are some issues with salts and Windows 2000. Using an empty salt,
|
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
|
||||||
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
|
||||||
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
|
||||||
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
|
sure you keep around keys with all the different types of salts that are
|
||||||
required.
|
required. Microsoft have fixed this issue post Windows 2003.
|
||||||
|
|
||||||
Microsoft seems also to have forgotten to implement the checksum
|
Microsoft seems also to have forgotten to implement the checksum
|
||||||
algorithms @samp{rsa-md4-des} and @samp{rsa-md5-des}. This can make Name
|
algorithms @samp{rsa-md4-des} and @samp{rsa-md5-des}. This can make Name
|
||||||
mapping (@pxref{Create account mappings}) fail if a @code{des-cbc-md5} key
|
mapping (@pxref{Create account mappings}) fail if a @samp{des-cbc-md5} key
|
||||||
is used. To make the KDC return only @code{des-cbc-crc} you must delete
|
is used. To make the KDC return only @samp{des-cbc-crc} you must delete
|
||||||
the @code{des-cbc-md5} key from the kdc using the @code{kadmin
|
the @samp{des-cbc-md5} key from the kdc using the @kdb{kadmin
|
||||||
del_enctype} command.
|
del_enctype} command.
|
||||||
|
|
||||||
@example
|
@example
|
||||||
@@ -256,41 +270,41 @@ unsupported types are generated.
|
|||||||
|
|
||||||
See also our paper presented at the 2001 usenix Annual Technical
|
See also our paper presented at the 2001 usenix Annual Technical
|
||||||
Conference, available in the proceedings or at
|
Conference, available in the proceedings or at
|
||||||
@url{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/westerlund.html}.
|
@uref{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/westerlund.html}.
|
||||||
|
|
||||||
There are lots of text about Kerberos on Microsoft's web site, here is a
|
There are lots of texts about Kerberos on Microsoft's web site, here is a
|
||||||
short list of the interesting documents that we have managed to find.
|
short list of the interesting documents that we have managed to find.
|
||||||
|
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
|
|
||||||
@item Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability -
|
@item Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability:
|
||||||
@url{http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp}
|
@uref{http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp}.
|
||||||
Kerberos GSS-API (in Windows-ize SSPI), Windows as a client in a
|
Kerberos GSS-API (in Windows-eze SSPI), Windows as a client in a
|
||||||
non-Windows KDC realm, adding unix clients to a Windows 2000 KDC, and
|
non-Windows KDC realm, adding unix clients to a Windows 2000 KDC, and
|
||||||
adding cross-realm trust (@xref{Inter-Realm keys (trust) between Windows 2000
|
adding cross-realm trust (@pxref{Inter-Realm keys (trust) between Windows 2000
|
||||||
and a Heimdal KDC}.).
|
and a Heimdal KDC}).
|
||||||
|
|
||||||
@item Windows 2000 Kerberos Authentication -
|
@item Windows 2000 Kerberos Authentication:
|
||||||
@url{http://www.microsoft.com/TechNet/win2000/win2ksrv/technote/kerberos.asp}
|
@uref{http://www.microsoft.com/TechNet/win2000/win2ksrv/technote/kerberos.asp}.
|
||||||
White paper that describes how Kerberos is used in Windows 2000.
|
White paper that describes how Kerberos is used in Windows 2000.
|
||||||
|
|
||||||
@item Overview of kerberos -
|
@item Overview of Kerberos:
|
||||||
@url{http://support.microsoft.com/support/kb/articles/Q248/7/58.ASP}
|
@uref{http://support.microsoft.com/support/kb/articles/Q248/7/58.ASP}.
|
||||||
Links to useful other links.
|
Links to useful other links.
|
||||||
|
|
||||||
@item Klist for windows -
|
@c @item Klist for Windows:
|
||||||
@url{http://msdn.microsoft.com/library/periodic/period00/security0500.htm}
|
@c @uref{http://msdn.microsoft.com/library/periodic/period00/security0500.htm}.
|
||||||
Describes where to get a klist for Windows 2000.
|
@c Describes where to get a klist for Windows 2000.
|
||||||
|
|
||||||
@item Event logging for kerberos -
|
@item Event logging for Kerberos:
|
||||||
@url{http://support.microsoft.com/support/kb/articles/Q262/1/77.ASP}.
|
@uref{http://support.microsoft.com/support/kb/articles/Q262/1/77.ASP}.
|
||||||
Basicly it say that you can add a registry key
|
Basicly it say that you can add a registry key
|
||||||
@code{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel}
|
@code{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel}
|
||||||
with value DWORD equal to 1, and then you'll get logging in the Event
|
with value DWORD equal to 1, and then you'll get logging in the Event
|
||||||
Logger.
|
Logger.
|
||||||
|
|
||||||
@item Access to the active directory through LDAP
|
@c @item Access to the Active Directory through LDAP:
|
||||||
@url{http://msdn.microsoft.com/library/techart/kerberossamp.htm}
|
@c @uref{http://msdn.microsoft.com/library/techart/kerberossamp.htm}
|
||||||
|
|
||||||
@end itemize
|
@end itemize
|
||||||
|
|
||||||
@@ -298,5 +312,4 @@ Other useful programs include these:
|
|||||||
|
|
||||||
@itemize @bullet
|
@itemize @bullet
|
||||||
@item pwdump2
|
@item pwdump2
|
||||||
@url{http://www.webspan.net/~tas/pwdump2/}
|
@uref{http://www.bindview.com/Support/RAZOR/Utilities/Windows/pwdump2_readme.cfm}@end itemize
|
||||||
@end itemize
|
|
||||||
|
Reference in New Issue
Block a user