How to prevent non-admin users of FreeIPA from reading the list of users in the web interface?

[cdknight]

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.

[Florence Blanc-Renaud]

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(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)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/[e-mail]...
>   
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

[Alexander Bokovoy]

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

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Riccardo Rotondo]

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

[Alexander Bokovoy]

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.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Riccardo Rotondo]

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

[Christian Heimes]

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.

-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
O'Neill

[Alexander Bokovoy]

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.


-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Riccardo Rotondo]

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

[cdknight]

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.

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland