Open sssd-bot opened 4 years ago
Just an update-- this issue still persists as of RHEL 9.3 (SSSD 2.9.1). Setting Policies --> Windows Settings --> Security Settings --> System Services --> [Any service] Creates a [System General Setting]
within gptTmpl.inf that seems to cause SSSD's gpo parser to error out with a very large traceback.
If the system is simply retrying with those lines excluded this probably should not have a traceback, which typically indicates a major failure.
Hi,
thank you for reviving this issue. As mentioned in some older comments SSSD might parse the policy file twice, first with strict ini syntax rule and, if an error occurs, with more relaxed rules. I have to admit that I do not remember why there are two runs and the relaxed rules are not used in the first place. Maybe we wanted to understand how often this happens and which kind of policies do not follow the ini syntax rules?
However, there are two possible ways to avoid the backtraces in cases where the strict rules do not work. The debug level of the messages in the first run can be changed to SSSDBG_IMPORTANT_INFO
which will not cause a backtrace and of there is an error unrelated to the syntax the backtrace will be generated in the second run where most probably the same issue will occur. Or we can remove the first run completely and just parse all GPO files with the relaxed rules.
bye, Sumit
Thanks for the quick response.
The backtraces are my fault as I usually run with debug levels at 4 or 6 as it makes tracking down issues easier. I mention them because they still are usually indicative of an actual problem, when in this case the files are formatted correctly and should not be showing up in logs as a problem. This also may be linked to #7159, as a combination of parsing errors seems to lead the ad_gpo_access_control
to conclude that access should be denied.q
While I would argue that there could be benefit to potentially parsing and supporting other GPO options such as importing CA trust or parsing the [Group Membership]
memberOf options (e.g. to allow adding principals into wheel
), as of now I believe sssd only actually supports options from the [Privilege Rights]
section of GptTmpl.inf anyways.
Thus I think running with relaxed rules on a single pass is correct, but I'd wonder more generally whether GPOs can just be parsed as ini files, looking for {LIST_OF_SUPPORTED_SECTIONS} (currently: [Privilege Rights]
) and ignoring unsupported sections. This would avoid raising errors that are ultimately misleading and irrelevant to SSSD's function.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/4144
Using "service" settings within a GPO will cause SSSD to error out on attempting to parse it. These are valid GPOs generated with gpedit and are able to be parsed by Windows machines, but they cause SSSD to error out, cease parsing further GPOs, and deny logins due to HBAC.
Steps to reproduce:
ad_gpo_access_control = enforcing
OU=Leaf,OU=Parent,DC=domain,DC=com
)Problem_GPO
linked to the parent OU with both HBAC and Service settings (Computer Configuration / Policies / Windows Settings / Security Settings / System Services
).[Service General Setting]
"BITS",3,""
"Netman",3,""
Leaf_HBAC_GPO
with HBAC settings on the leaf OU allowing you to log inExpected results:
[Privilege Rights]
.Problem_GPO
Actual results:
[sssd[be[fqdn]]][ad_gpo_store_policy_settings](0x0020):Error (5) on line 21: Equal sign is missing.
Mitigation:
Comments
Comment from sbose at 2020-01-23 18:27:53
Hi,
which version of SSSD are you using? This sounds very similar to https://pagure.io/SSSD/sssd/issue/2751 which should be fix since sssd-1.14 and ding-libs-0.6.0.
bye, Sumit
Comment from lordlimecat at 2020-01-23 18:46:28
This is occurring on SSSD 2.2.0 running on CentOS 8.
Comment from sbose at 2020-01-29 10:30:56
Hi,
ok, this version should include all needed fixes. Can you add
debug_level = 9
to the[domain/...]
section ofsssd.conf
restart SSSD and run an authentication with enforced GPO checks? Please attach the domain log file to this ticket afterwards or, if you prefer, only the lines containingad_gpo_store_policy_settings
.bye, Sumit
Comment from lordlimecat at 2020-01-30 16:55:21
Attaching log. Obviously sanitized but you can see the issue. In this situation, I added a user that was currently allowed by HBAC to a new GPO that denied their remote interactive login. The new setting was ignored and the user was still allowed login. Due to the other bug (#4145) I tried this with multiple link orders, but the result was the same: the GPO is ignored along with all its HBAC settings.
Also attaching the GptTmpl.inf from the GPO. This gpo was created from the windows GPMC.msc by configuring a Service state and an HBAC role.
GPTTmpl.inf
sssd_internal.domain.fqdn.log
Comment from sbose at 2020-01-30 17:59:54
Hi,
thank you for the details. The
Equal sign is missing.
error is expected, if this occurs SSSD parses the file again trying to ignore all lines which are not in akey = value
pattern. As can be see in the logsSeDenyRemoteInteractiveLogonRight
was detected in the[Privilege Rights]
section and was stored in the cache with the valueMyUser.Name
. So I would say the file was processed correctly and the issue you are seeing might be cause by the wrong order you described in #4145.Can you attach the full log file with
debug_level = 9
to #4145? Or, if sanitizing is too cumbersome, fell free to send my the log file directly.bye, Sumit
Comment from lordlimecat at 2020-01-30 18:42:44
Hi, It appears that the issue was a combination of #4145, and that HBAC rules using unresolved usernames (
user.name
oruser.name@realm.fqdn
, as opposed to SIDs) are not respected.Is this intentional, or should I create a new ticket?
As for attaching the logs-- I do not see a way to attach them or send them other than creating a code block. Sanitization is not an issue.
Comment from sbose at 2020-01-31 16:02:10
Hi,
thanks for the hint, I was so focused on the parsing that I didn't thought about the values.
Yes, currently SSSD only handles SIDs. The main reason for skipping names is that so far we didn't found a good documentation how the names should be handled, e.g. what is the scope for short names, the local domain, the forests, trusted forests as well?
There is https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpsb/3413b381-a445-4d17-b77e-5bbfadda253b and according to this names are allowed. And the description for PRINCIPALNAMESTRING looks very much like the sAMAccountName see e.g. https://docs.microsoft.com/en-us/windows/win32/adschema/a-samaccountname. But it is not clear from which domain the name is allowed to come from.
I wonder if you can replace the names by SIDs and check if all is working as expected then? It might even solve #4145.
If this work my suggestion would be to open a ticket to document clearly that currently only SIDs are supported and maybe improve the logging in this respect as well.
A second ticket might be an RFE to add supprt for names, but we need some documentation first to understand how names should be handled here.
bye, Sumit
Comment from thalman at 2020-03-13 16:00:42
Metadata Update from @thalman: