Node:Add Administrators to the Acl File, Next:Add Administrators to the Kerberos Database, Previous:Create the Database, Up:Install the Master KDC
Next, you need create an Access Control List (acl) file, and put the
Kerberos principal of at least one of the administrators into it. The
filename should match the value you have set for "acl_file" in your
kdc.conf
file. The default file name is
/usr/local/var/krb5kdc/kadm5.acl
.
The format of the file is:
Kerberos_principal permissions [target_principal] [restrictions]
The Kerberos principal (and optional target principal) can include the
"*" wildcard, so if you want any principal with the instance
"admin" to have full permissions on the database, you could use the
principal "*/admin@REALM
" where "REALM" is your Kerberos
realm. target_principal
can also include backreferences to
Kerberos_principal
, in which "*number" matches the
component number in the Kerberos_principal
.
Note: a common use of an admin instance is so you can grant
separate permissions (such as administrator access to the Kerberos
database) to a separate Kerberos principal. For example, the user
joeadmin
might have a principal for his administrative
use, called joeadmin/admin
. This way,
joeadmin
would obtain joeadmin/admin
tickets only when he actually needs to use those permissions.
The permissions are represented by single letters; UPPER-CASE letters represent negative permissions. The permissions are:
The restrictions are a string of flags. Allowed restrictions are:
+
and -
flags for the kadmin addprinc
and
modprinc
commands.
The above flags act as restrictions on any add or modify operation which is allowed due to that ACL line.
Here is an example of a kadm5.acl
file. Note that order is
important; permissions are determined by the first matching entry.
*/admin@ATHENA.MIT.EDU * joeadmin@ATHENA.MIT.EDU ADMCIL joeadmin/*@ATHENA.MIT.EDU il */root@ATHENA.MIT.EDU *@ATHENA.MIT.EDU cil *1/admin@ATHENA.MIT.EDU */*@ATHENA.MIT.EDU i */admin@EXAMPLE.COM * -maxlife 9h -postdateable
In the above file, any principal in the
ATHENA.MIT.EDU realm with an admin
instance has all
administrative privileges. The user joeadmin
has all permissions with his admin
instance,
joeadmin/admin@ATHENA.MIT.EDU
(matches the first
line). He has no permissions at all with his null
instance,
joeadmin@ATHENA.MIT.EDU
(matches the second line).
His root instance has inquire and list permissions with any
other principal that has the instance root
. Any principal
in ATHENA.MIT.EDU can inquire, list, or change the password of
their admin
instance, but not any other admin
instance.
Any principal in the realm ATHENA.MIT.EDU
(except for
joeadmin@ATHENA.MIT.EDU
, as mentioned above) has
inquire privileges. Finally, any principal with an admin instance
in EXAMPLE.COM has all permissions, but any principal that they
create or modify will not be able to get postdateable tickets or tickets
with a life of longer than 9 hours.