How to use the forms based login interface to give IPA admin access to selected federated users?
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
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 < freeipa-users@lists.fedorahosted.org> 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
"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
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org 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/freeipa-users@lists.fedorahoste...
Aha ! I was missing the Default Trust View work -- much appreciated!
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-truste...
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:
- 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
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 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-truste...
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:
- 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
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 dag@sonsorol.org 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 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-truste...
Chris Dagdigian 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:
- make group "corp_admins_external" populated with external
"username@domain.com" 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
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-truste...
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:
- 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
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 mailto:abokovoy@redhat.com 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-truste...
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:
- make group "corp_admins_external" populated with external >
"username@domain.com" 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 mailto:dag@sonsorol.org 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 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-truste...
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:
- 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
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 mailto:abokovoy@redhat.com 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-truste...
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:
- make group "corp_admins_external" populated with external >
"username@domain.com" 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 mailto:dag@sonsorol.org 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 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-truste...
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:
- 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
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 mailto:abokovoy@redhat.com 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 mailto:abokovoy@redhat.com 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-truste...
> > 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:
- 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
- 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 mailto:dag@sonsorol.org
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 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-truste...
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:
- make group "corp_admins_external" populated with external >
"username@domain.com" 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 mailto:dag@sonsorol.org 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 mailto:abokovoy@redhat.com 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-truste...
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:
- make group "corp_admins_external" populated with external >
"username@domain.com" 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 mailto:dag@sonsorol.org 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 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-truste...
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:
- 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
Alexander Bokovoy mailto:abokovoy@redhat.com 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-truste...
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:
- make group "corp_admins_external" populated with external >
"username@domain.com" 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 mailto:dag@sonsorol.org 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 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-truste...
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Chris Dagdigian -
David Sastre