Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 81. Enabling AD users to administer IdM

81.1. ID overrides for AD users

In Red Hat Enterprise Linux (RHEL) 7, external group membership allows Active Directory (AD) users and groups to access Identity Management (IdM) resources in a POSIX environment with the help of the System Security Services Daemon (SSSD).

The IdM LDAP server has its own mechanisms to grant access control. RHEL 8 introduces an update that allows adding an ID user override for an AD user as a member of an IdM group. An ID override is a record describing what a specific Active Directory user or group properties should look like within a specific ID view, in this case the Default Trust View. As a consequence of the update, the IdM LDAP server is able to apply access control rules for the IdM group to the AD user.

AD users are now able to use the self service features of IdM UI, for example to upload their SSH keys, or change their personal data. An AD administrator is able to fully administer IdM without having two different accounts and passwords.

Note

Currently, selected features in IdM may still be unavailable to AD users. For example, setting passwords for IdM users as an AD user from the IdM admins group might fail.

Important

Do not use ID overrides of AD users for sudo rules in IdM. ID overrides of AD users represent only POSIX attributes of AD users, not AD users themselves.

81.2. Using ID overrides to enable AD users to administer IdM

This procedure describes creating and using an ID override for an AD user to give that user rights identical to those of an IdM user. During this procedure, work on an IdM server that is configured as a trust controller or a trust agent.

Prerequisites

  • The idm:DL1 stream is enabled on your Identity Management (IdM) server and you have switched to the RPMs delivered through this stream:

    # yum module enable idm:DL1
    # yum distro-sync
  • The idm:DL1/adtrust profile is installed on your IdM server.

    # yum module install idm:DL1/adtrust

    The profile contains all the packages necessary for installing an IdM server that will have a trust agreement with Active Directory (AD), including the ipa-idoverride-memberof package.

  • A working IdM environment is set up. For details, see Installing Identity Management.
  • A working trust between your IdM environment and AD is set up.

Procedure

  1. As an IdM administrator, create an ID override for an AD user in the Default Trust View. For example, to create an ID override for the ad_user@ad.example.com user:

    # kinit admin
    # ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com
  2. Add the ID override from the Default Trust View as a member to an IdM group. If the group in question is a member of an IdM role, the AD user represented by the ID override will gain all permissions granted by the role when using the IdM API, including both the command line interface and the IdM web UI. For example, to add the ID override for the ad_user@ad.example.com user to the admins group:

    # ipa group-add-member admins --idoverrideusers=ad_user@ad.example.com

81.3. Using Ansible to enable AD users to administer IdM

This section describes how to use an Ansible playbook to ensure that a user ID override is present in an Identity Management (IdM) group. The user ID override is the override of an Active Directory (AD) user that you created in the Default Trust View after you established a trust with AD. As a result of running the playbook, an AD user, for example an AD administrator, is able to fully administer IdM without having two different accounts and passwords.

Prerequisites

  • You know the IdM admin password.
  • You have installed a trust with AD.
  • The user ID override of the AD user already exists in IdM. If it does not, create it with the ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com command.
  • The group to which you are adding the user ID override already exists in IdM.
  • You are using the 4.8.7 version of IdM or later. To view the version of IdM you have installed on your server, enter ipa --version.
  • You have configured an Ansible control node that meets the following requirements:

    • You are using Ansible version 2.8 or later.
    • You have installed the ansible-freeipa package.
    • In the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server where you are configuring the group membership.

Procedure

  1. Navigate to your ~/MyPlaybooks/ directory:

    $ cd ~/MyPlaybooks/
  2. Create an add-useridoverride-to-group.yml playbook with the following content:

    ---
    - name: Playbook to ensure presence of users in a group
      hosts: ipaserver
      become: true
    
    
      - name: Ensure the ad_user@ad.example.com user ID override is a member of the admins group:
        ipagroup:
          ipaadmin_password: Secret123
          name: admins
          idoverrideuser:
          - ad_user@ad.example.com

    In the example:

    • Secret123 is the IdM admin password.
    • admins is the name of the IdM POSIX group to which you are adding the ad_user@ad.example.com ID override. Members of this group have full administrator privileges.
    • ad_user@ad.example.com is the user ID override of an AD administrator. The user is stored in the AD domain with which a trust has been established.
  3. Save the file.
  4. Run the Ansible playbook specifying the playbook file and the inventory file:

    $ ansible-playbook -v -i inventory add-useridoverride-to-group.yml

Additional resources

81.4. Managing IdM CLI as an AD user

This procedure checks that an Active Directory (AD) user can log into Identity Management (IdM) command-line interface (CLI) and run commands appropriate for his role.

  1. Destroy the current Kerberos ticket of the IdM administrator:

    # kdestroy -A
    Note

    The destruction of the Kerberos ticket is required because the GSSAPI implementation in MIT Kerberos chooses credentials from the realm of the target service by preference, which in this case is the IdM realm. This means that if a credentials cache collection, namely the KCM:, KEYRING:, or DIR: type of credentials cache is in use, a previously obtained admin or any other IdM principal’s credentials will be used to access the IdM API instead of the AD user’s credentials.

  2. Obtain the Kerberos credentials of the AD user for whom an ID override has been created:

    # kinit ad_user@AD.EXAMPLE.COM
    Password for ad_user@AD.EXAMPLE.COM:
  3. Test that the ID override of the AD user enjoys the same privileges stemming from membership in the IdM group as any IdM user in that group. If the ID override of the AD user has been added to the admins group, the AD user can, for example, create groups in IdM:

    # ipa group-add some-new-group
    ----------------------------
    Added group "some-new-group"
    ----------------------------
      Group name: some-new-group
      GID: 1997000011