C.0 Administrative Privileges for the Kerberos Database

You need to set administrative privileges for the Kerberos database in the kadm5.acl file.

The format of the file is as follows:

Kerberos_principal  permissions  [target_principal]	[restrictions]

Table C-1 kadm5.acl File

Field

Description

Kerberos_principal

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.

NOTE:A common use of an admin instance is to 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.

target_principal

Can also include backreferences to Kerberos_principal, in which "*number" matches the component number in the Kerberos_principal.

permissions

The permissions are represented by single letters; UPPERCASE letters represent negative permissions. The permissions are:

a

Allows the addition of principals or policies in the database.

A

Disallows the addition of principals or policies in the database.

d

Allows the deletion of principals or policies in the database.

D

Disallows the deletion of principals or policies in the database.

m

Allows the modification of principals or policies in the database.

M

Disallows the modification of principals or policies in the database.

c

Allows the changing of passwords for principals in the database.

C

Disallows the changing of passwords for principals in the database.

i

Allows inquiries to the database.

I

Disallows inquiries to the database.

l

Allows the listing of principals or policies in the database.

L

Disallows the listing of principals or policies in the database.

s

Allows the explicit setting of the key for a principal.

S

Disallows the explicit setting of the key for a principal.

*

All privileges (admcil).

X

All privileges (admcil); identical to "*".

restrictions

The restrictions are a string of flags. Allowed restrictions are:

[+ -]flagname

The flag is forced to the indicated value. The permissible flags are the same as the + and - flags for the kadmin addprinc and modprinc commands.

-clearpolicy

The policy is forced to clear.

-policy pol

The policy is forced to be pol.

expire time

pwexpire time

maxlife time

maxrenewlife time

The associated value is forced to MIN (time, requested value).

The above flags act as restrictions on any add or modify operation that is allowed because of that ACL line.

An example of a kadm5.acl file is as follows:

NOTE: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 his or her 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 he or she creates or modifies cannot get postdateable tickets or tickets with a life of longer than 9 hours.