I believe the problem is in the way we store and update the resulting GPO configuration object in the sysdb cache. All the necessary objects are downloaded properly and the logs show that we are storing them in the resulting GPO configuration the way we should. However the list of allowed SIDs always contains only one SID, so it looks like instead of adding new SIDs to the object, we overwrite them if they have the same 'key' in the GPO ini file.

I will not be able to provide a scratch build today, because I do not have a patch ready yet. I will update this BZ when the test build is ready. 

Michal

I've attached the test packages to the Customer Portal case.  

Steve

Argh. I forgot to apply one change to the build. Will send new one shortly. The previous one will not work.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/3161

Created attachment 1196486 [details]
Latest logs from UPMC.  Both builds appears to have resolved their issue.

Created attachment 1196487 [details]
sssd_logs from gpotest5 package set

Jacob,

the screenshot showing your OU/GPO structure and the description was helpful. Together with the results from the last build, (the one that worked for you, but
can not be used because it does not follow the MS Group Policy
Protocol), we have additional facts about the configuration.

It is now very likely that your issue is a configuration error.
I would like to ask you (or one of your AD admins) for the
following additional information about the Group Policy
configuration:

1. Go the Group Policy Management window (where the screenshot was
taken).

2. In the tree view on the left. Right click on the "UNIX - ETI Aplication Engineering Admins" and select "Edit".

3. Group Policy Management Editor window will pop-up

4. Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
Now double click on these two settings:
- Allow log on locally
- Allow log on through remote desktop services
There should be group or user names. Plase provide those names.

Now go back to the Group Policy Management window and repeat the
steps 2 - 4 but this time for the GPO UNIX - UNIX Admins. Also
provide the list of groups or users you find.

Now back in the Group Policy Management window select the
"UNIX - ETI Application Engineering Admins" and look in the
Security Filtering. Please provide the list of all groups,
users and computers that are there. Do the same thing for the
"UNIX - UNIX Admins" GPO.

You can provide the above as screenshots, to save typing the
names.

Thank you.

Michal

Michal,
"UNIX - ETI Application Engineering Admins" = Allow log on locally + allow log on through terminal services for the group "ETIApplicationEngineeringAdmin

"UNIX - UNIX Admins" = Allow log on locally + allow log on through terminal services for the group "UNIX Administrators"

The security filtering for both GPOs is:

* Authenticated Users
* Everyone
* SYSTEM

I will upload four screencaps of the following:
1) Screencap of the GPO settings for "UNIX - ETI Application Engineering Admins"
2) Screencap of the security scope for "UNIX - ETI Application Engineering Admins"
3) Screencap of the GPO settings for "UNIX - UNIX Admins"
4) Screencap of the security scope for "UNIX - UNIX Admins"

Please let me know if you need any additional data.

Created attachment 1197213 [details]
screencaps of GPO settings and security scope for both GPOs

Jacob,

thank you for the info.

I think I now see what is wrong in the configuration.

The label "Enforced" in the GPO link actually does not mean "This GPO is turned on", but it prevents that GPO from being overriden by GPOs from the lower OUs.

So if you have Top level GPO UNIX - UNIX Admins that grants some users logon rights and set the "Enforced" flag on this GPO, specifying logon rights in the lower level GPOs in OUs (like big insights) will have no effect (which is why you could join as UNIX Administrators member, but not as ETIApplicationEngineeringAdmin). Btw. this "Enforced" flag was previously known as "No override", which is IMO much better name for it.

Unfortunately just removing the "Enforced" flag will not help. This will cause the lower level GPO (OU level) to override conflicting settings of the higher level GPO (domain level). Which means ETIApplicationEngineeringAdmin would be able to join, but UNIX Administrators will not.

So you can try following settings.

1. turn off the "Enforced" flag for both UNIX - UNIX Admins and the UNIX - ETI Application Engineering Admins GPOs. This will allow the lower level GPOs to override the parent GPO.

2. For each level/node in the hierarchy (Domain level, Big Insights level and other OUs), you should have maximal one GPO that specifies logon rights.

3. When creating the lower level GPO (again we are only talking about GPOs that are granting or denying access) copy the higher level GPO  and grant/deny access to more users in the copy. So in order to create a "UNIX - ETI Application Engineering Admins" GPO for the Big insights OU, copy the UNIX - UNIX Admins GPO and add group ETIApplicationEngineeringAdmin to the list of allowed groups. Then link it with the OU Big insights.

Also, please do not use the scratch build I provided last time. What it does is, that it automatically merges the GPOs (but this behavior is not compliant with the documentation, so using it could cause trouble poping up where we do not expect it). Do you have the scratch build I provided before (the last one from the previous bugzilla)? If not, I will build it.

Try the above configuration and let us know if it works.

Michal

Michal,
Let me run these three options by our AD Architect. We configured our GPO/OU structure based on our existing Windows config and I would like his input.

Is this the last scratch build I should be using?

[yundtj_adm@z01prd01 testbuild]$ rpm -qip sssd-1.13.0-40.el7_2.12.gpotest.ppc64le.rpm
Name        : sssd
Version     : 1.13.0
Release     : 40.el7_2.12.gpotest
Architecture: ppc64le
Install Date: (not installed)
Group       : Applications/System
Size        : 35147
License     : GPLv3+
Signature   : (none)
Source RPM  : sssd-1.13.0-40.el7_2.12.gpotest.src.rpm
Build Date  : Mon 01 Aug 2016 05:54:34 AM EDT
Build Host  : ppc-028.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon
Description :
Provides a set of daemons to manage access to remote directories and
authentication mechanisms. It provides an NSS and PAM interface toward
the system and a pluggable backend system to connect to multiple different
account sources. It is also the basis to provide client auditing and policy
services for projects like FreeIPA.

The sssd subpackage is a meta-package that contains the deamon as well as all
the existing back ends.
[yundtj_adm@z01prd01 testbuild]$

(In reply to Jacob Yundt from comment #21)
> Michal,
> Let me run these three options by our AD Architect. We configured our GPO/OU
> structure based on our existing Windows config and I would like his input.
> 
> Is this the last scratch build I should be using?
> 
> [yundtj_adm@z01prd01 testbuild]$ rpm -qip
> sssd-1.13.0-40.el7_2.12.gpotest.ppc64le.rpm
> Name        : sssd
> Version     : 1.13.0
> Release     : 40.el7_2.12.gpotest
> Architecture: ppc64le
> Install Date: (not installed)
> Group       : Applications/System
> Size        : 35147
> License     : GPLv3+
> Signature   : (none)
> Source RPM  : sssd-1.13.0-40.el7_2.12.gpotest.src.rpm
> Build Date  : Mon 01 Aug 2016 05:54:34 AM EDT
> Build Host  : ppc-028.build.eng.bos.redhat.com
> Relocations : (not relocatable)
> Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
> Vendor      : Red Hat, Inc.
> URL         : http://fedorahosted.org/sssd/
> Summary     : System Security Services Daemon
> Description :
> Provides a set of daemons to manage access to remote directories and
> authentication mechanisms. It provides an NSS and PAM interface toward
> the system and a pluggable backend system to connect to multiple different
> account sources. It is also the basis to provide client auditing and policy
> services for projects like FreeIPA.
> 
> The sssd subpackage is a meta-package that contains the deamon as well as all
> the existing back ends.
> [yundtj_adm@z01prd01 testbuild]$

No, this is not the right one. I will build a new scratch build and send it through Stephen.

Jacob,

Here is a public viewable archive with the scratch build for ppc architecture (in the case you do not have it from Stephen yet. If you do have it already, you can ignore this):

https://mzidek.fedorapeople.org/sssd-test-builds/sssd-gpotest6/sssd-gpotest6.tar

The version is:
sssd-1.13.0-40.el7_2.12.gpotest6.ppc

Michal

Michal,
I worked with our AD Architect and he believes there is an additional setting we need to configure on our GPOs.

In order for this "inheritance" to work as expected, additional GPOs need to have the "Group Policy loopback processing mode" set to "Merged" (in addition to removing the "Enforced" flag.

I will be testing with the gpotest6 packages shortly after making these GPO changes.

Michal,
After making this most recent GPO change and installing gpotest6, I am _unable_ to login with a user (yundtj_adm) that is a member of the UNIX Admins group (using the UNIX - UNIX Admins GPO).

I'll attach screenshots of the two GPOs (with their new "Merged" settings) and the usually sssd logs/gpocache/sssd.conf.  From the logs, can you verify that sssd is "merging" the GPOs as expected?  Or are we hitting some type of new issue?

I will also follow-up with our AD architect to see if he sees anything misconfigured.

-Jacob

Created attachment 1199637 [details]
sssd logs using gpotest6

Created attachment 1199638 [details]
screencaps of GPO settings after making merge change

Screencaps of Unix - Admins and ETI-AE Admins GPOs after enabling: "Computer Configuration\Administrative Templates\System\Group Policy\Configure user Group Policy loopback processing mode" and setting it to "Merge".

Jacob,

I do not think that the "Merge" option
is what you are looking for.

Here is what the MS technet states:

<quote>

Merge indicates that the user policies defined in the computer's Group Policy objects and the user policies normally applied to the user are combined. If the policy settings conflict, the user policies in the computer's Group Policy objects take precedence over the user's normal policies.

<end of quote>
Source: https://technet.microsoft.com/en-us/library/cc978513.aspx

So, it is affecting the resulting GPO list (list of GPOs that
are going to be applied) and not talking about the SID lists
that are in the options that allow/deny local and remote logins.
The merging here means that the list of GPOs for the user
and the list of GPOs for the computer are going to be merged and
in case of conflicts, the computer's GPO options override the 
users GPO options. So it something different.

Also I am not sure if there was a misunderstanding about
what I said. The three points that I mentioned in my comment
20, all three  need to be applied (so they are not three
alternatives that can fix the configuration, but 
three points that are all necessary).

The reason why you are not able to login with user from
UNIX - UNIX Admins is because when the GPO for group
UNIX - ETI Application Engineering Admins was made,
the point number 3 (from my comment 20) was not followed.
The "ETI" GPO is lower in the hierarchy, mening apllied
later and has higher priority (it overrides the higher
level GPO that allows UNIX - UNIX Admins to login, thus
blocking the UNIX - UNIX Admins members to login).

I do not think there is an option that will make what
you are trying to achieve and merge the SID lists from the
"allow/deny login" type options.

Try to create the "UNIX - ETI Application Engineering Admins" GPO
following the three points (see point 3) from my comment number 20
and check if it works.

Michal

Ping? It's been more than two months since we requested more information.

I see in the case that they are asking about the status of 7.2 packages -- the answer is that these fixes were not backported to 7.2 and there the answer is no, we didn't back port these fixes to 7.2.

however, if the code works for the customer with 7.3 packages, then this bugzilla can be closed, correct?

Lukas,
Is it possible to get this fix (and it's corresponding INI_CONFIG dependency) back ported to EUS 7.2?

(In reply to Jason Willeford from comment #43)
> Lukas,
> Is it possible to get this fix (and it's corresponding INI_CONFIG
> dependency) back ported to EUS 7.2?

There is not any problem from engineering point of view.
But there are other requirements which need to be fulfilled for bacporting to EUS 7.2.

But it would be good if you could test sssd-1.14.0-43.el7_3.4.x86_64 + required libini_config-1.3.0 from 7.3 on 7.2. You needn't upgrade other pacakges.

libini_config-1.3.0 in rhel7.3 is fully compatible(API/ABI) with libini_config-1.2.0 in rhel7.2 and the latest version is required for fixing GPO bug in sssd. You needn't worry to upgrade it (at least for testing purposes)

I tried to upgrade ssd on el7.2 from el7.3 repositories and here is an output:

Updating:
 sssd                   x86_64      1.14.0-43.el7_3.4        106 k
Installing for dependencies:
 jansson                x86_64      2.4-6.el7                 32 k
 libsss_autofs          x86_64      1.14.0-43.el7_3.4        116 k
 libsss_sudo            x86_64      1.14.0-43.el7_3.4        114 k
Updating for dependencies:
 libini_config          x86_64      1.3.0-27.el7              63 k
 libipa_hbac            x86_64      1.14.0-43.el7_3.4        114 k
 libnl3                 x86_64      3.2.28-2.el7             277 k
 libsss_idmap           x86_64      1.14.0-43.el7_3.4        118 k
 python-sssdconfig      noarch      1.14.0-43.el7_3.4        139 k
 sssd-ad                x86_64      1.14.0-43.el7_3.4        223 k
 sssd-client            x86_64      1.14.0-43.el7_3.4        171 k
 sssd-common            x86_64      1.14.0-43.el7_3.4        1.2 M
 sssd-common-pac        x86_64      1.14.0-43.el7_3.4        149 k
 sssd-ipa               x86_64      1.14.0-43.el7_3.4        295 k
 sssd-krb5              x86_64      1.14.0-43.el7_3.4        144 k
 sssd-krb5-common       x86_64      1.14.0-43.el7_3.4        171 k
 sssd-ldap              x86_64      1.14.0-43.el7_3.4        211 k
 sssd-proxy             x86_64      1.14.0-43.el7_3.4        139 k

New packages libsss_autofs and libsss_sudo contains files which were previously packaged in sssd-common. 

jansson is required for new sssd-secrets responder which is in tech preview and is packaged in sssd-common.