summaryrefslogtreecommitdiff
path: root/kerberosIV/doc/setup.texi
blob: a1bd339c4fdf99e700d43b577048b4bea1279e84 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
@node How to set up a realm, One-Time Passwords, What is Kerberos?, Top
@chapter How to set up a realm

@quotation
@flushleft
	Who willed you? or whose will stands but mine?
	There's none protector of the realm but I.
	Break up the gates, I'll be your warrantize.
	Shall I be flouted thus by dunghill grooms?
        --- King Henry VI, 6.1
@end flushleft
@end quotation

@menu
* How to set up the kerberos server::  
* Install the client programs::  
* Install the kerberised services::  
* Install a slave kerberos server::  
* Cross-realm functionality ::  
@end menu

@node How to set up the kerberos server, Install the client programs, How to set up a realm, How to set up a realm
@section How to set up the kerberos server

@menu
* Choose a realm name::         
* Choose a kerberos server::    
* Install the configuration files:: 
* Install the /etc/services::  
* Install the kerberos server::  
* Set up the server::           
* Add a few important principals::  
* Start the server::            
* Try to get tickets::          
* Create initial ACL for the admin server::  
* Start the admin server::      
* Add users to the database::   
* Automate the startup of the servers::  
@end menu

@node Choose a realm name, Choose a kerberos server, How to set up the kerberos server, How to set up the kerberos server
@subsection Choose a realm name

A 
@cindex realm
realm is an administrative domain.  Kerberos realms are usually
written in uppercase and consist of a Internet domain
name@footnote{Using lowercase characters in the realm name might break
in mysterious ways. This really should have been fixed, but has not.}.
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 Choose a kerberos server, Install the configuration files, Choose a realm name, How to set up the kerberos server
@subsection Choose a kerberos server

You need to choose a machine to run the 
@pindex kerberos
kerberos server program.  If the kerberos database residing on this host
is compromised, your entire realm will be compromised.  Therefore, this
machine must be as secure as possible.  Preferably it should not run any
services other than Kerberos.  The secure-minded administrator might
only allow logins on the console.

This machine has also to be reliable.  If it is down, you will not be
able to use any kerberised services unless you have also configured a
slave server (@xref{Install a slave kerberos server}).

Running the kerberos server requires very little CPU power and a small
amount of disk. An old PC with some hundreds of megabytes of free disk
space should do fine. Most of the disk space will be used for various
logs.

@node Install the configuration files, Install the /etc/services, Choose a kerberos server, How to set up the kerberos server
@subsection Install the configuration files

There are two important configuration files: @file{/etc/kerberosIV/krb.conf} and
@file{/etc/kerberosIV/krb.realms}.
@pindex krb.conf
@pindex krb.realms

The @file{krb.conf} file determines which machines are servers for
different realms.  The format of this file is:

@example
THIS.REALM
THIS.REALM              kerberos.this.realm admin server
THIS.REALM              kerberos-1.this.realm
ANOTHER.REALM           kerberos.another.realm
@end example

The first line defines the name of the local realm. Line two defines the
name of the master kerberos server and the database administration
server for this realm.  You can define any number of kerberos slave
servers similar to the one defined in line three.  The clients will try
to contact the servers in the order they are defined in @file{krb.conf}.

To disable kerberos on your system place a '#'-sign as the first character
on the first line in @file{/etc/kerberosIV/krb.conf}. This will disable any
kerberos authentication on your system.

The @samp{admin server} clause at the first entry states that this is
the master server
@cindex master server
(the one to contact when modifying the database, such as changing
passwords). There should be only one such entry for each realm.

In the original MIT Kerberos 4 (as in most others), the server
specification could only take the form of a host-name. To facilitate
having kerberos servers in odd places (such as behind a firewall),
support has been added for ports other than the default (750), and
protocols other than UDP.

The formal syntax for an entry is now
@samp{@var{[proto}/@var{]host[}:@var{port]}}. @var{proto} is either
@samp{udp} or @samp{tcp}, and @var{port} is the port to talk to. Default
value for @var{proto} is @samp{udp} and for @var{port} whatever
@samp{kerberos-iv} is defined to be in @file{/etc/services} or 750 if
undefined.

You can also talk HTTP with your KDC, in that case you specify an URL,
like @samp{http://@var{host[}:@var{port]}}. If you for some reason need
to use a HTTP proxy, you can specify the proxy in the @samp{krb4_proxy}
environment variable, also in URL format. The default for port in this
case is 80.

If the information about a realm is missing from the @file{krb.conf}
file, or if the information is wrong, the following methods will be
tried in order.

@enumerate
@item
If you have an SRV-record (@cite{RFC 2052}) for your realm it will be
used. This record should be of the form
@samp{kerberos-iv.@var{protocol}.@var{REALM}}, where @var{proto} is
either @samp{udp} or @samp{tcp}. (Note: the current implementation does
not look at priority or weight when deciding which server to talk to.)
@item
If there isn't any SRV-record, it tries to find a TXT-record for the
same domain. The contents of the record should have the same format as the
host specification in @file{krb.conf}. (Note: this is a temporary
solution if your name server doesn't support SRV records. The clients
should work fine with SRV records, so if your name server supports them,
they are very much preferred.)
@item
If no valid kerberos server is found, it will try to talk udp to the
service @samp{kerberos-iv} with fall-back to port 750 with
@samp{kerberos.@var{REALM}} (which is also assumed to be the master
server), and then @samp{kerberos-1.@var{REALM}},
@samp{kerberos-2.@var{REALM}}, and so on.
@end enumerate

We strongly recommend that you add a CNAME @samp{kerberos.@var{REALM}}
pointing to your kerberos master server.

The @file{krb.realms} file is used to find out what realm a particular
host belongs to.  An example of this file could look like:

@example
this.realm            THIS.REALM
.this.realm           THIS.REALM
foo.com               SOME.OTHER.REALM
www.foo.com           A.STRANGE.REALM
.foo.com              FOO.REALM
@end example

Entries starting with a dot are taken as the name of a domain. Entries
not starting with a dot are taken as a host-name. The first entry matched
is used. The entry for @samp{this.realm} is only necessary if there is a
host named @samp{this.realm}.

If no matching realm is found in @file{krb.realms}, DNS is searched for
the correct realm. For example, if we are looking for host @samp{a.b.c},
@samp{krb4-realm.a.b.c} is first tried and then @samp{krb4-realm.b.c}
and so on. The entry should be a TXT record containing the name of the
realm, such as:

@example
krb4-realm.pdc.kth.se.  7200    TXT     "NADA.KTH.SE"
@end example

If this didn't help the domain name sans the first part in uppercase is
tried.

The plain vanilla version of Kerberos doesn't have any fancy methods of
getting realms and servers so it is generally a good idea to keep
@file{krb.conf} and @file{krb.realms} up to date.

@node Install the /etc/services, Install the kerberos server, Install the configuration files, How to set up the kerberos server
@subsection Updating /etc/services

(Obsolete in OpenBSD)

You should append or merge the contents of @file{services.append} to
your @file{/etc/services} files or NIS-map. Remove any unused factory
installed kerberos port definitions to avoid possible conflicts.
@pindex services

Most of the programs will fall back to the default ports if the port
numbers are not found in @file{/etc/services}, but it is convenient to
have them there anyway.

@node Install the kerberos server, Set up the server, Install the /etc/services, How to set up the kerberos server
@subsection Install the kerberos server

You should have already chosen the machine where you want to run the
kerberos server and the realm name.  The machine should also be as
secure as possible (@xref{Choose a kerberos server}) before installing
the kerberos server.  In this example, we will install a kerberos server
for the realm @samp{FOO.SE} on a machine called @samp{hemlig.foo.se}.

@node Set up the server, Add a few important principals, Install the kerberos server, How to set up the kerberos server
@subsection Setup the server

Login as root on the console of the kerberos server. Run
@kbd{kdb_init}:
@pindex kdb_init

@example
@cartouche
hemlig# kdb_init
Realm name [default  FOO.SE ]: 
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.

Enter Kerberos master password: 
Verifying password 
Enter Kerberos master password: 
@end cartouche
@end example

If you have set up the configuration files correctly, @kbd{kdb_init}
should choose the correct realm as the default, otherwise a (good) guess
is made.  Enter the master password.

This password will only be used for encrypting the kerberos database on
disk and for generating new random keys.  You will not have to remember
it, only to type it again when you run @kbd{kstash}.  Choose something
long and random.  Now run @kbd{kstash} using the same password:
@pindex kstash

@example
@cartouche
hemlig# kstash

Enter Kerberos master password: 

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Wrote master key to /etc/kerberosIV/master_key
@end cartouche
@end example

After entering the same master password it will be saved in the file
@file{/etc/kerberosIV/master_key} and the kerberos server will read it when needed. Write down
the master password and put it in a sealed envelope in a safe, you might
need it if your disk crashes or should you want to set up a slave
server.

@code{kdb_init} initializes the database with a few entries:

@table @samp
@item krbtgt.@var{REALM}
The key used for authenticating to the kerberos server.

@item changepw.kerberos
The key used for authenticating to the administrative server, i.e. when
adding users, changing passwords, and so on.

@item default
This entry is copied to new items when these are added.  Enter here the
values you want new entries to have, particularly the expiry date.

@item K.M
This is the master key and it is only used to verify that the master key
that is saved un-encrypted in @file{/etc/kerberosIV/master_key} is correct and corresponds to
this database.

@end table

@code{kstash} only reads the master password and writes it to
@file{/etc/kerberosIV/master_key}.  This enables the kerberos server to start without you
having to enter the master password.  This file (@file{/etc/kerberosIV/master_key}) is only
readable by root and resides on a ``secure'' machine.

@node Add a few important principals, Start the server, Set up the server, How to set up the kerberos server
@subsection Add a few important principals

Now the kerberos database has been created, containing only a few
principals.  The next step is to add a few more so that you can test
that it works properly and so that you can administer your realm without
having to use the console on the kerberos server.  Use @kbd{kdb_edit}
to edit the kerberos database directly on the server.
@pindex kdb_edit

@code{kdb_edit} is intended as a bootstrapping and fall-back mechanism
for editing the database.  For normal purposes, use the @code{kadmin}
program (@xref{Add users to the database}).

The following example shows the adding of the principal
@samp{nisse.admin} into the kerberos database.  This principal is used
by @samp{nisse} when administrating the kerberos database.  Later on the
normal principal for @samp{nisse} will be created.  Replace @samp{nisse}
and @samp{password} with your own username and password.

@example
@cartouche
hemlig# kdb_edit -n
Opening database...
Current Kerberos master key version is 1.

Master key entered.  BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.

Principal name: <nisse>
Instance: <admin>

<Not found>, Create [y] ? <>

Principal: nisse, Instance: admin, kdc_key_ver: 1
New Password: <password>
Verifying password 
New Password: <password>

Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? <>
Max ticket lifetime (*5 minutes) [ 255 ] ? <>
Attributes [ 0 ] ? <>
Edit O.K.
Principal name: <>
@end cartouche
@end example

@code{kdb_edit} will loop until you hit the @kbd{return} key at the
``Principal name'' prompt. Now you have added nisse as an administrator.

@node Start the server, Try to get tickets, Add a few important principals, How to set up the kerberos server
@subsection Start the server

@pindex kerberos
@example
@cartouche
hemlig# /usr/sbin/kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.

Master key entered.  BEWARE!

Current Kerberos master key version is 1
Local realm: FOO.SE
@end cartouche
@end example

@node  Try to get tickets, Create initial ACL for the admin server, Start the server, How to set up the kerberos server
@subsection Try to get tickets

You can now verify that these principals have been added and that the
server is working correctly.

@pindex kinit
@example
@cartouche
hemlig# kinit
eBones International (hemlig.foo.se)
Kerberos Initialization
Kerberos name: <nisse.admin>
Password: <password>
@end cartouche
@end example

If you do not get any error message from @code{kinit}, then everything
is working (otherwise, see @ref{Common error messages}).  Use
@code{klist} to verify the tickets you acquired with @code{kinit}:

@pindex klist
@example
@cartouche
hemlig# klist
Ticket file:    /tmp/tkt0
Principal:      nisse.admin@@FOO.SE

Issued           Expires          Principal
May 24 21:06:03  May 25 07:06:03  krbtgt.FOO.SE@@FOO.SE
@end cartouche
@end example

@node Create initial ACL for the admin server, Start the admin server, Try to get tickets, How to set up the kerberos server
@subsection Create initial ACL for the admin server

The admin server, @code{kadmind}, uses a series of files to determine who has
@pindex kadmind
the right to perform certain operations.  The files are:
@file{admin_acl.add}, @file{admin_acl.get}, @file{admin_acl.del}, and
@file{admin_acl.mod}.  Create these with @samp{nisse.admin@@FOO.SE} as
the contents.
@pindex admin_acl.add
@pindex admin_acl.get
@pindex admin_acl.del
@pindex admin_acl.mod

@example
@cartouche
hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.add
hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.get
hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.mod
hemlig# echo "nisse.admin@@FOO.SE" >> /etc/kerberosIV/admin_acl.del
@end cartouche
@end example

Later on you may wish to add more users with administration
privileges. Make sure that you create both the administration principals
and add them to the admin server ACL.

@node Start the admin server, Add users to the database, Create initial ACL for the admin server, How to set up the kerberos server
@subsection Start the admin server

@pindex kadmind
@example
@cartouche
hemlig# /usr/sbin/kadmind &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead

Current Kerberos master key version is 1.

Master key entered.  BEWARE!
@end cartouche
@end example

@node Add users to the database, Automate the startup of the servers, Start the admin server, How to set up the kerberos server
@subsection Add users to the database

Use the @code{kadmin} client to add users to the database:
@pindex kadmin

@example
@cartouche
hemlig# kadmin -u nisse.admin -m
Welcome to the Kerberos Administration Program, version 2
Type "help" if you need it.
admin:  <add nisse>
Admin password: <nisse.admin's password>
Maximum ticket lifetime?  (255)  [Forever]  
Attributes?  [0x00]  
Expiration date (enter yyyy-mm-dd) ?  [Sat Jan  1 05:59:00 2000]  
Password for nisse:
Verifying password Password for nisse:
nisse added to database.
@end cartouche
@end example

Add whatever other users you want to have in the same way.  Verify that
a user is in the database and check the database entry for that user:

@example
@cartouche
admin:  <get nisse>
Info in Database for nisse.:
Max Life: 255 (Forever)   Exp Date: Sat Jan  1 05:59:59 2000

Attribs: 00  key: 0 0
admin:  <^D>
Cleaning up and exiting.
@end cartouche
@end example

@node Automate the startup of the servers,  , Add users to the database, How to set up the kerberos server
@subsection Automate the startup of the servers

Add the lines that were used to start the kerberos server and the
admin server to your startup scripts (@file{/etc/rc} or similar).
@pindex rc

@node Install the client programs, Install the kerberised services, How to set up the kerberos server, How to set up a realm
@section Install the client programs

(Obsolete in OpenBSD)

Making a machine a kerberos client only requires a few steps.  First you
might need to change the configuration files as with the kerberos
server.  (@xref{Install the configuration files} and @ref{Install the
/etc/services}.) Also you need to make the programs in
@file{/usr/athena/bin} available.  This can be done by adding the
@file{/usr/athena/bin} directory to the users' paths, by making symbolic
links, or even by copying the programs.

You should also verify that the local time on the client is synchronised
with the time on the kerberos server by some means. The maximum allowed
time difference between the participating servers and a client is 5
minutes.
@cindex NTP.
One good way to synchronize the time is NTP (Network Time Protocol), see
@url{http://www.eecis.udel.edu/~ntp/}.

If you need to run the client programs on a machine where you do not
have root-access, you can hopefully just use the binaries and no
configuration will be needed.  The heuristics used are mentioned above
(see @ref{Install the configuration files}).  If this is not the case
and you need to have @file{krb.conf} and/or @file{krb.realms}, you can
copy them into a directory of your choice and
@pindex krb.conf
@pindex krb.realms
set the environment variable @var{KRBCONFDIR} to point at this
@cindex KRBCONFDIR
directory.

To test the client functionality, run the @code{kinit} program:

@example
@cartouche
foo$ kinit
eBones International (foo.foo.se)
Kerberos Initialization
Kerberos name: <nisse>
Password: <password>

foo$ klist
Ticket file:    /tmp/tkt4711
Principal:      nisse@@FOO.SE

Issued           Expires          Principal
May 24 21:06:03  May 25 07:06:03  krbtgt.FOO.SE@@FOO.SE
@end cartouche
@end example

@node Install the kerberised services, Install a slave kerberos server, Install the client programs, How to set up a realm
@section Install the kerberised services

(Obsolete in OpenBSD)

These includes @code{rsh}, @code{rlogin}, @code{telnet}, @code{ftp},
@code{rxtelnet}, and so on.
@pindex rsh
@pindex rlogin
@pindex telnet
@pindex ftp
@pindex rxtelnet

First follow the steps mentioned in the prior section to make it a
client and verify its operation.  Change @file{inetd.conf} next to use
the new daemons.  Look at the file
@pindex inetd.conf
@file{etc/inetd.conf.changes} to see the changes that we recommend you
perform on @file{inetd.conf}.

You should at this point decide what services you want to run on
each machine.

@subsection rsh, rlogin, and rcp
@pindex rsh
@pindex rlogin
@pindex rcp

These exist in kerberised versions and ``old-style'' versions.  The
different versions use different port numbers, so you can choose none,
one, or both.  If you do not want to use ``old-style'' r* services, you
can let the programs output the text ``Remote host requires Kerberos
authentication'' instead of just refusing connections to that port.
This is enabled with the @samp{-v} option.  The kerberised services
exist in encrypted and non-encrypted versions.  The encrypted services
have an ``e'' prepended to the name and the programs take @samp{-x} as an
option indicating encryption.

Our recommendation is to only use the kerberised services and give
explanation messages for the old ports.

@subsection telnet
@pindex telnet

The telnet service always uses the same port and negotiates as to which
authentication method should be used.  The @code{telnetd} program has
@pindex telnetd
an option ``-a user'' that only allows kerberised and authenticated
connections.  If this is not included, it falls back to using clear text
passwords.  For obvious reasons, we recommend that you enable this
option.  If you want to use one-time passwords (@xref{One-Time
Passwords}) you can use the ``-a otp'' option which will allow OTPs or
kerberised connections.

@subsection ftp
@pindex ftp

The ftp service works as telnet does, with just one port being used.  By
default only kerberos authenticated connections are allowed.  You can
specify additional levels that are thus allowed with these options:

@table @asis
@item @kbd{-a otp}
Allow one-time passwords (@xref{One-Time Passwords}).
@item @kbd{-a ftp}
Allow anonymous login (as user ``ftp'' or ``anonymous'').
@item @kbd{-a safe}
The same as @kbd{-a ftp}, for backwards compatibility.
@item @kbd{-a plain}
Allow clear-text passwords.
@item @kbd{-a none}
The same as @kbd{-a ftp -a plain}.
@item @kbd{-a user}
A no-op, also there for backwards compatibility reasons.
@end table

When running anonymous ftp you should read the man page on @code{ftpd}
which explains how to set it up.

@subsection pop
@pindex popper

The Post Office Protocol (POP) is used to retrieve mail from the mail
hub.  The @code{popper} program implements the standard POP3 protocol
and the kerberised KPOP.  Use the @samp{-k} option to run the kerberos
version of the protocol. This service should only be run on your mail
hub.

@subsection kx
@pindex kx

@code{kx} allows you to run X over a kerberos-authenticated and
encrypted connection.  This program is used by @code{rxtelnet},
@code{tenletxr}, and @code{rxterm}.

If you have some strange kind of operating system with X libraries that
do not allow you to use unix-sockets, you need to specify the @samp{-t}
@pindex kxd
option to @code{kxd}.  Otherwise it should be sufficient by adding the
daemon in @file{inetd.conf}.

@subsection kauth
@pindex kauth

This service allows you to create tickets on a remote host.  To
enable it just insert the corresponding line in @file{inetd.conf}.

@section srvtabs
@pindex srvtab

In the same way every user needs to have a password registered with
the kerberos server, every service needs to have a shared key with the
kerberos server.  The service keys are stored in a file, usually called
@file{/etc/kerberosIV/srvtab}.  This file should not be readable to anyone but
root, in order to keep the key from being divulged.  The name of this principal
in the kerberos database is usually the service and the host.  The key
for the pop service is called @samp{pop.@var{hostname}}.  The one for
rsh/rlogin/telnet is named @samp{rcmd.@var{hostname}}.  (rcmd comes from
``remote command'').  To create these keys you will use the the
@code{ksrvutil} program.  Perform the
@pindex ksrvutil
following:

@example
@cartouche
bar# ksrvutil -p nisse.admin get
Name [rcmd]: <>
Instance [bar]: <>
Realm [FOO.SE]: <>
Is this correct? (y,n) [y] <>
Add more keys? (y,n) [n] <>
Password for nisse.admin@@FOO.SE: <nisse.admin's password>
Written rcmd.bar
rcmd.bar@@FOO.SE
Old keyfile in /etc/srvtab.old.
@end cartouche
@end example

@subsection Complete test of the kerberised services

Obtain a ticket on one machine (@samp{foo}) and use it to login with a
kerberised service to a second machine (@samp{bar}).  The test should
look like this if successful:

@example
@cartouche
foo$ kinit nisse
eBones International (foo.foo.se)
Kerberos Initialization for "nisse"
Password: <nisse's password>
foo$ klist
Ticket file:    /tmp/tkt4711
Principal:      nisse@@FOO.SE

Issued           Expires          Principal
May 30 13:48:03  May 30 23:48:03  krbtgt.FOO.SE@@FOO.SE
foo$ telnet bar
Trying 17.17.17.17...
Connected to bar.foo.se
Escape character is '^]'.
[ Trying mutual KERBEROS4 ... ]
[ Kerberos V4 accepts you ]
[ Kerberos V4 challenge successful ]
bar$
@end cartouche
@end example

You can also try with @code{rsh}, @code{rcp}, @code{rlogin},
@code{rlogin -x}, and some other commands to see that everything is
working all right.

@node Install a slave kerberos server, Cross-realm functionality , Install the kerberised services, How to set up a realm
@section Install a slave kerberos server

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.

First select a good server machine.  @xref{Choose a kerberos
server}. Since the master and slave servers will use copies of the same
database, they need to use the same master key.

On the master, add a @samp{rcmd.kerberos} principal (using
@samp{ksrvutil get}). The
@pindex kprop
@code{kprop} program, running on the master, will use this when
authenticating to the
@pindex kpropd
@code{kpropd} daemons running on the slave servers.

On your master server, create a file, e.g. @file{/etc/kerberosIV/slaves},
that contains the hostnames of your kerberos slave servers.

Start @code{kpropd} with @samp{kpropd -i} on your slave servers.

On your master server, create a dump of the database with @samp{kdb_util
slave_dump /etc/kerberosIV/slave_dump}, and then run @code{kprop}.

You should now have copies of the database on your slave servers. You
can verify this by issuing @samp{kdb_util dump @var{file}} on your
slave servers, and comparing with the original file on the master
server. Note that the entries will not be in the same order.

This procedure should be automated with a script run regularly by cron,
for instance once an hour.

To start the kerberos server on slaves, you first have to copy the
master key from the master server. You can do this either by remembering
the master password and issuing @samp{kstash}, or you can just copy the
keyfile. Remember that if you copy the file, do so on a safe media, not
over the network. Good means include floppy or paper. Paper is better,
since it is easier to swallow afterwards.

The kerberos server should be started with @samp{-s} on the slave
servers. This enables sanity checks, for example checking the time since
the last update from the master.

All changes to the database are made by @code{kadmind} at the master,
and then propagated to the slaves, so you should @strong{not} run
@code{kadmind} on the slaves.

Finally add the slave servers to
@file{/etc/kerberosIV/krb.conf}. The clients will ask the servers in the order
specified by that file.

Consider adding CNAMEs to your slave servers, see @ref{Install the
configuration files}.

@node Cross-realm functionality ,  , Install a slave kerberos server, How to set up a realm
@section Cross-realm functionality

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 shared key between two realms that trust each
other. When a client program, such as @code{telnet}, 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.

To add this functionality you have to add a principal to each realm. The
principals should be @samp{krbtgt.OTHER.REALM} in @samp{MY.REALM}, and
@samp{krbtgt.MY.REALM} in @samp{OTHER.REALM}. The two different
principals should have the same key (and key version number).  Remember
to transfer this key in a safe manner. This is all that is required.

@example
@cartouche
blubb$ klist
Ticket file:    /tmp/tkt3008
Principal:      joda@@NADA.KTH.SE

  Issued           Expires          Principal
Jun  7 02:26:23  Jun  7 12:26:23  krbtgt.NADA.KTH.SE@@NADA.KTH.SE
blubb$ telnet agat.e.kth.se
Trying 130.237.48.12...
Connected to agat.e.kth.se.
Escape character is '^]'.
[ Trying mutual KERBEROS4 ... ]
[ Kerberos V4 accepts you ]
[ Kerberos V4 challenge successful ]
Last login: Sun Jun  2 20:51:50 from emma.pdc.kth.se

agat$ exit
Connection closed by foreign host.
blubb$ klist
Ticket file:    /tmp/tkt3008
Principal:      joda@@NADA.KTH.SE

  Issued           Expires          Principal
Jun  7 02:26:23  Jun  7 12:26:23  krbtgt.NADA.KTH.SE@@NADA.KTH.SE
Jun  7 02:26:50  Jun  7 12:26:50  krbtgt.E.KTH.SE@@NADA.KTH.SE
Jun  7 02:26:51  Jun  7 12:26:51  rcmd.agat@@E.KTH.SE
@end cartouche
@end example