How to use the forms based login interface to give IPA admin access to selected federated users?

[Chris Dagdigian]

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 
"[e-mail]" 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

[David Sastre]

Does this help?

https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...

On Mon, Oct 12, 2020 at 7:59 PM Chris Dagdigian via FreeIPA-users <
[e-mail]> wrote:
> 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:
> make group "corp_admins_external" populated with external
>
> "[e-mail]" 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
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...

[Chris Dagdigian]

Aha ! I was missing the Default Trust View work -- much appreciated!

Chris
> David Sastre 
> October 12, 2020 at 2:10 PM
> Does this help?
>
> https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
>
> 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:
> make group "corp_admins_external" populated with external
>
> "[e-mail]" 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]

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-truste...
>
> 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:
> make group "corp_admins_external" populated with external
>
> "[e-mail]" 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

[David Sastre]

I don't have a 4.8.7 installation to test this, but the release notes[1]
seem to indicate that this functionality should be available:

- 8357: Allow managing IPA resources as a user from a trusted Active
   Directory forest

A 3rd-party plugin to provide management of IPA resources as users from
trusted Active Directory domains was merged into FreeIPA core. ID user
overrides can now be added to IPA management groups and roles and thus
allow AD users to manage IPA.
The syntax may be different, though. You can try the `ipa role-add-member`
inline help.

[1]: https://www.freeipa.org/page/Releases/4.8.7

On Mon, Oct 12, 2020 at 8:31 PM Chris Dagdigian  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?
>
> 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-truste...
>
> 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:
> make group "corp_admins_external" populated with external
>
> "[e-mail]"  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

[Alexander Bokovoy]

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 
> > October 12, 2020 at 2:10 PM
> > Does this help?
> >
> > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
> >
> > 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:
> > make group "corp_admins_external" populated with external
> >
> > "[e-mail]" 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]

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

Thescriptlet: 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 
> > > October 12, 2020 at 2:10 PM
> > > Does this help?
> > > >
> >
> > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
> > > > 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:
> > > > make group "corp_admins_external" populated with external >
> >
> > "[e-mail]" identities
> > > Make group "corp_admins_posix" populated with the >
> >
> > corp_admins_external group
> > > 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-truste...
>
> 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:
> make group "corp_admins_external" populated with external
>
> "[e-mail]" 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

[Alexander Bokovoy]

On ma, 12 loka 2020, Chris Dagdigian wrote:
> 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
>
> Thescriptlet: 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.

Can you please share the exact selinux issues as reported by ausearch?
It may well be inconsistency in CentOS 8.2 rebuilds, especially if you
are trying to use CentOS Stream.

If it is only hsperfdata_pkiuser AVC as below, then it shouldn't be a
big deal and it shouldn't cause any serious issue. This can be ignored
-- it is writing down profiling data that might be used by Java VM but
can live without it.
> 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 
> > > > October 12, 2020 at 2:10 PM
> > > > Does this help?
> > > > > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
> > > > > 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:
> > > > > make group "corp_admins_external" populated with external >
> > >
> > > "[e-mail]" identities
> > > > Make group "corp_admins_posix" populated with the >
> > >
> > > corp_admins_external group
> > > > 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-truste...
> >
> > 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:
> > make group "corp_admins_external" populated with external
> >
> > "[e-mail]" 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]

I think you are right Alexander, the selinux was a false alarm. The 
scriptlet happened to complete exactly after I made the selinux changes 
after I got concerned it was stuck or hung on something; on my 3 other 
IPA systems I allowed the 'dnf module install idm:DL1/adtrust' command 
to run for as long as it liked; eventually both ran successfully to 
completion without me having to adjust things. I think the java process 
just took longer than I was expecting.

Can also confirm that I can login with my AD personae and see the admin 
webUI.

Regards
Chris
> Alexander Bokovoy 
> October 12, 2020 at 3:48 PM
> On ma, 12 loka 2020, Chris Dagdigian wrote:
> > 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
> >
> > Thescriptlet: 
> > 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.
>
> Can you please share the exact selinux issues as reported by ausearch?
> It may well be inconsistency in CentOS 8.2 rebuilds, especially if you
> are trying to use CentOS Stream.
>
> If it is only hsperfdata_pkiuser AVC as below, then it shouldn't be a
> big deal and it shouldn't cause any serious issue. This can be ignored
> -- it is writing down profiling data that might be used by Java VM but
> can live without it.
> > 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
> > > > >
> > > > > October 12, 2020 at 2:10 PM
> > > > > Does this help?
> > > > > >
> >
> > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
> > > > > > > > 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:
> > > > > > make group "corp_admins_external" populated with external
> > > > >
> > > > > "[e-mail]" identities
> > > > > 2) Make group "corp_admins_posix" populated with the > > >
> >
> > corp_admins_external group
> > > > > 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-truste...
> > > > 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:
> > > > make group "corp_admins_external" populated with external >
> >
> > "[e-mail]" identities
> > > Make group "corp_admins_posix" populated with the >
> >
> > corp_admins_external group
> > > 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 3:35 PM
> 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
>
> Thescriptlet: 
> 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 
> > > > October 12, 2020 at 2:10 PM
> > > > Does this help?
> > > > >
> > >
> > > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
> > > > > 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:
> > > > > make group "corp_admins_external" populated with external >
> > >
> > > "[e-mail]" identities
> > > > Make group "corp_admins_posix" populated with the >
> > >
> > > corp_admins_external group
> > > > 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-truste...
> >
> > 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:
> > make group "corp_admins_external" populated with external
> >
> > "[e-mail]" 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
>
> 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 
> > > October 12, 2020 at 2:10 PM
> > > Does this help?
> > > >
> >
> > https://freeipa.readthedocs.io/en/latest/designs/adtrust/admin-ipa-as-truste...
> > > > 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:
> > > > make group "corp_admins_external" populated with external >
> >
> > "[e-mail]" identities
> > > Make group "corp_admins_posix" populated with the >
> >
> > corp_admins_external group
> > > 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-truste...