Hello,
with nslcd I do the following to simulate user private groups without actually creating them in the directory server:
... filter group (&(|(objectClass=Group)(&(!(userAccountControl:1.2.840.113556.1.4.803:=2))(objectClass=User)))(msSFU30NisDomain=example)) ...
I tried porting this to sssd using the following:
ldap_group_search_base = DC=example,DC=com?subtree?(&(|(objectClass=Group)(&(!(userAccountControl:1.2.840.113556.1.4.803:=2))(objectClass=User)))(msSFU30NisDomain=example))
Unfortunately this does not work as expected.
Any Idea how this would be done in sssd?
Regards
Sven
On Tue, Jun 24, 2014 at 03:28:05PM +0200, Sven Geggus wrote:
Hello,
with nslcd I do the following to simulate user private groups without actually creating them in the directory server:
... filter group (&(|(objectClass=Group)(&(!(userAccountControl:1.2.840.113556.1.4.803:=2))(objectClass=User)))(msSFU30NisDomain=example)) ...
I tried porting this to sssd using the following:
ldap_group_search_base = DC=example,DC=com?subtree?(&(|(objectClass=Group)(&(!(userAccountControl:1.2.840.113556.1.4.803:=2))(objectClass=User)))(msSFU30NisDomain=example))
Looks like the correct syntax to me.
However, note that SSSD works differently than nss-pam-ldapd -- we save the entry attributes to the cache first and while saving the entry, we perform a number of checks.
My guess is that the SSSD expects the group entries to have objectclass=group. Domain logs would show more..
Jakub Hrozek schrieb am Dienstag, den 24. Juni um 15:59 Uhr:
My guess is that the SSSD expects the group entries to have objectclass=group.
Hm, I already suspected something like this might be the case.
When running sssd with debug option I get something like this:
[sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): No results for getgrnam call [sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): Group [xxx] does not exist in [example.com]! (negative cache) [sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): No matching domain found for [xxx], fail!
Looks like I need to stick with nslcd for now :(
Sven
On Wed, Jun 25, 2014 at 11:55:14AM +0200, Sven Geggus wrote:
Jakub Hrozek schrieb am Dienstag, den 24. Juni um 15:59 Uhr:
My guess is that the SSSD expects the group entries to have objectclass=group.
Hm, I already suspected something like this might be the case.
When running sssd with debug option I get something like this:
[sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): No results for getgrnam call [sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): Group [xxx] does not exist in [example.com]! (negative cache) [sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): No matching domain found for [xxx], fail!
This just means the search failed, doesn't tell why, though.
I think the domain logs would be more informative. Can you put debug_level = 6 into the [domain/example.com] section and then check out /var/log/sssd/sssd_example.com.log ?
Looks like I need to stick with nslcd for now :(
In 1.12, we're going to fix https://fedorahosted.org/sssd/ticket/2184 then you could set the same objectclass (maybe 'top' or something) for both users and groups..
Sven
-- "linux is evolution, not intelligent design" (Linus Torvalds)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (25/06/14 11:55), Sven Geggus wrote:
Jakub Hrozek schrieb am Dienstag, den 24. Juni um 15:59 Uhr:
My guess is that the SSSD expects the group entries to have objectclass=group.
Hm, I already suspected something like this might be the case.
When running sssd with debug option I get something like this:
[sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): No results for getgrnam call [sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): Group [xxx] does not exist in [example.com]! (negative cache) [sssd[nss]] [nss_cmd_getgrnam_search] (0x0040): No matching domain found for [xxx], fail!
These lines mean that there was already request for group "xxx", but it was not found in LDAP. For analysis, you will need to send log all files.
Looks like I need to stick with nslcd for now :(
Sven
LS
sssd-users@lists.fedorahosted.org