When a user signs in to FreeIPA, I do not want them to be able to view the list of users in my LDAP server under the "Active users" link. I still want them to be able to administer self-service, so they can reset their password, add OTP tokens, etc. How would I go about doing this? The users will only be able to access the web interface, so it doesn't matter whether they can access it from other sources.
On 12/11/18 1:36 AM, cdknight via FreeIPA-users wrote:
When a user signs in to FreeIPA, I do not want them to be able to view the list of users in my LDAP server under the "Active users" link. I still want them to be able to administer self-service, so they can reset their password, add OTP tokens, etc. How would I go about doing this? The users will only be able to access the web interface, so it doesn't matter whether they can access it from other sources. _______________________________________________ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Hi,
this topic has already been discussed in issue 2995: [RFE] Add option to limit the scope of the DS objects user can see in self service [1] and in this thread [2]. This may help understand why self-service WebUI allows to see other users.
You may be able to define ACIs preventing a user from seeing other users' information but this would have to be thoroughly tested as it could break a lot of assumptions done by IPA.
HTH, flo
[1] https://pagure.io/freeipa/issue/2995 [2] https://www.redhat.com/archives/freeipa-users/2016-April/msg00107.html
On ti, 11 joulu 2018, cdknight via FreeIPA-users wrote:
When a user signs in to FreeIPA, I do not want them to be able to view the list of users in my LDAP server under the "Active users" link. I still want them to be able to administer self-service, so they can reset their password, add OTP tokens, etc. How would I go about doing this? The users will only be able to access the web interface, so it doesn't matter whether they can access it from other sources.
There is no way to restrict that. We keep getting this question all the time and we consider it is to be a security through obscurity, not a real one.
Every enrolled IPA client has to be able to query IPA LDAP for information about users, groups, hosts, sudo rules, etc. This already gives users a way to retrieve an information you are trying to hide in a Web UI.
If user is able to login to web UI, she would be able to use IPA CLI on the enrolled IPA clients too. Even without IPA CLI on the enrolled clients, she would be able to issue JSON-RPC commands -- either with command line from any machine or right from the browser's console.
You can read archives (make sure go through the whole threads): https://www.redhat.com/archives/freeipa-users/2016-March/msg00053.html https://www.redhat.com/archives/freeipa-users/2016-April/msg00118.html
Hi, I'm writing here because, 6 years after, I have the same question cknight previously asked.
Any update on that?
My users only login to web UI and can't perform ldap search so the only way they can obtain users info it's from the "Users" page ("#/e/user/details/userame") I understand this question could sound odd, but in Europe we have many laws protecting users privacy and these info can not be published.
Thank you for your help. Riccardo
On Пан, 25 сак 2024, Riccardo Rotondo via FreeIPA-users wrote:
Hi, I'm writing here because, 6 years after, I have the same question cknight previously asked.
Any update on that?
My users only login to web UI and can't perform ldap search so the only way they can obtain users info it's from the "Users" page ("#/e/user/details/userame") I understand this question could sound odd, but in Europe we have many laws protecting users privacy and these info can not be published.
I'd repeat my response recently from a different thread:
-------------------------------------------- What changed since that time, is that Fedora project has created Noggin, https://github.com/fedora-infra/noggin, a self-service portal for user management on top of FreeIPA deployment. You might want to look at that and use it instead. --------------------------------------------
You may consider not exposing the FreeIPA web UI to regular users at all.
Hi Alexander,
Thank you Alexander, this solution probably fits our needs. My only problem now is the I configured freeipa with docker, and in that image developer didn't include the Fedora Account System plugin for IPA so in the log I found:
ERROR in middleware: Uncaught IPA exception: Unknown option: fasgroup
I'll check with them if I can add this plug in post installation.
Regards, Riccardo
On 04/04/2024 13.24, Riccardo Rotondo via FreeIPA-users wrote:
Hi Alexander,
Thank you Alexander, this solution probably fits our needs. My only problem now is the I configured freeipa with docker, and in that image developer didn't include the Fedora Account System plugin for IPA so in the log I found:
ERROR in middleware: Uncaught IPA exception: Unknown option: fasgroup
I'll check with them if I can add this plug in post installation.
You can add the plugin to an existing installation. For a normal installation of FreeIPA, `dnf install freeipa-fas` just works. The package runs ipa-server-upgrade and restarts ipa.service in the posttrans scriplet.
It appears that does not work for containers. You need to figure out how to run ipa-server-upgrade while the container is running.
On Чцв, 04 кра 2024, Riccardo Rotondo via FreeIPA-users wrote:
Hi Alexander,
Thank you Alexander, this solution probably fits our needs. My only problem now is the I configured freeipa with docker, and in that image developer didn't include the Fedora Account System plugin for IPA so in the log I found:
ERROR in middleware: Uncaught IPA exception: Unknown option: fasgroup
I'll check with them if I can add this plug in post installation.
I'd say you need to build your own image on top of freeipa/freeipa-container. I'd rather do that by cloning git repo and extending
RUN yum -y install --setopt=install_weak_deps=False ipa-server ipa-server-dns ipa-server-trust-ad patch ipa-healthcheck ipa-client-epn && yum clean all
in one of the Dockerfile.* for your target. Or you can derive from freeipa-container image and explicitly add that in your own Dockerfile.
Hi Christian and Alexander, considering I'm still in the initial phase of the project I customised the Dockerfile to install the needed package. For those interested here is the fork with the branch: https://github.com/rrotondo/freeipa-container/tree/add-ipa-fas with a custom version for Almalinux-9.
Thank you again for your support. Regards, Riccardo
Thanks for the responses. Therefore, I will instead have to restrict access to the Web UI either by creating an HBAC rule (this is my understanding of what to do), and instead allowing them access a secondary self-service UI like https://github.com/ubccr/mokey. While this secondary software may not be the most stable, it will have to do (as long as basic functions work) until FreeIPA implements their own solution.
On ti, 11 joulu 2018, cdknight via FreeIPA-users wrote:
Thanks for the responses. Therefore, I will instead have to restrict access to the Web UI either by creating an HBAC rule (this is my understanding of what to do), and instead allowing them access a secondary self-service UI like https://github.com/ubccr/mokey. While this secondary software may not be the most stable, it will have to do (as long as basic functions work) until FreeIPA implements their own solution.
There is currently no plan to allow self-service view to be completely isolated. As explained, it is not practical and not possible in a typical FreeIPA deployment as the same information is accessible by other, user-authenticated, means.
Adding an HBAC rule will not help since access to Web UI is not controlled with HBAC.
freeipa-users@lists.fedorahosted.org