Learn more about these different git repos.
Other Git URLs
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: 1. Set ad_gpo_access_control = enforcing 2. Create a nested OU hierarchy with the host residing in the leaf OU (OU=Leaf,OU=Parent,DC=domain,DC=com) 3. Create Problem_GPO linked to the parent OU with both HBAC and Service settings (Computer Configuration / Policies / Windows Settings / Security Settings / System Services). 4. Observe that this creates a gplTmpl.inf with a setting as such: [Service General Setting] "BITS",3,"" "Netman",3,"" 5. Create Leaf_HBAC_GPO with HBAC settings on the leaf OU allowing you to log in 6. Clear GPO cache and restart SSSD
ad_gpo_access_control = enforcing
OU=Leaf,OU=Parent,DC=domain,DC=com
Problem_GPO
Computer Configuration / Policies / Windows Settings / Security Settings / System Services
[Service General Setting]
"BITS",3,""
"Netman",3,""
Leaf_HBAC_GPO
Expected results: * SSSD should ignore the unknown settings, and only parse the settings under [Privilege Rights]. * SSSD should preferentially apply Leaf_HBAC_GPO settings from the leaf OU over those from the parent Problem_GPO
[Privilege Rights]
Actual results: * HBAC will not apply, and logins will be denied. Errors will be logged under /var/log/sssd/sssd_fqdn.log: [sssd[be[fqdn]]][ad_gpo_store_policy_settings](0x0020):Error (5) on line 21: Equal sign is missing.
[sssd[be[fqdn]]][ad_gpo_store_policy_settings](0x0020):Error (5) on line 21: Equal sign is missing.
Mitigation: * Create a Fixer_GPO with only HBAC settings linked to the parent OU, and give it a higher link order (lower precedence) than the Problem_GPO. This causes SSSD to incorrectly ignore the problematic GPO (see #4145), and eventually parse the superior Leaf_HBAC_GPO
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
This is occurring on SSSD 2.2.0 running on CentOS 8.
ok, this version should include all needed fixes. Can you add debug_level = 9 to the [domain/...] section of sssd.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 containing ad_gpo_store_policy_settings.
debug_level = 9
[domain/...]
sssd.conf
ad_gpo_store_policy_settings
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
[Unicode] Unicode=yes [Version] signature="$CHICAGO$" Revision=1 [Service General Setting] "ALG",2,"" [Privilege Rights] SeDenyRemoteInteractiveLogonRight = MyUser.Name
sssd_internal.domain.fqdn.log
(Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [sysdb_gpo_dn] (0x4000): gpoGUID={30B6EDE3-122C-4BB8-A7D3-9E099FF6DCF3},cn=gpos,cn=ad,cn=custom,cn=internal.domain.fqdn,cn =sysdb (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_callback": 0x5555d8107dd0 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_timeout": 0x5555d8163ac0 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Running timer event 0x5555d8107dd0 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8163ac0 "ldb_kv_timeout" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8107dd0 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [sysdb_merge_res_ts_attrs] (0x2000): TS cache doesn't handle this DN type, skipping (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [sysdb_gpo_store_gpo] (0x4000): Updating new GPO [internal.domain.fqdn][{30B6EDE3-122C-4BB8-A7D3-9E099FF6DCF3}] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_callback": 0x5555d8030f70 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_timeout": 0x5555d8096180 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Running timer event 0x5555d8030f70 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8096180 "ldb_kv_timeout" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8030f70 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_cse_done] (0x0400): gpo_guid: {30B6EDE3-122C-4BB8-A7D3-9E099FF6DCF3} (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x0020): [/var/lib/sss/gpo_cache/internal.domain.fqdn/Policies/{30B6EDE3-122C-4BB8-A7D3-9E 099FF6DCF3}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf]: ini_config_parse failed [5][Input/output error] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x0020): Error (5) on line 7: Equal sign is missing. (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): allow_key = SeInteractiveLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeInteractiveLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): deny_key = SeDenyInteractiveLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeDenyInteractiveLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): allow_key = SeRemoteInteractiveLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeRemoteInteractiveLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): deny_key = SeDenyRemoteInteractiveLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [sysdb_gpo_result_dn] (0x4000): cn=gpo_result,cn=gpos,cn=ad,cn=custom,cn=internal.domain.fqdn,cn=sysdb (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_callback": 0x5555d8096180 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_timeout": 0x5555d8121f20 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Running timer event 0x5555d8096180 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8121f20 "ldb_kv_timeout" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8096180 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [sysdb_merge_res_ts_attrs] (0x2000): TS cache doesn't handle this DN type, skipping (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [sysdb_gpo_store_gpo_result_setting] (0x0400): Updating setting: key [SeDenyRemoteInteractiveLogonRight] value [MyUser.Name] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): start ldb transaction (nesting: 1) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_callback": 0x5555d8096180 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Added timed event "ldb_kv_timeout": 0x5555d8121f20 (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Running timer event 0x5555d8096180 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8121f20 "ldb_kv_timeout" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): Destroying timer event 0x5555d8096180 "ldb_kv_callback" (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): commit ldb transaction (nesting: 1) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): allow_key = SeNetworkLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeNetworkLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): deny_key = SeDenyNetworkLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeDenyNetworkLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): allow_key = SeBatchLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeBatchLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): deny_key = SeDenyBatchLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeDenyBatchLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): allow_key = SeServiceLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeServiceLogonRight] (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_store_policy_settings] (0x4000): deny_key = SeDenyServiceLogonRight (Thu Jan 30 09:43:45 2020) [sssd[be[internal.domain.fqdn]]] [ad_gpo_extract_policy_setting] (0x4000): section/name not found: [Privilege Rights][SeDenyServiceLogonRight]
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 a key = value pattern. As can be see in the logs SeDenyRemoteInteractiveLogonRight was detected in the [Privilege Rights] section and was stored in the cache with the value MyUser.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.
Equal sign is missing.
key = value
SeDenyRemoteInteractiveLogonRight
MyUser.Name
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.
Hi, It appears that the issue was a combination of #4145, and that HBAC rules using unresolved usernames (user.name or user.name@realm.fqdn, as opposed to SIDs) are not respected.
user.name
user.name@realm.fqdn
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.
Hi, It appears that the issue was a combination of #4145, and that HBAC rules using unresolved usernames (user.name or user.name@realm.fqdn, as opposed to SIDs) are not respected. Is this intentional, or should I create a new ticket?
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.
Metadata Update from @thalman: - Issue tagged with: Future milestone
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/5102
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.
Metadata Update from @pbrezina: - Issue close_status updated to: cloned-to-github - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.