Bug 1370255
Summary: | members of the group specified in the GPO are not able to login. | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Stephen Beal <sbeal> |
Component: | sssd | Assignee: | Michal Zidek <mzidek> |
Status: | CLOSED NOTABUG | QA Contact: | Steeve Goveas <sgoveas> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.2 | CC: | afarley, creynold, grajaiya, jhrozek, jwilleford, lslebodn, mkosek, mzidek, pbrezina, sbeal, striker, yundtj |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | ppc64le | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-07-10 08:09:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Stephen Beal
2016-08-25 18:11:25 UTC
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. |