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
|
This directory contains additional data files needed to run some tests.
By default, all the tests are done using a SQLite database. To test
against another database, create a file named test.database. The first
line of the file should contain the database driver name (mysql, for
example, for DBD::mysql). The second line should contain the DBI connect
string, normally of the form:
database=<name>;host=<host>;port=<port>
replacing <name>, <host>, and <port> with the parameters for your
database. The third line should be the username to use, and the fourth
and last line should be the password. If this file is present, all tests
will be run against this database instead of a local SQLite database.
In order to run the keytab tests, you will need to grant the test
processes access to create, download, and remove principals in a test KDC.
This should not be pointed at a production KDC! Then, create the
following files:
test.keytab Keytab for an authorized user
test.principal Principal of the authorized user
test.realm Kerberos realm in which to do testing
test.krbtype Type of Kerberos server (Heimdal or MIT)
This realm will also need to be configured in your local krb5.conf,
including the admin_server for the realm.
The test process will create the principals wallet/one and wallet/two and
on success will clean up after itself. If the test fails, they may be
left behind in the KDC. It will also attempt to create wallet-test/one
and expects that attempt to be rejected by the KDC.
For MIT Kerberos, to grant appropriate permissions, add the line:
<principal> admci wallet/*@<realm>
to the kadm5.acl file for your master KDC for the test realm and restart
kadmind. <principal> is the principal that you are using to test with,
and <realm> is the Kerberos realm.
Again, I do not recommend using a production realm; the test doesn't need
a production realm and it's more secure to stick to a test realm.
In order to test the AFS kaserver synchronization, you will need to grant
the test processes access to a principal with ADMIN rights in a test AFS
kaserver. This should not be pointed at a production cell! Create the
following files:
test.admin Fully-qualified principal of ADMIN user
test.srvtab Kerberos v4 srvtab for the ADMIN user
The ADMIN user will be parsed to determine the default realm for
principals created in the kaserver. You cannot use cross-realm
authentication for this test. This AFS kaserver Kerberos v4 realm will
also need to be configured in your local krb.conf (but not krb.realms).
The test process will create the principals wallet.one and wallet.two and
on success will clean up after itself. If the test fails, they may be
left behind in the AFS kaserver.
-----
Copyright 2007, 2009, 2013
The Board of Trustees of the Leland Stanford Junior University
Copying and distribution of this file, with or without modification, are
permitted in any medium without royalty provided the copyright notice and
this notice are preserved. This file is offered as-is, without any
warranty.
|
