On Аўт, 01 кра 2025, Finn Krein-Schuch via FreeIPA-users wrote:
Hello,
is it possible to restrict information about users or usergroups from
being passed to a FreeIPA client? Using HBAC we can configure clients
to only allow login by specific user groups, but `id` and `getent
passwd`
will still list these users and give out information about them.
Is it possible to restrict this, either server-side or by sssd configuration?
My motivation for this is integrating a client database into the
freeipa. These users should only authenticate to a specific service
(keycloak) but otherwise be transparent on the managed clients.
I am aware that FreeIPA does not support OUs but maybe this use case
can be covered somehow.
I was looking at my previous answers for this but wasn't able to find
something in the list archive, so I looked at the previous archive that
is not anymore available online and this is from February 2017:
-----------------------------------------------------------------------
FreeIPA has flat DIT, with no OUs or other segregation means. All users
and all groups are at the same level, there is no mechanism to prevent
them from being invisible to each other.
Additionally, it would not give you much of protection against hosts
because each enrolled host can see (read-only) all users and groups. If
host principals would not be able to do so, SSSD would not be able to
retrieve identity information.
Even if user has no control over its own enrolled machine, POSIX
identity retrieval API also has no separation feature. If you are able
to issue getpwnam() or getpwuid() call, you are able to methodically
iterate through all POSIX attributes of all users, even inefficiently.
Note FreeIPA is not alone at this. Active Directory allows all machines
in the domain to query identity information even if you are not able to
see it directly from LDAP. Global Catalog service also gives all users
at least read-only access to whole forest's identity information.
This is why I called a proposed approach to solve this use-case as
security through obscurity. The API is there to readily retrieve most of
the information without really involved effort.
-----------------------------------------------------------------------
Said that, you might be able to play with LDAP filters in SSSD to limit
which users can be visible to the machine at all. This is not really
going to work well as all users are in the same subtree but at least
memberOf is part of the user entry and can be compared.
--
/ 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