During initgroups requests we try to avoid to resolve the complete member list of groups if possible, e.g. if there are no nested groups. The tokenGroups LDAP lookup return the complete list of memberships for a user hence it is not necessary lookup the other group member and un-roll nested groups. With this patch only the group entry is looked up and saved as incomplete group to the cache. This is achieved by adding a new boolean parameter no_members to groups_get_send() and sdap_get_groups_send(). The difference to config options like ldap_group_nesting_level = 0 or ignore_group_members is that if no_members is set to true groups which are missing in the cache are created a incomplete groups. As a result a request to lookup this group will trigger a new LDAP request to resolve the group completely. This way no information is ignored but the time needed to read all data is better distributed between different requests. https://fedorahosted.org/sssd/ticket/2601 Reviewed-by: Jakub Hrozek <jhrozek@redhat.com> (cherry picked from commit d81d8d3dc151ebc95cd0e3f3b14c1cdaa48980f1)
According to Microsoft documentation, the tokenGroups attribute is available since Windows 2000: http://msdn.microsoft.com/en-us/library/cc220937.aspx We were not able to test against Windows 2000, though, as we don't have that OS around, so this patch only changes the compatibility level to 2003. Reviewed-by: Pavel Březina <pbrezina@redhat.com> (cherry picked from commit 5c2f2023696d1ff79c3c5d94b89e7ef9cd4159e9)
The newest functional level we branch for is currently DS_BEHAVIOR_WIN2003. Therefore (and also because extended support for Windows server 2003 ends in 2015) we can safely set the functional level to 2003 if the attribute is present but not a known value. Reviewed-by: Pavel Březina <pbrezina@redhat.com> (cherry picked from commit 0fafb51756913e78dbf523a69fc3a4ef2bac54ec)
https://fedorahosted.org/sssd/ticket/2418
According to http://msdn.microsoft.com/en-us/library/cc223272.aspx a
Windows Server 2012 R2 has a functional level set to '6'. We need to
support that value in order for tokenGroups to be functional.
For more information on the functional levels, please refer to:
http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx
Reviewed-by: Pavel Březina <pbrezina@redhat.com>
(cherry picked from commit 9ea0969f6a9e52b7c57feb5808266b0739ee40a4)
https://fedorahosted.org/sssd/ticket/2412 Even though AD trusts often work with POSIX attributes which are normally not replicated to GC, our group lookups are smart since commit 008e1ee835602023891ac45408483d87f41e4d5c and look up the group itself using the LDAP connection and only use the GC connection to look up the members. Reviewed-by: Pavel Reichl <preichl@redhat.com> (cherry picked from commit a20ce8cd43d72c89e2ea1d65aefe24ba270f040f)
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Pavel Reichl <preichl@redhat.com> (cherry picked from commit a2ea3f5d9ef9f17efbb61e942c2bc6cff7d1ebf2)
https://fedorahosted.org/sssd/ticket/2391 apply_subdomain_homedir() didn't handle the situation where an entity that doesn't match was requested from the cache. For user and group lookups this wasn't a problem because the negative match was caught sooner. But SID lookups can match either user or group. When a group SID was requested, the preceding LDAP request matched the SID and stored the group in the cache. Then apply_subdomain_homedir() only tried to search user by SID, didn't find the entry and accessed a NULL pointer. A simple reproducer is: $ python >>> import pysss_nss_idmap >>> pysss_nss_idmap.getnamebysid(group_sid) The group_sid can be anything, including Domain Users (XXX-513) Reviewed-by: Michal Židek <mzidek@redhat.com> (cherry picked from commit 82347f452febe3cbffc36b0a3308ffb462515442)
The functionality was removed, but we forgot to remove the corresponding tests, mostly because these tests were only ever ran as root.
Reviewed-by: Jakub Hrozek <jhrozek@redhat.com>