Product SiteDocumentation Site

Chapter 17. Configuration: Defining Access Control within FreeIPA

17.1. About Access Controls for FreeIPA Entries
17.1.1. A Brief Look at Access Control Concepts
17.1.2. Access Control Methods in FreeIPA
17.2. Defining Self-Service Settings
17.2.1. Creating Self-Service Rules from the Web UI
17.2.2. Creating Self-Service Rules from the Command Line
17.2.3. Editing Self-Service Rules
17.3. Delegating Permissions over Users
17.3.1. Delegating Access to User Groups in the Web UI
17.3.2. Delegating Access to User Groups in the Command Line
17.4. Defining Role-Based Access Controls
17.4.1. Creating Roles
17.4.2. Creating New Permissions
17.4.3. Creating New Privileges
Access control is a security system which defines who can access certain resources — from machines to services to entries — and what kinds of operations they are allowed to perform. FreeIPA provides several access control areas to make it very clear what kind of access is being granted and to whom it is granted. As part of this, FreeIPA draws a distinction between access controls to resources within the domain and access control to the FreeIPA configuration itself.
This chapter details the different internal access control mechanisms that are available for users within FreeIPA to the FreeIPA server and other FreeIPA users.

17.1. About Access Controls for FreeIPA Entries

Access control defines the rights or permissions users have been granted to perform operations on other users or objects.

17.1.1. A Brief Look at Access Control Concepts

The FreeIPA access control structure is based on standard LDAP access controls. Access within the FreeIPA server is based on the FreeIPA users (who are stored in the backend Directory Server instance) who are allowed to access other FreeIPA entities (which are also stored as LDAP entries in the Directory Server instance).
An access control rule has three parts:
  • Who can perform the operation. This is the entity who is being granted permission to do something; this is the actor. In LDAP access control models, this is called the bind rule because it defines who the user is (based on their bind information) and can optionally require other limits on the bind attempt, such as restricting attempts to a certain time of day or a certain machine.
  • What can be accessed. This defines the entry which the actor is allowed to perform operations on. This is the target of the access control rule.
  • What type of operation can be performed. The last part is determining what kinds of actions the user is allowed to perform. The most common operations are add, delete, write, read, and search. In FreeIPA, all users are implicitly granted read and search rights to all entries in the FreeIPA domain, with restrictions only for sensitive attributes like passwords and Kerberos keys. (Anonymous users are restricted from seeing security-related configuration, like sudo rules and host-based access control.)
    The only rights which can be granted are add, delete, and write — the permissions required to modify an entry.


FreeIPA does not provide a way to grant read access explicitly, and this is an important distinction from standard LDAP access control rules. In LDAP, all operations, including read, are implicitly denied and must be explicitly granted. In FreeIPA, read and search access are implicitly granted to any authenticated user.
Because read access is already granted, there is no way through the UI to grant read access. However, there is an option in the CLI tools to grant read access for special cases where there may be a broad deny rule set but read access should be granted to specific attributes. For example, read access is blocked to password attributes, but could be allowed by a special read permission.
When any operation is attempted, the first thing that the FreeIPA client does is send user credentials as part of the bind operation. The backend Directory Server checks those user credentials and then checks the user account to see if the user has permission to perform the requested operation.

17.1.2. Access Control Methods in FreeIPA

To make access control rules simple and clear to implement, FreeIPA divides access control definitions into three categories:
  • Self-service rules, which define what operations a user can perform on his own personal entry. The access control type only allows write permissions to attributes within the entry; it does not allow add or delete operations for the entry itself.
  • Delegation rules, which allow a specific user group to perform write (edit) operations on specific attributes for users in another user group. Like self-service rules, this form of access control rule is limited to editing the values of specific attributes; it does not grant the ability to add or remove whole entries or control over unspecified attributes.
  • Role-based access control, which creates special access control groups which are then granted much broader authority over all types of entities in the FreeIPA domain. Roles can be granted edit, add, and delete rights, meaning they can be granted complete control over entire entries, not just selected attributes.
    Some roles are already created and available within FreeIPA. Special roles can be created to manage any type of entry in specific ways, such as hosts, automount configuration, netgroups, DNS settings, and FreeIPA configuration.