Thanks for the recommendation, it certainly looks promising.


On Thu, Feb 29, 2024 at 7:05 AM Alexander Bokovoy <abokovoy@redhat.com> wrote:
On Няд, 25 лют 2024, Carlos Eduardo Porter via FreeIPA-users wrote:
>So, I did so more research and found this thread from 7 years ago [1] which
>I obviously missed and clearly answers my previous question
>
>Quote:
>""
>  Even with that, I'd not recommend tightening permissions so that users
>  would not be able to see other users. There are always ways to break
>  through this 'enforcement', even start with the fact that a user could
>  actually authenticate with the host principal of their desktop system.
>  Access to the identity information is not arbitrated in POSIX
>  environment. Any process under any user could ask for other user and
>  group identities with standard libc API.
>
>  Security through obscurity never works well in a longer term.
>
>""
>                                   -- Alexander Bokovoy
>
>So I get Alexander's point, although there are still valid reasons to want
>to limit other users access to the directory, such as:
>
> - Multiple temporary vendors: you might want to grant them access to some
>of your development tools without them being aware of other users or groups
>on your organization
>
> - Application Settings: you might have an application that allows you to
>set up a single LDAP server, or if you have multiple realms or freeipa
>instances you can only use at the time for authentication.
>
> Nonetheless, the point is taken and it seems that for now the best
>solution would be not to expose all users to the FreeIPA web interface.
>
> I'm also considering using phpLDAPadmin and grant it access only to
>specific groups within the main FreeIPA directory, that way I might be able
>to setup different phpLDAPadmin instances for as many LDAP groups and
>provide them with limited directory access ( at least from a web interface
>point of view, although this might seem foolish ).

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.

>
>References:
>[1]
>https://freeipa-users.redhat.narkive.com/Zz750eoG/limit-regular-user-access-only-to-self-service-portal
>
>On Sat, Feb 24, 2024 at 5:17 AM Carlos Eduardo Porter <
>carlosporter2006@gmail.com> wrote:
>
>> Hello,
>>
>> I hope this message finds you well. I'm currently working on deploying
>> FreeIPA for a small company and have encountered a challenge that I’d like
>> to share with you, hoping to confirm if I'm on the right track.
>>
>> My objective is to restrict access within the FreeIPA web interface,
>> specifically, I want to ensure that only members of a group named
>> "managers" can view information about other accounts and groups on the
>> FreeIPA server.
>>
>> I am aware that this issue might seem familiar as it has been discussed in
>> this forum previously. Nonetheless, I'm bringing it up again with the
>> intention of finding a solution that could benefit others facing similar
>> challenges.
>>
>> From what I've gathered over the years, altering the default permissions
>> in FreeIPA, which allow access to all accounts, could potentially lead to
>> more complications (refer to [1] for details). However, there seems to be a
>> possibility of achieving this through the correct configuration of
>> permissions, privileges, and roles in FreeIPA. For instance, setting up
>> filters that permit a user to view only their own account information.
>> Despite my efforts, I haven’t been successful in implementing this so far.
>>
>> Here’s an example of what I've tried:
>>
>> # Adds a new permission named 'Self Only Access' allowing read, search,
>> and compare rights limited to user's own attributes
>> ipa permission-add 'Self Only Access' --right={'read','search','compare'}
>> --type=user --attrs={'uid','mail','title'} --filter="(uid=\${user})"
>>
>> # Creates a new privilege called 'Self Read User Privilege'
>> ipa privilege-add 'Self Read User Privilege' --desc="Privilege for Self
>> Read User"
>>
>> # Adds the 'Self Only Access' permission to the 'Self Read User Privilege'
>> ipa privilege-add-permission 'Self Read User Privilege'
>> --permissions='Self Only Access'
>>
>> # Creates a new role named 'CustomSelfReadUserRole' with a description for
>> the self-read privilege
>> ipa role-add 'CustomSelfReadUserRole' --desc='Role with Self Read User
>> Privilege'
>>
>> # Associates the 'Self Read User Privilege' with the
>> 'CustomSelfReadUserRole'
>> ipa role-add-privilege 'CustomSelfReadUserRole' --privileges='Self Read
>> User Privilege'
>>
>> # Displays the details of the 'CustomSelfReadUserRole'
>> ipa role-show 'CustomSelfReadUserRole'
>>
>> # Adds specific users ('user1' and 'user2') as members of the
>> 'CustomSelfReadUserRole'
>> ipa role-add-member 'CustomSelfReadUserRole' --users={'user1','user2'}
>>
>>
>> This approach is partly based on a blog entry by Alexander Bokovoy ([2])
>> about creating permissions in FreeIPA.
>>
>> Another more drastic measure involves modifying Apache2 to use mod_ldap
>> and restricting access to the FreeIPA API, as shown below:
>>
>> # Creating a new configuration file for Apache2 with LDAP settings
>> cat > /etc/httpd/conf.d/ldap.conf
>>
>> # Loading necessary modules for LDAP and GSSAPI authentication
>> LoadModule ldap_module modules/mod_ldap.so
>> LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
>> LoadModule auth_gssapi_module modules/mod_auth_gssapi.so
>>
>> # Configuration settings for the location '/ipa'
>> <Location "/ipa">
>>     # Setting the authentication type to Basic
>>     AuthType Basic
>>
>>     # Naming the restricted access area for clarity
>>     AuthName "FreeIPA Restricted Access"
>>
>>     # Specifying LDAP as the provider for basic authentication
>>     AuthBasicProvider ldap
>>
>>     # Configuring LDAP bind credentials (username and password)
>>     AuthLDAPBindDN "uid=<username>,cn=users,cn=accounts,dc=example,dc=com"
>>     AuthLDAPBindPassword "<secret>"
>>
>>     # Disabling LDAP referrals (redirects to other servers for
>> authentication)
>>     LDAPReferrals Off
>>
>>     # Specifying an empty user file; authentication is done against LDAP
>>     AuthUserFile /dev/null
>>
>>     # Defining the LDAP URL with a filter for user ID (uid)
>>     AuthLDAPURL "ldaps://
>> freeipa.example.com/cn=users,cn=accounts,dc=example,dc=com?uid" NONE
>>
>>     # Configuring LDAP group attributes for authorization checks
>>     AuthLDAPGroupAttribute member
>>     AuthLDAPGroupAttributeIsDN on
>>
>>     # Restricting access to members of the 'managers' group in LDAP
>>     Require ldap-group cn=managers,cn=groups,cn=accounts,dc=example,dc=com
>> </Location>
>>
>> However ,this setup doesn't work either since I end up with a blank page
>> after authentication with the Apache2 server and can't load the login page
>> for FreeIPA.
>>
>> I'm also considering an approach similar to one discussed in a previous
>> conversation ([3]), but I’m uncertain about its applicability in my
>> situation.
>>
>> I would greatly appreciate any advice or recommendations on how to either
>> allow web interface access solely to the "managers" group or set up
>> permissions in FreeIPA so that users are unable to browse/see/find other
>> user accounts in the LDAP directory (excluding the bind user account, of
>> course).
>>




>> Thank you for your time and expertise.
>>
>> Best regards,
>>
>> Carlos Porter.
>>
>> References:
>> [1] [Restrict User Access - FreeIPA Users Mailing List](
>> https://freeipa-users.redhat.narkive.com/AYqO5sQr/restrict-user-access)
>> [2] [Creating Permissions in FreeIPA - Alexander Bokovoy's Blog](
>> https://vda.li/en/posts/2016/08/30/Creating-permissions-in-FreeIPA/)
>> [3] [FreeIPA Users Mailing List Archive](
>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/YNNSI5574TCAG2MG7L3EA6Q43LYUS6WR/
>> )
>>




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