Thanks for the recommendation, it certainly looks promising.
On Thu, Feb 29, 2024 at 7:05 AM Alexander Bokovoy <abokovoy(a)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-acce...
>
>On Sat, Feb 24, 2024 at 5:17 AM Carlos Eduardo Porter <
>carlosporter2006(a)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.fedoraho...
>> )
>>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland