Learn more about these different git repos.
Other Git URLs
We've recently started receiving a lot of complaints from users about broadcast messages of the form:
Message from syslogd@hostname at Dec 4 09:08:35 ... sssd[be[domain.lan]]:Group Policy Container with DN [cn={66062A26-FA18-4C56-A7E1-B22209856319},cn=policies,cn=system,DC=domain,DC=lan] is unreadable or has unreadable or missing attributes. In order to fix this make sure that this AD object has following attributes readable: nTSecurityDescriptor, cn, gPCFileSysPath, gPCMachineExtensionNames, gPCFunctionalityVersion, flags. Alternatively if you do not have access to the server or can not change permissions on this object, you can use option ad_gpo_ignore_unreadable = True which will skip this GPO.See 'man ad_gpo_ignore_unreadable for details.'
We've reviewed the AD object with that DN and determined that they are scoped to specific sets of workstations using AD groups, such as "Domain Laptops". As far as we can tell, this is entirely normal, and there's no reason to log an error, much less broadcast a message to every open terminal every time GPOs are processed.
I'm aware of the ad_gpo_ignore_unreadable setting, but the default seems to be the wrong behavior, and I'd like to suggest changing that.
Metadata Update from @ppolawsk: - Issue assigned to ppolawsk
Just to add a bit more info. SSSD here determined that the unreadable GPO container is a container associated with Group Policy that is applicable to the target (user that is being logged in). Inability to read this container always results in denial of access. So, you only see this error when someone tries to login, but is denied because of the missing/unreadable container.
So it is like: 1. user tries to log in 2. there is a GPO policy that applies to this user 3. we can not read that GPO policy 4. deny access to user (and generate the log message that is seen in this issue)
Here is upstream pull request which should solve the issue with error message level: https://github.com/SSSD/sssd/pull/983
" So, you only see this error when someone tries to login, but is denied because of the missing/unreadable container."
That doesn't seem to be the case. As far as we know, no access denials occur. Users log in and periodically during their work, the warning is logged in their terminal.
Our AD admins believe that scoping these GPOs using permissions is the correct mechanism to control whether they apply to a user or not. How does sssd determine that the GPO applies to a user? In other words, should our admins be using a different mechanism to scope those GPOs?
master
Metadata Update from @pbrezina: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @pbrezina: - Custom field design_review adjusted to on - Custom field mark adjusted to on - Custom field patch adjusted to on - Custom field review adjusted to on - Custom field sensitive adjusted to on - Custom field testsupdated adjusted to on - Issue status updated to: Open (was: Closed)
Reopening until @mzidek answers the question.
" So, you only see this error when someone tries to login, but is denied because of the missing/unreadable container." That doesn't seem to be the case. As far as we know, no access denials occur. Users log in and periodically during their work, the warning is logged in their terminal. Our AD admins believe that scoping these GPOs using permissions is the correct mechanism to control whether they apply to a user or not. How does sssd determine that the GPO applies to a user? In other words, should our admins be using a different mechanism to scope those GPOs?
To limit the scope you can use the "Security filtering" list in the GPO (go to Group Policy Management console, click on the GPO you wont to edit and under the "Scope" tab you will see "Security filtering").
That way you can make the GPO not applicable to the targer user/group. By default there is "Authenticated users" which basically makes it apply to everybody.
I wonder why your users were able to login despite the error being shown. Maybe it was just log showing that someone tried to log in, but could not (but not themselves?). I would need to see the logs + name and SID of user that tried to login (successfully) if the message was really about his login or someone else's.
Metadata Update from @thalman: - Issue tagged with: Future milestone
To limit the scope you can use the "Security filtering" list in the GPO
I want to clarify: that is what our domain admins are doing now. They've applied filters to a GPO, sssd can't read it because it's filtered to systems that don't include the system running sssd, and sssd is logging this as a critical failure, spamming all of the open terminals with warnings repeatedly.
Can we agree that this is not a critical failure and fix the logging settings?
Yes, the logging issue has been fixed in https://pagure.io/SSSD/sssd/c/9188aa17d9c4dfec1d5744981ea8855465965808 There was a typo in code that ended up in sending syslog emergency message which was then printed in the terminals.
I'm closing this as fixed. Thank you.
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/5094
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.