Chapter 50. Enabling AD users to administer IdM


50.1. ID overrides for AD users

You can centrally manage access of Active Directory (AD) users and groups to Identity Management (IdM) resources in a POSIX environment by 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. With this feature, the IdM LDAP server is able to apply access control rules for the IdM group to the AD user.

AD users can 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.

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

Follow this procedure to create and use 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

  • 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 user ad_user@ad.example.com:

    # kinit admin
    # ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com
    Copy to Clipboard
  2. Add the ID override from the Default Trust View as a member of an IdM group. This must be a non-POSIX group, as it interacts with Active Directory.

    If the group in question is a member of an IdM role, the AD user represented by the ID override gains 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 IdM admins group:

    # ipa group-add-member admins --idoverrideusers=ad_user@ad.example.com
    Copy to Clipboard
  3. Alternatively, you can add the ID override to a role, such as the User Administrator role:

    # ipa role-add-member 'User Administrator' --idoverrideusers=ad_user@ad.example.com
    Copy to Clipboard

50.3. Verifying that an AD user can perform correct commands in the IdM CLI

This procedure checks that an {AD} (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
    Copy to Clipboard
    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:
    Copy to Clipboard
  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
    Copy to Clipboard

50.4. Using Ansible to enable an AD user to administer IdM

You can use the ansible-freeipa idoverrideuser and group modules to create a user ID override for an {AD} (AD) user from a trusted AD domain and give that user rights identical to those of an IdM user. The procedure uses the example of the Default Trust View ID view to which the administrator@addomain.com ID override is added in the first playbook task. In the next playbook task, the administrator@addomain.com ID override is added to the IdM admins group as a member. As a result, an AD administrator can administer IdM without having two different accounts and passwords.

Prerequisites

  • You have configured your Ansible control node to meet the following requirements:

    • You are using Ansible version 2.15 or later.
    • You have installed the freeipa.ansible_freeipa collection.
    • The example assumes that in the ~/MyPlaybooks/ directory, you have created an Ansible inventory file with the fully-qualified domain name (FQDN) of the IdM server.
    • The example assumes that the secret.yml Ansible vault stores your ipaadmin_password and that you have access to a file that stores the password protecting the secret.yml file.
  • The ipaserver host in the inventory file is configured as a trust controller or a trust agent.
  • The target node, that is the node on which the freeipa.ansible_freeipa module is executed, is part of the IdM domain as an IdM client, server or replica.

Procedure

  1. On your Ansible control node, create an enable-ad-admin-to-administer-idm.yml playbook with a task to add the administrator@addomain.com user override to the Default Trust View:

    ---
    - name: Enable AD administrator to act as a FreeIPA admin
      hosts: ipaserver
      become: false
      gather_facts: false
    
      tasks:
      - name: Ensure idoverride for administrator@addomain.com in 'default trust view'
        ipaidoverrideuser:
          ipaadmin_password: "{{ ipaadmin_password }}"
          idview: "Default Trust View"
          anchor: administrator@addomain.com
    Copy to Clipboard
  2. Use another playbook task in the same playbook to add the AD administrator user ID override to the admins group:

      - name: Add the AD administrator as a member of admins
        ipagroup:
          ipaadmin_password: "{{ ipaadmin_password }}"
          name: admins
          idoverrideuser:
          - administrator@addomain.com
    Copy to Clipboard
  3. Save the file.
  4. Run the Ansible playbook. Specify the playbook file, the file storing the password protecting the secret.yml file, and the inventory file:

    $ ansible-playbook --vault-password-file=password_file -v -i inventory enable-ad-admin-to-administer-idm.yml
    Copy to Clipboard

Verification

  1. Log in to the IdM client as the AD Administrator:

    $ ssh administrator@addomain.com@client.idm.example.com
    Copy to Clipboard
  2. Verify that you have obtained a valid ticket-granting ticket (TGT):

    $ klist
    Ticket cache: KCM:325600500:99540
    Default principal: Administrator@ADDOMAIN.COM
    Valid starting Expires Service principal
    02/04/2024 11:54:16 02/04/2024 21:54:16 krbtgt/ADDOMAIN.COM@ADDOMAIN.COM
    renew until 02/05/2024 11:54:16
    Copy to Clipboard
  3. Verify your admin privileges in IdM:

    $ ipa user-add testuser --first=test --last=user
    ------------------------
    Added user "tuser"
    ------------------------
      User login: tuser
      First name: test
      Last name: user
      Full name: test user
    [...]
    Copy to Clipboard
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat