| Identity Management GuideChapter 17. Policy: Defining Automatic Group Membership for Users and HostsMost of the policies and configuration within the Identity Management domain are based on groups. Settings from sudo rules to automount to access control are defined for groups, and then those settings are applied to group members. Managing group membership is an important factor in managing users and hosts. Creating automember groups defines rules to add users and hosts to specified groups automatically, as soon as a new entry is added. 17.1. About AutomembershipOne of the most critical tasks for managing policies, identities, and security is managing group membership in Identity Management. Groups are the core of most policy configuration. By default, hosts do not belong to any group when they are created; users are added to the catchall ipausers group. Even if custom groups are configured and all policy configuration is in place, users and hosts cannot take advantage of those policies until they are joined to groups. Of course, this can be done manually, but it is both more efficient and more consistent if group membership can be assigned automatically. This is done with automembership groups. Automembership is essentially an automatic, global entry filter that organizes entries, at least in part, based on specific criteria. An automember rule, then, is the way that that filter is specified. For example, there can be a lot of different, repeatable ways that to categorize identities within the IT and organizational environment: Adding all hosts or all users to a single global group. Adding employees to specific groups based on their employee type, ID number, manager, or physical location. Dividing hosts based on their IP address or subnet.
Automembers provide a way to pre-sort those entries. That makes it easier to configure the actual behavior that you want to configure - like granting different sudo rules to different user types or machines on different subnets or have different automount settings for different users. Automembership only applies to new users or groups. Changing the configuration on an existing user or group does not affect group membership, either by adding or removing the user/host in the group. Automembership is a flag or a target set on an existing user group or host group. An automembership rule is created as a policy. This is a sister entry to the actual group entry and it signals that the given group is used for automatic group membership. Once the rule is created - once the group is identified as being a target - then the next step is to define automember conditions. Conditions are regular expression filters that are used to identify group members. Conditions can be inclusive or exclusive, meaning that matching entries can be added or ignored based on those conditions. There can be multiple conditions in a single rule. A user or host entry can match multiple rules and be added to multiple groups. Automembership is a way of imposing reliable order on user and host group entries as they are created. The key to using automember groups effectively is to plan your overall Identity Management structure - the access control policies, sudo rules, host/service management rules, host groups, and user groups. Once the structure is in place, then several things are clear: What groups will be used in the Identity Management What specific groups different types of users and hosts need to belong to to perform their designated functions What delineating attributes can be used to filter users and hosts into the appropriate groups
17.2. Defining Automembership Rules (Basic Procedure) Open the Policy tab, and select the Automembers subtab. In the top of the Automembers area, select the type of autogroup to create, either USER GROUP RULES or HOST GROUP RULES. In the drop-down menu, select the group for which to create the automember rule. Click the Add and Edit button. In the edit page for the rule, click the + Add by the type of condition to create to identify entries. Select the attribute to use as the basis for the search and then set the regular expression to use to match the attribute value. Conditions can look for entries either to include in the group or to explicitly exclude from the group. The format of a condition is a Perl-compatible regular expression (PCRE). For more information on PCRE patterns, see the pcresyntax(3) man page. Exclude conditions are evaluated first and take precedence over include conditions. Click Add and Add Another to add another condition. A single rule can have multiple include and exclude conditions. When all conditions have been configured, click the Add button to save the last condition and close the dialog window. There are two commands used to define an automember policy: A command to flag the group as an automember group, automember-add A command to add regular expression conditions to identify group members, automember-add-condition
For example: Create the automember policy entry for the group. Use the --type to identify whether the target group is a user group (group) or a host group (hostgroup). This command has the format: ipa automember-add --type=group|hostgroup groupName For example: [jsmith@server ~]$ ipa automember-add --type=group exampleGroup Create the conditions for the rule. To set multiple patterns, either give a comma-separated list of patterns in the --inclusive-regex|--exclusive-regex options or run the command multiple times. This command has the format: ipa automember-add-condition --type=group|hostgroup --key=attribute --inclusive-regex=regex | --exclusive-regex=regex groupName As with the automember rule, the condition must specify the type of group (--type) and the name of the target group (groupName). The condition must also specify the attribute (the key) and any patterns for the attribute value. The --key is the attribute name that is the focus of the condition. Then, there is a regular expression pattern to identify matching values; matching entries can either be included (--inclusive-regex) or excluded (--exclusive-regex) from the group. Exclusion rules take precedence. For example, to include all employees with Barbara Jensen as a manager, but excluding the temporary employees: [jsmith@server ~]$ ipa automember-add-condition --type=group --key=manager --inclusive-regex=^uid=bjensen$ exampleGroup[jsmith@server ~]$ ipa automember-add-condition --type=group --key=employeetype --exclusive-regex=^temp exampleGroup The regular expression can match any port of the string. Using a caret (^) means that it must match at the beginning, and using a dollar sign ($) means that it must match at the end. Wrapping the pattern in ^ and $ means that it must be an exact match. To remove a condition for a rule, pass the full condition information, both the key and the regular expression: [jsmith@server ~]$ ipa automember-remove-condition --key=fqdn --type=hostgroup --inclusive-regex=^web[1-9]+\.example\.com webservers To remove the entire rule, simply run the automember-del command. 17.3. Examples of Using Automember GroupsThese examples are shown using the CLI; the same configuration can be performed in the web UI. All entries can be added to a single, global group regardless of what other groups they are also added to. Entries can be added to specific automember groups. If the new entry does not match any autogroup, then it is added to a default or fallback group.
These strategies are mutually exclusive. If an entry matches a global group, then it does match an automember group and would, therefore, not be added to the fallback group. 17.3.1. Setting an All Users/Hosts RuleTo add all users or all hosts to a single group, use an inclusive regular expression for some attribute (such as cn or fqdn) which all entries will contain. A regular expression to match all entries is simply .*. For example, to add all hosts to the same host group: [jsmith@server ~]$ ipa automember-add-condition --type=hostgroup allhosts --inclusive-regex=.* --key=fqdn--------------------------------Added condition(s) to "allhosts"-------------------------------- Automember Rule: allhosts Inclusive Regex: fqdn=.*----------------------------Number of conditions added 1---------------------------- Every host added after that is automatically added to the allhosts group: [jsmith@server ~]$ ipa host-add test.example.com-----------------------------Added host "test.example.com"----------------------------- Host name: test.example.com Principal name: host/[email protected] Password: False Keytab: False Managed by: test.example.com[jsmith@server ~]$ ipa hostgroup-show allhosts Host-group: allhosts Description: Default hostgroup Member hosts: test.example.com 17.3.2. Defining Default Automembership GroupsThere is a special command to set a default group, automember-default-group-set. This sets the group name (--default-group) and group type(--type), similar to an automember rule, but there is no condition to match. By definition, default group members are unmatched entries. For example: [jsmith@server ~]$ ipa automember-default-group-set --default-group=ipaclients --type=hostgroup[jsmith@server ~]$ ipa automember-default-group-set --default-group=ipausers --type=group A default group rule can be removed using the automember-default-group-remove command. Since there is only one default group for a group type, it is only necessary to give the group type, not the group name: [jsmith@server ~]$ ipa automember-default-group-remove --type=hostgroup 17.3.3. Using Automembership Groups with Windows UsersWhen a user is created in IdM, that user is automatically added as a member to the ipausers group (which is the default group for all new users, apart from any automember group). However, when a Windows user is synced over from Active Directory, that user is not automatically added to the ipausers group. New Windows users can be added to the ipausers group, as with users created in Identity Management, by using an automember group. Every Windows user is added with the ntUser object class; that object class can be used as an inclusive filter to identify new Windows users to add to the automember group. First, define the ipausers group as an automember group: [jsmith@server ~]$ ipa automember-add --type=group ipausers Then, use the ntUser object class as a condition to add users: [jsmith@server ~]$ ipa automember-add-condition ipausers --key=objectclass --type=group --inclusive-regex=ntUser Chapter 18. Configuration: Defining Access Control within IdMAccess 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. Identity Management 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, Identity Management draws a distinction between access controls to resources within the domain and access control to the IdM configuration itself. This chapter details the different internal access control mechanisms that are available for users within IdM to the IdM server and other IdM users. 18.1. About Access Controls for IdM EntriesAccess control defines the rights or permissions users have been granted to perform operations on other users or objects. 18.1.1. A Brief Look at Access Control ConceptsThe Identity Management access control structure is based on standard LDAP access controls. Access within the IdM server is based on the IdM users (who are stored in the backend Directory Server instance) who are allowed to access other IdM 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 Identity Management, all users are implicitly granted read and search rights to all entries in the IdM 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.
Identity Management 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 IdM, 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 IdM 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. 18.1.2. Access Control Methods in Identity ManagementTo make access control rules simple and clear to implement, Identity Management 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 IdM 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 Identity Management. Special roles can be created to manage any type of entry in specific ways, such as hosts, automount configuration, netgroups, DNS settings, and IdM configuration.
18.2. Defining Self-Service SettingsSelf-service access control rules define the operations that an entity can perform on itself. These rules define only what attributes a user (or other IdM entity) can edit on their personal entries. Two self-service rules exist by default: A rule for editing some general attributes in the personal entry, including given name and surname, phone numbers, and addresses. A rule to edit user passwords, including two Samba passwords, the Kerberos password, and the general user password.
18.2.1. Creating Self-Service Rules from the Web UIOpen the IPA Server tab in the top menu, and select the Self Service Permissions subtab. Click the Add link at the top of the list of self-service ACIs. Enter the name of the rule in the pop-up window. Spaces are allowed. Select the checkboxes by the attributes which this ACI will permit users to edit. Click the Add button to save the new self-service ACI.
18.2.2. Creating Self-Service Rules from the Command LineA new self-service rule can be added using the selfservice-add command. There are two required options, --permissions to set whether the ACI grants write, add, or delete permission and --attrs to give the full list of attributes which this ACI grants permission to. $ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname,displayname,title,initials-----------------------------------------------------------Added selfservice "Users can manage their own name details"----------------------------------------------------------- Self-service name: Users can manage their own name details Permissions: write Attributes: givenname, displayname, title, initials 18.2.3. Editing Self-Service RulesIn the self-service entry in the web UI, the only element that can be edited is the list of attributes that are included in the ACI. The checkboxes can be selected or deselected. With the command line, self-service rules are edited using the ipa selfservice-mod command. The --attrs option overwrites whatever the previous list of supported attributes was, so always include the complete list of attributes along with any new attributes. $ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname,displayname,title,initials,surname--------------------------------------------------------------Modified selfservice "Users can manage their own name details"--------------------------------------------------------------Self-service name: Users can manage their own name detailsPermissions: writeAttributes: givenname, displayname, title, initials Include all of the attributes when modifying a self-service rule, including existing ones. 18.3. Delegating Permissions over UsersDelegation is very similar to roles in that one group of users is assigned permission to manage the entries for another group of users. However, the delegated authority is much more similar to self-service rules in that complete access is granted but only to specific user attributes, not to the entire entry. Also, the groups in delegated authority are existing IdM user groups instead of roles specifically created for access controls. 18.3.1. Delegating Access to User Groups in the Web UIOpen the IPA Server tab in the top menu, and select the Delegations subtab. Click the Add link at the top of the list of delegation ACIs. Name the new delegation ACI. In the User group drop-down menu, select the group whose entries can be edited by members of the delegation group. In the Member user group drop-down menu, select the group who is being granted permissions to the entries of users in the user group. In the attributes box, select the checkboxes by the attributes to which the member user group is being granted permission. Click the Add button to save the new delegation ACI.
18.3.2. Delegating Access to User Groups in the Command LineA new delegation access control rule is added using the delegation-add command. There are three required arguments: --group, the group who is being granted permissions to the entries of users in the user group.
--membergroup, the group whose entries can be edited by members of the delegation group.
--attrs, the attributes which users in the member group are allowed to edit.
For example: $ ipa delegation-add "basic manager attrs" --attrs=manager,title,employeetype,employeenumber --group=engineering_managers --membergroup=engineering--------------------------------------Added delegation "basic manager attrs"-------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber Member user group: engineering User group: engineering_managers Delegation rules are edited using the delegation-mod command. The --attrs option overwrites whatever the previous list of supported attributes was, so always include the complete list of attributes along with any new attributes. $ ipa delegation-mod "basic manager attrs" --attrs=manager,title,employeetype,employeenumber,displayname-----------------------------------------Modified delegation "basic manager attrs"----------------------------------------- Delegation name: basic manager attrs Permissions: write Attributes: manager, title, employeetype, employeenumber, displayname Member user group: engineering User group: engineering_managers Include all of the attributes when modifying a delegation rule, including existing ones. 18.4. Defining Role-Based Access ControlsRole-based access control grants a very different kind of authority to users compared to self-service and delegation access controls. Role-based access controls are fundamentally administrative, with the potential to add, delete, and significantly modify entries. There are three parts to role-based access controls: The permission. The permission defines a specific operation or set of operations (write, add, or delete) and the target entries within the IdM LDAP directory to which those operations apply. Permissions are building blocks; they can be assigned to multiple privileges as needed. The privileges available to a role. A privilege is essentially a group of permissions. Permissions are not applied directly to a role. Permissions are added to a privilege so that the privilege creates a coherent and complete picture of a set of access control rules. For example, a permission can be created to add, edit, and delete automount locations. Then that permission can be combined with another permission relating to managing FTP services, and they can be used to create a single privilege that relates to managing filesystems. The role. This is the list of IdM users who are able to perform the actions defined in the privileges.
It is possible to create entirely new permissions, as well as to create new privileges based on existing permissions or new permissions. A list of the default privileges and their associated permissions are in Table 18.1, "Privileges and Permissions in IdM". Identity Management 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 IdM, 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. Table 18.1. Privileges and Permissions in IdM | Privilege | Associated Permissions |
|---|
| Automount Administrators | | Add_Automount_maps | | Remove_Automount_maps | | Add_Automount_keys | | Remove_Automount_keys |
| | Certificate Administrators | | Retrieve_Certificates_from_the_CA | | Request_Certificate | | Request_Certificates_from_a_different_hos | | Get_Certificates_status_from_the_CA | | Revoke_Certificate | | Certificate_Remove_Hold |
| | Delegation Administrator | | Add_Roles | | Remove_Roles | | Modify_Roles | | Modify_Role_membership | | Modify_privilege_membership |
| | DNS Administrators (for users) | | add_dns_entries | | remove_dns_entries | | update_dns_entries |
| | DNS Servers (for machines) | | add_dns_entries | | remove_dns_entries | | update_dns_entries |
| | Group Administrators | | Add_Groups | | Remove_Groups | | Modify_Groups | | Modify_Group_membership |
| | HBAC Administrator | | Add_HBAC_rule | | Delete_HBAC_rule | | Modify_HBAC_rule | | Manage_HBAC_rule_membership | | Add_HBAC_services | | Delete_HBAC_services | | Add_HBAC_service_groups | | Delete_HBAC_service_groups | | Manage_HBAC_service_group_membership |
| | Host Administrators | | Add_Hosts | | Remove_Hosts | | Modify_Hosts | | Manage_host_keytab | | Enroll_a_host | | Add_krbPrincipalName_to_a_host |
| | Host Enrollment | | Manage_host_keytab | | Enroll_a_host | | Add_krbPrincipalName_to_a_host |
| | Host Group Administrators | | Add_Hostgroups | | Remove_Hostgroups | | Modify_Hostgroups | | Modify_Hostgroup_membership |
| | Modify Users and Reset Passwords | | | Netgroups Administrators | | Add_netgroups | | Remove_netgroups | | Modify_netgroups | | Modify_netgroup_membership |
| | Password Policy Administrator | | Add_Group_Password_Policy_costemplate | | Delete_Group_Password_Policy_costemplate | | Modify_Group_Password_Policy_costemplate | | Add_Group_Password_Policy | | Delete_Group_Password_Policy | | Modify_Group_Password_Policy |
| | Replication Administrators | | Add_Replication_Agreements | | Remove_Replication_Agreements | | Modify_Replication_Agreements |
| | Service Administrators | | Add_Services | | Remove_Services | | Modify_Services | | Manage_service_keytab |
| | Sudo Administrator | | Add_Sudo_rule | | Delete_Sudo_rule | | Modify_Sudo_rule | | Add_Sudo_command | | Delete_Sudo_command | | Modify_Sudo_command | | Add_Sudo_command_group | | Delete_Sudo_command_group | | Manage_Sudo_command_group_membership |
| | User Administrators | | Change_a_user_password | | Add_user_to_default_group | | Unlock_user_accounts | | Remove_Users | | Modify_Users | | Add_Users |
| | Write IPA Configuration | |
18.4.1.1. Creating Roles in the Web UIOpen the IPA Server tab in the top menu, and select the Role Based Access Control subtab. Click the Add link at the top of the list of role-based ACIs. Enter the role name and a description. Click the Add and Edit button to save the new role and go to the configuration page. Open the Privileges tab in the role configuration page. Click the Add link at the top of the list of privileges to add a new privilege. Enter the role name and a description.
18.4.1.2. Creating Roles in the Command LineAdd the new role: # ipa role-add --desc="User Administrator" useradmin ------------------------ Added role "useradmin" ------------------------ Role name: useradmin Description: User Administrator Add the required privileges to the role: # ipa role-add-privilege --privileges="User Administrators" useradmin Role name: useradmin Description: User Administrator Privileges: user administrators ---------------------------- Number of privileges added 1---------------------------- Add the required groups to the role. In this case, we are adding only a single group, useradmin, which already exists. # ipa role-add-member --groups=useradmins useradmin Role name: useradmin Description: User Administrator Member groups: useradmins Privileges: user administrators ------------------------- Number of members added 1-------------------------
18.4.2. Creating New Permissions Identity Management 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 IdM, 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. 18.4.2.1. Creating New Permissions from the Web UIOpen the IPA Server tab in the top menu, and select the Role Based Access Control subtab. Select the Permissions task link. Click the Add link at the top of the list of permissions. Enter the name of the new permission. Select the checkboxes next to the allowed operations for this permission. Select the method to use to identify the target entries from the Target drop-down menu. There are four different methods: Type looks for an entry type like user, host, or service and then provides a list of all possible attributes for that entry type. The attributes which will be accessible through this ACI are selected from the list. Filter uses an LDAP filter to identify which entries the permission applies to. Subtree targets every entry beneath the specified subtree entry. All attributes within the matching entries can be modified. Target group specifies a user group, and all the user entries within that group are available through the ACI. All attributes within the matching entries can be modified.
For Filter, Subtree, and Target group methods, no attributes are set in the UI. These must be added later using ipa permission-mod --attrs. If no attributes are set for the permission then, by default, all attributes are excluded. Fill in the required information to identify the target entries, depending on the selected type. Click the Add button to save the permission. For Filter, Subtree, and Target group methods, set the attributes for the ACI to include. This must be done from the command line. For example: [jsmith@ipaserver ~]$ ipa permission-mod "manage Windows groups" --attrs=description,member
18.4.2.2. Creating New Permissions from the Command LineA new permission is added using the permission-add command. All permissions require a list of attributes over which permission is granted (--attr), a list of allowed actions (--permissions), and the target entries for the ACI. There are four methods to identify the target entries: --type looks for an entry type like user, host, or service and then provides a list of all possible attributes for that entry type. --filter uses an LDAP filter to identify which entries the permission applies to. --subtree targets every entry beneath the specified subtree entry. --targetgroup specifies a user group, and all the user entries within that group are available through the ACI.
Example 18.1. Adding a Permission with a Filter A filter can be any valid LDAP filter. $ ipa permission-add "manage Windows groups" --filter="(!(objectclass=posixgroup))" --permissions=write --attrs=description The permission-add command does not validate the given LDAP filter. Verify that the filter returns the expected results before configuring the permission. Example 18.2. Adding a Permission for a Subtree All a subtree filter requires is a DN within the directory. Since IdM uses a simplified, flat directory tree structure, this can be used to target some types of entries, like automount locations, which are containers or parent entries for other configuration. $ ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com" --permissions=write --attrs=automountmapname,automountkey,automountInformation Example 18.3. Adding a Permission Based on Object Type There seven object types that can be used to form a permission: user group host service hostgroup netgroup dnsrecord
Each type has its own set of allowed attributes, in a comma-separated list. $ ipa permission-add "manage service" --permissions=all --type=service --attrs=krbprincipalkey,krbprincipalname,managedby The attributes (--attrs) must exist and be allowed attributes for the given object type, or the permission operation fails with schema syntax errors. 18.4.3. Creating New Privileges18.4.3.1. Creating New Privileges from the Web UIOpen the IPA Server tab in the top menu, and select the Role Based Access Control subtab. Select the Privileges task link. Click the Add link at the top of the list of privileges. Enter the name and a description of the privilege. Click the Add and Edit button to go to the privilege configuration page to add permissions. Select the Permissions tab. Click the Add link at the top of the list of permissions to add permission to the privilege. Click the checkbox by the names of the permissions to add, and click the right arrows button, >>, to move the permissions to the selection box. Click the Add button.
18.4.3.2. Creating New Privileges from the Command LinePrivilege entries are created using the privilege-add command, and then permissions are added to the privilege group using the privilege-add-permission command. Create the privilege entry. $ ipa privilege-add "managing filesystems" --desc="for filesystems" Assign the desired permissions. For example: $ ipa privilege-add-permission "managing filesystems" --permissions="managing automount","managing ftp services"
|
| |
