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] [-k kprop_port]
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 principal 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 information
26 for the KDC and the KADM5 system. Kadmind understands a num‐
27 ber of variable settings in this file, some of which 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 -k kprop_port
114 specifies the port by which the kprop process that is spawned by
115 kadmind connects to the slave kpropd, in order to transfer the
116 dump file during an iprop full resync request.
117
119 In addition to the relations defined in kdc.conf(5), kadmind under‐
120 stands the following relations, all of which should appear in the
121 [realms] section:
122 acl_file
124 The path of kadmind's ACL file. Mandatory. No default.
125 dict_file
127 The path of kadmind's password dictionary. A principal with any
128 password policy will not be allowed to select any password in
129 the dictionary. Optional. No default.
130 admin_keytab
132 The name of the keytab containing entries for the principals
133 kadmin/admin and kadmin/changepw in each realm that kadmind will
134 serve. The default is the value of the KRB5_KTNAME environment
135 variable, if defined. Mandatory.
136 kadmind_port
138 The TCP port on which kadmind will listen. The default is 749.
139
141 The ACL file controls which principals can or cannot perform which
142 administrative functions. For operations that affect principals, the
143 ACL file also controls which principals can operate on which other
144 principals. This file can contain comment lines, null lines or lines
145 which contain ACL entries. Comment lines start with the sharp sign (#)
146 and continue until the end of the line. Lines containing ACL entries
147 have the format of principal whitespace operation-mask [whitespace
148 operation-target]
149 Ordering is important. The first matching entry is the one which will
151 control access for a particular principal on a particular principal.
152 principal
154 may specify a partially or fully qualified Kerberos version 5
155 principal name. Each component of the name may be wildcarded
156 using the asterisk ( * ) character.
157 operation-target
159 [Optional] may specify a partially or fully qualified Kerberos
160 version 5 principal name. Each component of the name may be
161 wildcarded using the asterisk ( * ) character.
162 operation-mask
164 Specifies what operations may or may not be performed by a prin‐
165 cipal matching a particular entry. This is a string of one or
166 more of the following list of characters or their upper-case
167 counterparts. If the character is upper-case, then the opera‐
168 tion is disallowed. If the character is lower-case, then the
169 operation is permitted.
170 a [Dis]allows the addition of principals or policies in the
172 database.
173 d [Dis]allows the deletion of principals or policies in the
174 database.
175 m [Dis]allows the modification of principals or policies in
176 the database.
177 c [Dis]allows the changing of passwords for principals in the
178 database.
179 i [Dis]allows inquiries to the database.
180 l [Dis]allows the listing of principals or policies in the
181 database.
182 p [Dis]allows the propagation of the principal database.
183 x Short for admcil.
184 * Same as x.
185 Some examples of valid entries here are:
186 user/instance@realm adm
188 A standard fully qualified name. The operation-mask only
189 applies to this principal and specifies that [s]he may add,
190 delete or modify principals and policies, but not change anybody
191 else's password.
192 user/instance@realm cim service/instance@realm
194 A standard fully qualified name and a standard fully qualified
195 target. The operation-mask only applies to this principal oper‐
196 ating on this target and specifies that [s]he may change the
197 target's password, request information about the target and mod‐
198 ify it.
199 user/*@realm ac
201 A wildcarded name. The operation-mask applies to all principals
202 in realm "realm" whose first component is "user" and specifies
203 that [s]he may add principals and change anybody's password.
204 user/*@realm i */instance@realm
206 A wildcarded name and target. The operation-mask applies to all
207 principals in realm "realm" whose first component is "user" and
208 specifies that [s]he may perform inquiries on principals whose
209 second component is "instance" and realm is "realm".
210
212 principal.db default name for Kerberos principal database
213 <dbname>.kadm5 KADM5 administrative database. (This would be
215 "principal.kadm5", if you use the default database
216 name.) Contains policy information.
217 <dbname>.kadm5.lock lock file for the KADM5 administrative database.
219 This file works backwards from most other lock
220 files. I.e., kadmin will exit with an error if
221 this file does not exist.
222 Note: The above three files are specific to db2 database.
224 kadm5.acl file containing list of principals and their kadmin
226 administrative privileges. See above for a
227 description.
228 kadm5.keytab keytab file for kadmin/admin principal.
230 kadm5.dict file containing dictionary of strings explicitly
232 disallowed as passwords.
233
235 kpasswd(1), kadmin(8), kdb5_util(8), kadm5_export(8), kadm5_import(8),
236 kdb5_ldap_util(8)
237 KADMIND(8)