#3311 group filter isn't useful

Created 9 months ago by hedrick
Modified a month ago

I'm trying to use a single IPA server to handle several different clusters of machines. I need certain users and groups to show up on only some machines. I'm using the host attribute for both users and groups, although the value is a cluster name, not a host name. For sssd, I want group and passwd filters that select just those groups and users with the right host value.

I used
ldap_group_search_base = cn=accounts,xxx?subtree?(host=ilab)

host=ilab is added to some queries, but not enough to actually work. The main exception is initgroups. It gets the list of groups using memberOf attributes for the user. It then looks up the groups to find the gid.

The result is that "groups user" shows all the groups, whether the host attribute is right or not, but it shows gids rather than names for some of them, because a later lookup to go back from gid to name fails for groups with the wrong host value (the correct behavior).

One approach would be for the lookup for the individual groups to use the filter, and for the group to be omitted from the list if that lookup fails.

See also 1653. If memberOf isn't used, perhaps all group lookups would then use the filter. However a direct fix to this problem may be easier than implementing 1653.

I think what you are trying accomplish is that only a subset of groups becomes visible on a particular host. We have had similar requests in the past and there are tickets other than #1653 that ask for that, for example #3249.
You are asking for a filter but this might not be how things would be implemented (eventually).

So let us put a user story (please verify):

As an administrator of different sets of the machines I want to be able to define different subsets of groups that become visible on those machines so that I can limit access control on these machines only to specific groups.

Is that right? Or the reason is that you are managing different tenants and you do not want to leak other tenants to the host used primarily bu another tenant?

If the cause is access control then there are other means to limit access control and we would rather focus on making sure that can be accomplished in a better way via HBAC, SUDO or other mean. If it is about exposing tenant information then the story should really be:

As an administrator of a set of clusters of hosts offered to different tenants I want to be able to isolate tenants in IPA and SSSD in such a way that on a client system used by one tenant the information about other tenant(s) is not revealed.

If this is the case then we already have tickets (in IdM project) to do multitentncy in IdM. However it would be a huge change and might not happen any time soon. What you can get quite soon is the ability to have FreeIPA trusts. With containerized IPA you would be able to run different tenant systems on one machine and manage them using trusts. We are working on global calatog and this is a step to this direction.

So what is this ticket about?

I think this is currently not well supported with the IPA provider, because, as you noted, the get-groups call always dereferences all memberof attributes.

I think it is a slight bug in SSSD in the sense that if the group search base contains a filter, we shouldn't dereference the memberof attributes.

A patch is welcome to change the behaviour of the LDAP provider to not dereference if any of the bases contain a filter.

milestone: NEEDS_TRIAGE => SSSD Patches welcome

9 months ago

Metadata Update from @hedrick:
- Issue set to the milestone: SSSD Patches welcome

Yes, this is correct:

As an administrator of different sets of the machines I want to be able to define different subsets of groups that become visible on those machines so that I can limit access control on these machines only to specific groups.

However it's not just access control. There are other ways to do that (though the most obvious seems not to work). Groups can also be used to control who can access a file. Indeed file sharing is the original purpose of groups. I don't want every group is the directory to be visible on every system, in large part because it complicates management. If I have 100 groups in the directory but only 10 should be used on the system, users will still see all 100, and may use them.

Groups typically have a finite lifetime. In our environment we create groups for each course. We have lots of them. To avoid insanity we want to remove them after a few years. At the moment we only have to warn users on course machines that old groups are going away. If we let them be visible anywhere, then any time we remove a group we have to check every computer to see whether someone has used it. (Yes, we have users that use random groups that we’d never expect them to use.)

Also, at the moment you have a documented feature that doesn't work. There is a documented group filter. But if you try to use it, you find that groups not covered by the filter are still present on the system and used. If you're not going to fix that, you should remove the group filter.

8 months ago

Metadata Update from @hedrick:
- Issue close_status updated to: None

Yes, this is correct:
As an administrator of different sets of the machines I want to be able to define different subsets of groups that become visible on those machines so that I can limit access control on these machines only to specific groups.
However it's not just access control. There are other ways to do that (though the most obvious seems not to work). Groups can also be used to control who can access a file. Indeed file sharing is the original purpose of groups. I don't want every group is the directory to be visible on every system, in large part because it complicates management. If I have 100 groups in the directory but only 10 should be used on the system, users will still see all 100, and may use them.
Groups typically have a finite lifetime. In our environment we create groups for each course. We have lots of them. To avoid insanity we want to remove them after a few years. At the moment we only have to warn users on course machines that old groups are going away. If we let them be visible anywhere, then any time we remove a group we have to check every computer to see whether someone has used it. (Yes, we have users that use random groups that we’d never expect them to use.)

OK

Also, at the moment you have a documented feature that doesn't work.

Yeah, I agree it's a bug, but the feature doesn't work /in this specific case/. It works in the plain rfc2307{,bis} case. I think if you configured the client with id_provider=ldap and ldap_schema=rfc2307bis, then it would work also with IPA.

8 months ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

Yes, so far it seems to work. The ldap queries produced are a bit odd. When I do "groups xxxx", it looks at xxx, all the groups xxx is a member of, and all the users in all the groups. With nslcd it looks at all the groups and gets a list of their members, but it doesn't look at each member individually. There's enough caching that this may not be an issue, but it does seem odd. The newest version of nslcd (which we're not usnig because it isn't in Centos yet) optimizes initgroups so that it just pulls the list of groups the user is, without looking at their members at all.

But there's probably some advantage to using just sssd and not having to run nslcd also, so I may use this configuration. With sssd and id provider = ldap, is there a way to get it to use GSSAPI authentication to ldap?

Yes, so far it seems to work. The ldap queries produced are a bit odd. When I do "groups xxxx", it looks at xxx, all the groups xxx is a member of, and all the users in all the groups. With nslcd it looks at all the groups and gets a list of their members, but it doesn't look at each member individually. There's enough caching that this may not be an issue, but it does seem odd.

Interesting, can you post the LDAP searches nslcd is doing and the LDAP searches SSSD is doing?

Does nslcd display the group members if you do 'getent group $groupname' ?

In general, I would except to see what SSSD is doing because in general
the 'groups' command must first resolve the groups the user is a member
of which returns a list of gids (see man 3 getgrouplist) and then resolve
each group in turn using getgrgid to convert the GID to name.

The newest version of nslcd (which we're not usnig because it isn't in Centos yet) optimizes initgroups so that it just pulls the list of groups the user is, without looking at their members at all.

Yeah, but it should still need to convert the GID to name.

But there's probably some advantage to using just sssd and not having to run nslcd also, so I may use this configuration.

You can still use the sudo and autofs integration from the IDM server. I don't think you can use the HBAC support, because it depends on id_provider=ipa fetching the data for it. But I understand you are using the group membership for access control.

With sssd and id provider = ldap, is there a way to get it to use GSSAPI authentication to ldap?

Try this:
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/hostname.example.com
ldap_sasl_realm = EXAMPLE.COM
krb5_server = ipa.example.com

8 months ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

I just looked at LDAP logs to compare sss with nslcd. I don't see any query for groups at all with sssd, until something is done that requires the group name. At login, setgroups need to be done, but that only requires GID's, not names.

I now have a mystery. I can't see how it's getting the gid's at all, unless Kerberos is returning them in the PAC and sssd is using that. But I can't duplicate the extra queries I mentioned.

If IPA's kerberos is generating a PAC and sssd is using it, that would explain the reported bug. The KDC would have no way of knowing what filter is defined in sssd.conf.

Edited a month ago by hedrick

Login to comment on this ticket.

defect

SSSD

1.14.0

false

false

false

false

false

false

cancel