Thanks for the recommendation, it certainly looks promising.
On Thu, Feb 29, 2024 at 7:05 AM Alexander Bokovoy <[email protected]> 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 < > >[email protected]> 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/[email protected]/message/YNNSI5574TCAG2MG7L3EA6Q43LYUS6WR/ > >> ) > >> > > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > >
-- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
