manpagez: man pages & more
man kadm5.acl(5)
Home | html | info | man
kadm5.acl(5)                     MIT Kerberos                     kadm5.acl(5)


       kadm5.acl - Kerberos ACL file


       The  Kerberos  kadmind(8) daemon uses an Access Control List (ACL) file
       to manage access rights to the Kerberos database.  For operations  that
       affect  principals,  the  ACL  file  also controls which principals can
       operate on which other principals.

       The   default    location    of    the    Kerberos    ACL    file    is
       /opt/local/var/krb5kdc/kadm5.acl   unless  this  is  overridden  by the
       acl_file variable in kdc.conf(5).


       Empty lines and lines starting with the sharp  sign  (#)  are  ignored.
       Lines containing ACL entries have the format:

          principal  permissions  [target_principal  [restrictions] ]

          Line  order  in the ACL file is important.  The first matching entry
          will control access for an actor principal on a target principal.

              (Partially or fully qualified Kerberos principal  name.)  Speci-
              fies the principal whose permissions are to be set.

              Each component of the name may be wildcarded using the * charac-

              Specifies what operations may or may not be performed by a prin-
              cipal  matching  a particular entry.  This is a string of one or
              more of the following list of  characters  or  their  upper-case
              counterparts.   If  the character is upper-case, then the opera-
              tion is disallowed.  If the character is  lower-case,  then  the
              operation is permitted.

                              |a | [Dis]allows  the  addition |
                              |  | of principals or policies  |
                              |c | [Dis]allows  the  changing |
                              |  | of  passwords  for princi- |
                              |  | pals                       |
                              |d | [Dis]allows  the  deletion |
                              |  | of principals or policies  |
                              |e | [Dis]allows the extraction |
                              |  | of principal keys          |
                              |i | [Dis]allows      inquiries |
                              |  | about  principals or poli- |
                              |  | cies                       |
                              |l | [Dis]allows the listing of |
                              |  | all principals or policies |

                              |m | [Dis]allows the  modifica- |
                              |  | tion   of   principals  or |
                              |  | policies                   |
                              |p | [Dis]allows  the  propaga- |
                              |  | tion   of   the  principal |
                              |  | database     (used      in |
                              |  | incr_db_prop)              |
                              |s | [Dis]allows  the  explicit |
                              |  | setting of the key  for  a |
                              |  | principal                  |
                              |x | Short  for  admcilsp.  All |
                              |  | privileges (except e)      |
                              |* | Same as x.                 |

          The extract privilege is not included in the wildcard privilege;  it
          must  be  explicitly  assigned.   This  privilege allows the user to
          extract keys from the database, and must be handled with great  care
          to  avoid disclosure of important keys like those of the kadmin/* or
          krbtgt/* principals.  The lockdown_keys principal attribute  can  be
          used  to  prevent key extraction from specific principals regardless
          of the granted privilege.

              (Optional.  Partially  or  fully  qualified  Kerberos  principal
              name.)   Specifies  the  principal  on  which permissions may be
              applied.  Each component of the name may be wildcarded using the
              * character.

              target_principal  can also include back-references to principal,
              in which *number matches the corresponding wildcard  in  princi-

              (Optional) A string of flags. Allowed restrictions are:

                        flag  is forced to the indicated value.  The permissi-
                        ble flags are the same as those for the  default_prin-
                        cipal_flags variable in kdc.conf(5).

                        policy is forced to be empty.

                 -policy pol
                        policy is forced to be pol.

                 -{expire, pwexpire, maxlife, maxrenewlife} time
                        (getdate  string)  associated  value will be forced to
                        MIN(time, requested value).

              The above flags act as restrictions on any add or modify  opera-
              tion which is allowed due to that ACL line.

          If  the kadmind ACL file is modified, the kadmind daemon needs to be
          restarted for changes to take effect.


       Here is an example of a kadm5.acl file:

          */admin@ATHENA.MIT.EDU    *                               # line 1
          joeadmin@ATHENA.MIT.EDU   ADMCIL                          # line 2
          joeadmin/*@ATHENA.MIT.EDU i   */root@ATHENA.MIT.EDU       # line 3
          */root@ATHENA.MIT.EDU     ci  *1@ATHENA.MIT.EDU           # line 4
          */root@ATHENA.MIT.EDU     l   *                           # line 5
          sms@ATHENA.MIT.EDU        x   * -maxlife 9h -postdateable # line 6

       (line 1) Any principal  in  the  ATHENA.MIT.EDU  realm  with  an  admin
       instance has all administrative privileges except extracting keys.

       (lines  1-3)  The  user  joeadmin has all permissions except extracting
       keys with his admin  instance,  joeadmin/admin@ATHENA.MIT.EDU  (matches
       line  1).   He has no permissions at all with his null instance, joead-
       min@ATHENA.MIT.EDU (matches line 2).  His  root  and  other  non-admin,
       non-null  instances  (e.g.,  extra or dbadmin) have inquire permissions
       with any principal that has the instance root (matches line 3).

       (line 4) Any root principal in ATHENA.MIT.EDU can inquire or change the
       password  of  their  null  instance,  but  not any other null instance.
       (Here, *1 denotes a back-reference to the component matching the  first
       wildcard in the actor principal.)

       (line  5) Any root principal in ATHENA.MIT.EDU can generate the list of
       principals in the database, and the list of policies in  the  database.
       This  line is separate from line 4, because list permission can only be
       granted globally, not to specific target principals.

       (line   6)   Finally,   the   Service   Management   System   principal
       sms@ATHENA.MIT.EDU  has all permissions except extracting keys, but any
       principal that it creates or modifies will not be able to get postdate-
       able tickets or tickets with a life of longer than 9 hours.


       The  ACL  file  can coexist with other authorization modules in release
       1.16  and  later,  as  configured  in   the   kadm5_auth   section   of
       krb5.conf(5).   The  ACL  file  will  positively  authorize  operations
       according to the rules above, but will never  authoritatively  deny  an
       operation,  so  other  modules  can authorize operations in addition to
       those authorized by the ACL file.

       To  operate  without  an  ACL  file,  set  the  acl_file  variable   in
       kdc.conf(5) to the empty string with acl_file = "".


       kdc.conf(5), kadmind(8)




       1985-2018, MIT

1.16.2                                                            kadm5.acl(5)

kerberos5 1.16.2 - Generated Mon Nov 12 16:21:56 CST 2018
© 2000-2021
Individual documents may contain additional copyright information.