When interworking with a Samba AD server (4.3.11) SSSD up to version 1.15.1 cannot apply a correctly configured GPO for access control of domain users on a domain member server. Even with low level debugging, only minimum information is provided: GPO not applicable to target per security filtering. After removing the standard read access rights from the GPO the GPO access control fails with perform_smb_operations failed.[2][No such file or directory] by the GPO child.

As even low-level logs did not help to figure out the root cause, a review of the source code was performed supported by wireshark analysis of the message flow between SSSD and Samba AD as well as Windows 7 clients and Samba AD.

The current GPO security filtering does not take into account, that GPO read
access and control access rights for a particular trustee may be split into
different ACEs. Security filtering stops after evaluation of the GPO read
access ACE and denies access if there is no other trustee for the user that
requests login. This problem was already highlighted in
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/ODXS6FBMZTXO7BNKYBX423LX4UHZO7AE
but has not been solved.

Also with regard to other security filtering steps the current implementation
is way to strict. E. g. if a group policy container in AD does not contain a
DACL or "DACL Present" bit is not set, SSSD stops group policy filtering and
ignores the succeeding GPOs.

There are AD server implementations that store group policy files on SYSVOL
using upper case names for the main folders (MACHINE and USER). SSSD uses
libsmbclient to accces group policy files. libsmbclient does not allow case
insensitive file access, if the AD server file system is case sensitive. That
has been confirmed to be a feature on the Samba mailing list. In such a case
SSSD's GPO child fails with error 22 (Invalid argument), even though
the required group policy files are stored on SYSVOL.

Finally, administrators can only retrieve sufficient information about failures
in GPO security filtering, if they configure low-level debugging. SSSD man pages
suggest to use log level function data in their examples. This level is
sufficient to log GPO access control but not GPO security filtering. Also the
sssd-ad man page is very reluctant with information on the powerful GPO based
access control of SSSD.

The described issues are most probably also the real root cause for Issue #3279, despite of the fact that the issuer had problems with the rather complicated setup of a Samba AD environment.