 |
» |
|
|
|
This file lists authorized principals with their respective
administrative permissions. It also lists principals that cannot
be modified without explicit privileges. This file is located only
on the primary security server, at the following location: It must be protected with appropriate read-write privileges
and must be accessible only by the root user. kadmind checks for the principal's
permissions in the admin_acl_file. The admin_acl_file can
be edited directly on the primary server, or can also be edited
remotely using the Administrative Permissions window
of the Administrator. The general format
of the file is: identifier/instance@REALM [perms_list] [# comments] where, - identifier
The principal's name - instance
The administrative instance associated with the principal.
It is recommended that you add an admin instance
to each administrative principal name. If the prinicpal resides in the primary security server's default
realm, the @REALM is optional; else you will need
to explicitly specify the principal's realm. - [perms_list]
You need to add one or more of the permissions letters listed
in the table below, with no spaces between them. - [# comment]
Contains any optional remarks about the principal. Characters
after the pound symbol are ignored.
Each line in the admin_acl_file matches
an administrative principal with a set of permissions. Wildcards
can also be used to enter groups of principal names. Assigning
Administrative Permissions | |
Administrative principals may have varying levels of trust
assigned to them, depending on your organization's policies. Table 6-1 “Administrative Permission Settings” lists the possible administrative
permission settings and the letter designator used in the admin_acl_file to indicate the permissions assigned to the principal
account. Permissions designated with a lower case letter apply only
to the realm to which the administrative principal belongs. Permissions
designated with an upper-case letter apply to all realms. The [
permissions] is an optional string containing
one or more of the options listed in the table below. The Restricted administrator setting is a modifier; it must
be used in conjunction with permissions. There are several important considerations
that need to be taken into account while using r, R and Rr modifiers. Refer to “Using
Restricted Adminsitrator”, for more information.
Table 6-1 Administrative Permission Settings Administrator Field Name | ACL file Character |
|---|
Add Principals | a or A | | Change Principal Passwords | c or C | | Delete Principals | d or D | Edit the admin_acl_file.
Note: This setting cannot be restricted by
the r or R permissions | e or E | | Edit Group Defaults | g or G | | Inquire about Principals. Assign this attribute
to all administrative principals to allow use of the administrative
tools | i or I | List prinicpal. This is redundant with i or
I
Note: This permission is not displayed in Administrator | l or L | | Modify Principals | m or M | | Extract Keys | x or X | | Restricted Administrator. Use the r, R and Rr modifiers in combination with the a, A, c, C, d, D, i, I, m, M, or x. X permissions to permit administrative principals to use
those options only against certain principals. | r or R |
| | | |  | NOTE: The order of the permission letters is irrelevant. | | | | |
The principal can also include the "*" wildcard
as the admin_acl_file supports the following identifier/instance wildcards: This makes it easier to add groups of principal names to the
file. So if you want any principal with the instance "admin" to
have permissions to administer the database, you could use the principal "*/admin@REALM". where 'REALM' is your primary security server's
realm. For example, to grant all principals with the admin instance,
who need to have all the permissions assigned to them, add the following
line in the acl file: */admin@FINANCE.BAMBI.COM * where, - *
all prinicpals - admin
instance - FINANCE.BAMBI.COM
realm name - *
all permissions
To grant the principal, rabbit@FINANCE.BAMBI.COM, permission to add, list and inquire about any principal
in the database, you can add the following line into the acl file: rabbit@FINANCE.BAMBI.COM ali Adding
Entries to the admin_acl_file | |
You can add any principal name to the admin_acl_file as
an entry with or without assigned administrative permissions. To add a principal with assigned permissions, use the Principal Information's
attribute tab of kadminl_ui. Refer to “Administrative
Permissions”. Deciding which principal names to add to the admin_acl_file is
a strategic decision. Consider the following: There
should be only one admin_acl_file per primary
server. All realms supported by the primary server are included
in this file. Any principal name added
to this file should have adequate protection, so that only the most
trusted administrative principals can alter the principal account
using the remote administration tool. Principals in the admin_acl_file that
have assigned permissions can log on to the administrative tools,
thereby becoming administrative principals.
The r, R, or Rr modifiers, when used with the a or A permission, restrict the principal names that can be
added to the database. For instance, principals assigned the 'IARiar' permissions cannot add new principals that use an identifier/instance@REALM, which is already included in the admin_acl_file. To take advantage of this restriction, you must consider the
names you may want to add to the admin_acl_file. Creating
Administrative Accounts | |
You can set administrative permissions in the admin_acl_file using one of the following methods: Using the
Administrator to set administrative permissions. The admin_acl_file is automatically edited, when you change the administrative
permissions of the principal. Edit the admin_acl_file directly. To edit this file you must have the required
system file administration rights.
Using
Restricted Adminsitrator | |
The r, R, and Rr modifiers
are used in combination with the a, A, c, C, d, D, i, I, m, M,
or x, X permissions
to permit administrative principals to use those options only against
certain principals. How
the r/R Modifiers WorkThere are several important considerations about using the r, R,
and Rr modifiers: The
r modifier restricts only lower-case permissions.
For instance, administrative principals assigned the ird permissions cannot delete principals from their own realm
that are included in the admin_acl_file. Note that the r modifier does
not restrict upper-case permissions. For instance, administrative
principals assigned the IMimr permissions cannot
modify principals in their own realm that are included in the admin_acl_file,
but are able to modify any principal in all other realms supported
by the primary security server. The R modifier
restricts only upper-case letter permissions and only applies to
realms other than the administrative principal's realm. For
instance, administrative principals assigned the IRD permissions cannot
delete principals included in the admin_acl_file from
any other realm except their own. Note that IRDid is equivalent
to the IRD permissions because the upper-case permissions (not including
the r and R modifiers) apply to all realms. In either case, administrative principals can delete any principal from
their own realm, but have restricted delete privileges in realms other
than their own. As another example, administrative principals assigned the IDRm or IDRidm permissions
have restricted delete permissions in all other realms but not their
own, but can modify and delete any principal in their own realm. The Rr modifiers
restricts permissions for all principals in the admin_acl_file for
all realms supported by the primary security server. For example,
administrative principals assigned the IMRimr permission
cannot modify principals included in the admin_acl_file in
any realm, including their own. They can only modify principals
that are not included in the admin_acl_file. The e,
E, g, and G permissions
are not affected by the r, R,
and Rr modifiers. Administrative principals
assigned icr or ICRicr are
still able to change their own passwords using the administrative
tools. Permissions other than c and C are
restricted for the restricted administrative principals. For instance,
principals assigned with the imr permission
are not able to modify their own principal accounts. An administrative principal assigned the r or R in
combination with e or E can
use Administrator to remove the r modifier
from their admin_acl_file entry. Do not assign
these permission combinations. Some examples would be, ier, IER, IERr,
or IEr. Administrative principals
assigned the ic, icr,
IC or ICR permissions
are able to change principal attributes and extract service keys,
in addition to changing principal passwords. According to the
r and R modifier rules,
restricted administrators can only make perform these actions for
principal accounts not included in the admin_acl_file.
|
Printable version
