1KADMIND(8) System Manager's Manual KADMIND(8)
2
6 kadmind - KADM5 administration server
7
9 kadmind [-x db_args] [-r realm] [-m] [-nofork] [-port port-number]
10 [-P pid_file]
11
13 This command starts the KADM5 administration server. If the database
14 is db2, the administration server runs on the master Kerberos server,
15 which stores the KDC prinicpal database and the KADM5 policy database.
16 If the database is LDAP, the administration server and the KDC server
17 need not run on the same machine. Kadmind accepts remote requests to
18 administer the information in these databases. Remote requests are
19 sent, for example, by kadmin(8) and the kpasswd(1) command, both of
20 which are clients of kadmind.
21 kadmind requires a number of configuration files to be set up in order
23 for it to work:
24 kdc.conf The KDC configuration file contains configuration informatin
26 for the KDC and the KADM5 system. Kadmind understands a num‐
27 ber of variable settings in this file, some of whch are
28 mandatory and some of which are optional. See the CONFIGURA‐
29 TION VALUES section below.
30 keytab Kadmind requires a keytab containing correct entries for the
32 kadmin/admin and kadmin/changepw principals for every realm
33 that kadmind will answer requests for. The keytab can be
34 created with the kadmin(8) client. The location of the
35 keytab is determined by the admin_keytab configuration vari‐
36 able (see CONFIGURATION VALUES).
37 ACL file Kadmind's ACL (access control list) tells it which principals
39 are allowed to perform KADM5 administration actions. The
40 path of the ACL file is specified via the acl_file configura‐
41 tion variable (see CONFIGURATION VALUES). The syntax of the
42 ACL file is specified in the ACL FILE SYNTAX section below.
43 After the server begins running, it puts itself in the background and
45 disassociates itself from its controlling terminal.
46 kadmind can be configured for incremental database propagation. Incre‐
48 mental propagation allows slave KDC servers to receive principal and
49 policy updates incrementally instead of receiving full dumps of the
50 database. This facility can be enabled in the kdc.conf file with the
51 iprop_enable option. See the kdc.conf documentation for other options
52 for tuning incremental propagation parameters. Incremental propagation
53 requires the principal "kiprop/MASTER@REALM" (where MASTER is the mas‐
54 ter KDC's canonical host name, and REALM the realm name) to be regis‐
55 tered in the database.
56
59 -x db_args
60 specifies the database specific arguments.
61 Options supported for LDAP database are:
63 -x nconns=<number_of_connections>
65 specifies the number of connections to be maintained per
66 LDAP server.
67 -x host=<ldapuri>
69 specifies the LDAP server to connect to by a LDAP URI.
70 -x binddn=<binddn>
72 specifies the DN of the object used by the administration
73 server to bind to the LDAP server. This object should have
74 the read and write rights on the realm container, principal
75 container and the subtree that is referenced by the realm.
76 -x bindpwd=<bind_password>
78 specifies the password for the above mentioned binddn. It
79 is recommended not to use this option. Instead, the pass‐
80 word can be stashed using the stashsrvpw command of
81 kdb5_ldap_util.
82 -r realm
84 specifies the default realm that kadmind will serve; if it is
85 not specified, the default realm of the host is used. kadmind
86 will answer requests for any realm that exists in the local KDC
87 database and for which the appropriate principals are in its
88 keytab.
89 -m specifies that the master database password should be fetched
91 from the keyboard rather than from a file on disk. Note that
92 the server gets the password prior to putting itself in the
93 background; in combination with the -nofork option, you must
94 place it in the background by hand.
95 -nofork
97 specifies that the server does not put itself in the background
98 and does not disassociate itself from the terminal. In normal
99 operation, you should always allow the server place itself in
100 the background.
101 -port port-number
103 specifies the port on which the administration server listens
104 for connections. The default is is controlled by the kad‐
105 mind_port configuration variable (see below).
106 -P pid_file
108 specifies the file to which the PID of kadmind process should be
109 written to after it starts up. This can be used to identify
110 whether kadmind is still running and to allow init scripts to
111 stop the correct process.
112
114 In addition to the relations defined in kdc.conf(5), kadmind under‐
115 stands the following relations, all of which should appear in the
116 [realms] section:
117 acl_file
119 The path of kadmind's ACL file. Mandatory. No default.
120 dict_file
122 The path of kadmind's password dictionary. A principal with any
123 password policy will not be allowed to select any password in
124 the dictionary. Optional. No default.
125 admin_keytab
127 The name of the keytab containing entries for the principals
128 kadmin/admin and kadmin/changepw in each realm that kadmind will
129 serve. The default is the value of the KRB5_KTNAME environment
130 variable, if defined. Mandatory.
131 kadmind_port
133 The TCP port on which kadmind will listen. The default is 749.
134
136 The ACL file controls which principals can or cannot perform which
137 administrative functions. For operations that affect principals, the
138 ACL file also controls which principals can operate on which other
139 principals. This file can contain comment lines, null lines or lines
140 which contain ACL entries. Comment lines start with the sharp sign (#)
141 and continue until the end of the line. Lines containing ACL entries
142 have the format of principal whitespace operation-mask [whitespace
143 operation-target]
144 Ordering is important. The first matching entry is the one which will
146 control access for a particular principal on a particular principal.
147 principal
149 may specify a partially or fully qualified Kerberos version 5
150 principal name. Each component of the name may be wildcarded
151 using the asterisk ( * ) character.
152 operation-target
154 [Optional] may specify a partially or fully qualified Kerberos
155 version 5 principal name. Each component of the name may be
156 wildcarded using the asterisk ( * ) character.
157 operation-mask
159 Specifies what operations may or may not be peformed by a prin‐
160 cipal matching a particular entry. This is a string of one or
161 more of the following list of characters or their upper-case
162 counterparts. If the character is upper-case, then the opera‐
163 tion is disallowed. If the character is lower-case, then the
164 operation is permitted.
165 a [Dis]allows the addition of principals or policies in the
167 database.
168 d [Dis]allows the deletion of principals or policies in the
169 database.
170 m [Dis]allows the modification of principals or policies in
171 the database.
172 c [Dis]allows the changing of passwords for principals in the
173 database.
174 i [Dis]allows inquiries to the database.
175 l [Dis]allows the listing of principals or policies in the
176 database.
177 p [Dis]allows the propagation of the principal database.
178 x Short for admcil.
179 * Same as x.
180 Some examples of valid entries here are:
181 user/instance@realm adm
183 A standard fully qualified name. The operation-mask only
184 applies to this principal and specifies that [s]he may add,
185 delete or modify principals and policies, but not change anybody
186 else's password.
187 user/instance@realm cim service/instance@realm
189 A standard fully qualified name and a standard fully qualified
190 target. The operation-mask only applies to this principal oper‐
191 ating on this target and specifies that [s]he may change the
192 target's password, request information about the target and mod‐
193 ify it.
194 user/*@realm ac
196 A wildcarded name. The operation-mask applies to all principals
197 in realm "realm" whose first component is "user" and specifies
198 that [s]he may add principals and change anybody's password.
199 user/*@realm i */instance@realm
201 A wildcarded name and target. The operation-mask applies to all
202 principals in realm "realm" whose first component is "user" and
203 specifies that [s]he may perform inquiries on principals whose
204 second component is "instance" and realm is "realm".
205
207 principal.db default name for Kerberos principal database
208 <dbname>.kadm5 KADM5 administrative database. (This would be
210 "principal.kadm5", if you use the default database
211 name.) Contains policy information.
212 <dbname>.kadm5.lock lock file for the KADM5 administrative database.
214 This file works backwards from most other lock
215 files. I.e., kadmin will exit with an error if
216 this file does not exist.
217 Note: The above three files are specific to db2 database.
219 kadm5.acl file containing list of principals and their kadmin
221 administrative privileges. See above for a
222 description.
223 kadm5.keytab keytab file for kadmin/admin principal.
225 kadm5.dict file containing dictionary of strings explicitly
227 disallowed as passwords.
228
230 kpasswd(1), kadmin(8), kdb5_util(8), kadm5_export(8), kadm5_import(8),
231 kdb5_ldap_util(8)
232 KADMIND(8)