Seeking Advice: Limiting User Access in FreeIPA Web Interface

[Carlos Eduardo Porter]

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/[e-mail]...
)

[Carlos Eduardo Porter]

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 ).

References:
[1]
https://freeipa-users.redhat.narkive.com/Zz750eoG/limit-regular-user-access-...

On Sat, Feb 24, 2024 at 5:17 AM Carlos Eduardo Porter <
[e-mail]> 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/[e-mail]...
> )

[Alexander Bokovoy]

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-...
>
> On Sat, Feb 24, 2024 at 5:17 AM Carlos Eduardo Porter <
> [e-mail]> 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/[e-mail]...
> > )

[Carlos Porter]

Thanks for the recommendation, it certainly looks promising.

On Thu, Feb 29, 2024 at 7:05 AM Alexander Bokovoy 
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-...
> > On Sat, Feb 24, 2024 at 5:17 AM Carlos Eduardo Porter <
> > [e-mail]> 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/[e-mail]...
> > > )
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland