Thanks Alexander (you've been helpful for *years* on this list, much appreciated ...)

Looks like my issue was being unfamiliar with the CentOS/RHEL 8  "dnf" repo commands ...

For CentOS 8 the specific command was:

# dnf module install idm:DL1/adtrust

And for what it's worth installing the new plugin seems to hang forever if SELINUX is running and enabled; possibly because my order of installation did not set things up so the proper SELINUX policies could be set

The scriptlet: ipa-healthcheck-0.4-4.module_el8.2.0+374+0d2d74a1.noarch  hangs forever during the "dnf module install idm:DL1/adtrust" until you run these commands:

# ausearch -c 'java' --raw | audit2allow -M my-java
# semodule -X 300 -i my-java.pp

Out of paranoia I'm going to disable SELINUX while I test out allowing AD users to manage IPA just in case any other internal process or subsystem hits a SELINUX wall.

Regards
Chris


This was the sealert message:
SELinux is preventing java from read access on the directory hsperfdata_pkiuser.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that java should be allowed read access on the hsperfdata_pkiuser directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'java' --raw | audit2allow -M my-java
# semodule -X 300 -i my-java.pp


Additional Information:
Source Context                system_u:system_r:tomcat_t:s0
Target Context                unconfined_u:object_r:user_tmp_t:s0
Target Objects                hsperfdata_pkiuser [ dir ]
Source                        java
Source Path                   java
Port                          <Unknown>
Host                          ipa001.ipa.XXX.com
Source RPM Packages
Target RPM Packages
Policy RPM                    selinux-policy-3.14.3-41.el8_2.6.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     ipa001.ipa.XXX.com
Platform                      Linux ipa001.ipa.XXX.com
                              4.18.0-193.19.1.el8_2.x86_64 #1 SMP Mon Sep 14
                              14:37:00 UTC 2020 x86_64 x86_64
Alert Count                   22
First Seen                    2020-09-25 19:58:50 UTC
Last Seen                     2020-10-12 19:30:57 UTC
Local ID                      4bfba108-7f68-4ba5-b5dd-7c74575d31dc

Raw Audit Messages
type=AVC msg=audit(1602531057.835:299): avc:  denied  { read } for  pid=4643 comm="java" name="hsperfdata_pkiuser" dev="nvme0n1p2" ino=138422434 scontext=system_u:system_r:tomcat_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=dir permissive=0





Alexander Bokovoy
October 12, 2020 at 3:23 PM
On ma, 12 loka 2020, Chris Dagdigian via FreeIPA-users wrote:
Spoke too soon -- looks like FreeIPA 4.8.7 does not support the '--idoverrideusers' stuff shown on that URL:

Usage: ipa [global-options] group-add-member GROUP-NAME [options]


$ ipa group-add-member admins --idoverrideusers <rest of command>
Usage: ipa [global-options] group-add-member GROUP-NAME [options]

ipa: error: no such option: --idoverrideusers


Neither the group-add-member or the role-add-member seem to support the "--idoverrideuser" required to make this work.

Are the docs outdated or is my IPA version?

You need to be clear about your runtime environment.

FreeIPA 4.8.7+ is available in Fedora and RHEL 8.3 beta.

My understanding is that Ubuntu version does not support trust to Active
Directory due to linking issues with Heimdal in Ubuntu's version of
Samba.

In RHEL 8.2 the 'third-party' plugin that David talks about is installed
automatically when
 dnf module install idm:DL1/trust

is done.

Since that modifies server side API, a client side API cache needs to
expire or be cleaned. E.g.

  rm -rf ~/.cache/ipa/

needs to be done and then next run of 'ipa ...' CLI would re-acquire new
metadata for IPA API that should be able to show --idoverrideusers
command:

ipa group-add-member --help
Usage: ipa [global-options] group-add-member GROUP-NAME [options]

Add members to a group.
Options:
  -h, --help            show this help message and exit
  --external=STR        Members of a trusted domain in DOM\name or name@domain
                        form
  --all                 Retrieve and print all attributes from the server.
                        Affects command output.
  --raw                 Print entries as stored on the server. Only affects
                        output format.
  --no-members          Suppress processing of membership attributes.
  --users=STR           users to add
  --groups=STR          groups to add
  --services=STR        services to add
  --idoverrideusers=STR
                        User ID overrides to add



Thanks!

Chris


> David Sastre <mailto:d.sastre.medina@gmail.com>
> October 12, 2020 at 2:10 PM
> Does this help?
> > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-trusted-user.html#usage
> > Chris Dagdigian <mailto:dag@sonsorol.org>
> October 12, 2020 at 1:59 PM
> Hi folks,
> > I've got a three-node replicating FreeIPA cluster running in AWS with a > one-way trust to an Active Directory domain.
> > Things work well with respect to user overrides and RBAC rules affecting > client machines but I can't for the life of me figure out the order of > operations for allowing a couple of external AD users to have admin > access to the FreeIPA webUI itself.
> > There are 3 AD users I'd like to give WebUI admin access to.
> > So far I've tried the standard stuff I've used for non-IPA clients:
> > 1) make group "corp_admins_external" populated with external > "username@domain.com" identities
> 2) Make group "corp_admins_posix" populated with the > corp_admins_external group
> 3) Added corp_admins_posix group to the admin group
> > Best I've been able to do so far is give myself login access to just the > user self-service page and even then that failed until > oddjob-mkhomedir() was running and enabled under authconfig
> > Is there a guide or a documentation set specific to granting admin > access to the webUI for forms-based login users?
> > Thanks!
> > Chris
> >




Chris Dagdigian
October 12, 2020 at 2:31 PM
Spoke too soon -- looks like FreeIPA 4.8.7 does not support the '--idoverrideusers' stuff shown on that URL:

Usage: ipa [global-options] group-add-member GROUP-NAME [options]


$ ipa group-add-member admins --idoverrideusers <rest of command>
Usage: ipa [global-options] group-add-member GROUP-NAME [options]

ipa: error: no such option: --idoverrideusers


Neither the group-add-member or the role-add-member seem to support the "--idoverrideuser" required to make this work.

Are the docs outdated or is my IPA version?

Thanks!

Chris



David Sastre
October 12, 2020 at 2:10 PM
Does this help?

https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-trusted-user.html#usage

Chris Dagdigian
October 12, 2020 at 1:59 PM
Hi folks,

I've got a three-node replicating FreeIPA cluster running in AWS with a one-way trust to an Active Directory domain.

Things work well with respect to user overrides and RBAC rules affecting client machines but I can't for the life of me figure out the order of operations for allowing a couple of external AD users to have admin access to the FreeIPA webUI itself.

There are 3 AD users I'd like to give WebUI admin access to.

So far I've tried the standard stuff I've used for non-IPA clients:

1) make group "corp_admins_external" populated with external "username@domain.com" identities
2) Make group "corp_admins_posix" populated with the corp_admins_external group
3) Added corp_admins_posix group to the admin group

Best I've been able to do so far is give myself login access to just the user self-service page and even then that failed until oddjob-mkhomedir() was running and enabled under authconfig

Is there a guide or a documentation set specific to granting admin access to the webUI for forms-based login users?

Thanks!

Chris