Hi,
I have a trust setup against an AD domain for existing user accounts, I have then crated groups in FreeIPA and added AD users to external groups which are members of the POSIX groups. All good so far, now I noticed that is was not possible to lookup some users on the clients while it works fine on the server. A little digging showed that:
(Sat Apr 13 22:48:52 2019) [sssd[nss]] [sysdb_search_object_attr] (0x0020): Search with filter [(&(|(objectCategory=user)(objectCategory=group))(|(nameAlias=examplegroup@ipa.net)(name=examplegroup@ipa.net)))] returned more than one object. (Sat Apr 13 22:48:52 2019) [sssd[nss]] [sysdb_search_object_attr] (0x0040): Error: 22 (Invalid argument) (Sat Apr 13 22:48:52 2019) [sssd[nss]] [cache_req_search_cache] (0x0020): CR #66: Unable to lookup [examplegroup@ipa.net] in cache [22]: Invalid argument (Sat Apr 13 22:48:52 2019) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
This happens when there are both a group and a user with the same name in FreeIPA, and we can see on the filter that it looks for both. So if user AD user X is part of group mariadb by a proxy group and there are a also a mariadb user, lookups for AD user X fails on the SSD clients.
It does work on the FreeIPA server all the time but fails on clients, if I lookup the conflicting group before the use on the client it also woks.
Version is 4.6.2.
Regards Henrik
On su, 14 huhti 2019, Henrik Johansson via FreeIPA-users wrote:
Hi,
I have a trust setup against an AD domain for existing user accounts, I have then crated groups in FreeIPA and added AD users to external groups which are members of the POSIX groups. All good so far, now I noticed that is was not possible to lookup some users on the clients while it works fine on the server. A little digging showed that:
(Sat Apr 13 22:48:52 2019) [sssd[nss]] [sysdb_search_object_attr] (0x0020): Search with filter [(&(|(objectCategory=user)(objectCategory=group))(|(nameAlias=examplegroup@ipa.net)(name=examplegroup@ipa.net)))] returned more than one object. (Sat Apr 13 22:48:52 2019) [sssd[nss]] [sysdb_search_object_attr] (0x0040): Error: 22 (Invalid argument) (Sat Apr 13 22:48:52 2019) [sssd[nss]] [cache_req_search_cache] (0x0020): CR #66: Unable to lookup [examplegroup@ipa.net] in cache [22]: Invalid argument (Sat Apr 13 22:48:52 2019) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
This happens when there are both a group and a user with the same name in FreeIPA, and we can see on the filter that it looks for both. So if user AD user X is part of group mariadb by a proxy group and there are a also a mariadb user, lookups for AD user X fails on the SSD clients.
It does work on the FreeIPA server all the time but fails on clients, if I lookup the conflicting group before the use on the client it also woks.
This is SSSD-specific issue. Sometimes it doesn't have enough information to deduce what is being looked up -- a group or a user and has to ask for either. Perhaps, it might be optimized to check whether there are two results returned and they are of different nature, as opposed to multiple results of the same nature returned which clearly would be a wrong result.
May be you can open a bug against SSSD?
On 14 Apr 2019, at 08:54, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
It does work on the FreeIPA server all the time but fails on clients, if I lookup the conflicting group before the use on the client it also woks.
This is SSSD-specific issue. Sometimes it doesn't have enough information to deduce what is being looked up -- a group or a user and has to ask for either. Perhaps, it might be optimized to check whether there are two results returned and they are of different nature, as opposed to multiple results of the same nature returned which clearly would be a wrong result.
May be you can open a bug against SSSD?
Thank you, this leave us with the same restrictions with one namespace for users and groups on the IPA side as in windows and will prevent our migration. I will have a bug filed against SSSD but I guess it will take some time to get this fixed.
Regards Henrik
freeipa-users@lists.fedorahosted.org