Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
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 op-
       erate on	which other principals.

       The  default  location  of  the	 Kerberos   ACL	  file	 is   /usr/lo-
       cal/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  ex-
	  tract	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  ap-
	      plied.  Each component of	the name may be	wildcarded using the *

	      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 in-
       stance 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  ac-
       cording	to the rules above, but	will never authoritatively deny	an op-
       eration,	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-2020, MIT

1.20								  KADM5.ACL(5)


Want to link to this manual page? Use this URL:

home | help