On ma, 03 huhti 2017, Jakub Hrozek wrote:
On Mon, Apr 03, 2017 at 06:32:49PM +0300, Alexander Bokovoy wrote:
On ma, 03 huhti 2017, Orion Poplawski wrote:
> On 04/03/2017 02:10 AM, Alexander Bokovoy wrote:
> > On ma, 03 huhti 2017, Jakub Hrozek wrote:
> > > On Fri, Mar 31, 2017 at 04:07:16PM -0600, Orion Poplawski wrote:
> > > > I'm seeing messages like this:
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
> > > > [ipa_add_ad_memberships_get_next] (0x0020): There are unresolved
external
> > > > group memberships even after all groups have been looked up on the LDAP
> > > > server.
> > > >
> > > > and wondering it is anything to worry about.
> > > >
> > > >
> > > > Some context:
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[sysdb_cache_search_groups]
> > > > (0x2000): Search groups with filter:
> > > >
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[sysdb_cache_search_groups]
> > > > (0x2000): No such entry
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[sysdb_cache_search_groups]
> > > > (0x2000): Search groups with filter:
> > > >
(&(objectclass=group)(originalDN=cn=nwra,cn=groups,cn=accounts,dc=nwra,dc=com))
> > > >
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [merge_msg_ts_attrs]
(0x2000):
> > > > No such DN in the timestamp cache:
> > > > name=n...@nwra.com,cn=groups,cn=nwra.com,cn=sysdb
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[sysdb_merge_res_ts_attrs]
> > > > (0x2000): TS cache doesn't contain this DN, skipping
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[sdap_get_groups_next_base]
> > > > (0x0400): Searching for groups with base [cn=accounts,dc=nwra,dc=com]
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]] [sdap_print_server]
(0x2000):
> > > > Searching 10.10.41.4:389
> > > > (Fri Mar 31 13:27:38 2017) [sssd[be[nwra.com]]]
[sdap_get_generic_ext_step]
> > > > (0x0400): calling ldap_search_ext with
> > > >
[(&(cn=12d2026e-a5cd-11e5-a14e-00163e2d6456)(|(objectClass=ipaUserGroup)(objectClass=posixGroup))(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=nwra,dc=com].
> > > >
> > >
> > > I think this might be the reason why SSSD reports unresolved
> > > memberships. It'trying to resolve the group using the cn attribute, ut
> > > the object's RDN attribute seems to be ipaUniqueID. So I don't think
> > > this is harmful, just confusing.
> > >
> > > Can you please check what the object is on the IPA side with this
> > > ipaUniqueID?
> > It is HBAC group -- see above in the log:
> >
(&(objectclass=group)(originalDN=ipaUniqueID=12d2026e-a5cd-11e5-a14e-00163e2d6456,cn=hbac,dc=nwra,dc=com))
>
> This is our "allow employees access" HBAC group. So it applies to our "nwra"
> host group as well as a couple individual machines, and to our "nwra" IPA
group.
It is HBAC group, not a normal POSIX user group, so SSSD shouldn't even
look at it for a POSIX user membership.
Right, I'll try to reproduce at least the error message locally to try
if we can suppress it (by skipping the HBAC group). At the very least
the error message is confusing for admins.
It may also be related to the issue of not setting proper base for
searches in case of IPA provider for some times of searches.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
