SSSD can't process GPO from Active Directory when it contains lines with no equal sign #3792

sssd-bot · 2020-05-02T13:17:30Z

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2751

Created at 2015-08-07 13:34:11 by puthi
Closed as Fixed
Assigned to nobody
Associated bugzillas
- https://bugzilla.redhat.com/show_bug.cgi?id=1377213
- https://bugzilla.redhat.com/show_bug.cgi?id=1316164

Updated description:[[BR]]
The problem was that libini parser could not handle non key-value lines and the GPO file can contain them. These lines are not interesting for us in the GPO processing but they made the whole parsing fail. This problem will be solved by adding new parser flag to libini to ignore these lines. SSSD will use this flag when parsing GPO files.

Original description[[BR]]

SSSD can download GPO from Active Directory but fail at the processing stat with the following error:

[ad_gpo_access_done] (0x0040): GPO-based access control failed.

[be_pam_handler_callback] (0x0100): Backend returned: (3, 4, No such file or directory) [Internal Error (System error)]

This problem happens in SSSD 1.12.5, 1.12.90 and 1.13.0

Comments

Comment from lslebodn at 2015-08-11 10:07:05

There was recent GPO related fix in sssd master #2713.
Which is not in sssd master. Could you try with sssd master? You can build rpms with command "make rpms" or "make prerelease-rpms".

cc: => lslebodn@redhat.com

Comment from puthi at 2015-08-11 10:27:52

I'll try it out and let you know the result.
Thanks

Comment from puthi at 2015-08-11 11:44:56

I built the rpm from master afa6ac7 and the problem reported here is fixed.

But the problem specify in #2750 is still there.

Comment from lslebodn at 2015-08-11 12:11:43

Thank you for confirmation.

resolution: => worksforme
status: new => closed

Comment from puthi at 2015-08-11 12:40:03

Hi lslebodn,
I'm sorry I just double check and found that the version installed on my server was 1.12.2, i put the new built package in my repository but i didn't enable it in my yum configuration.

I just retest on 1.13.1 (master afa6ac7) and the problem is still there. I also attach the log here. Please reopen the ticket.

Comment from puthi at 2015-08-11 12:40:41

attachment
GPO_failed_1.13.1_alpha.log

Comment from lslebodn at 2015-08-11 13:11:04

Fields changed

resolution: worksforme =>
status: closed => reopened

Comment from jhrozek at 2015-08-18 11:55:32

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.2

Comment from jhrozek at 2015-08-18 12:11:30

Fields changed

rhbz: => todo

Comment from lslebodn at 2015-10-23 09:36:25

I would like to apologise for late response.

The most interesting part of log file is:

(Tue Aug 11 17:31:03 2015) [sssd[be[]]] [ad_gpo_cse_done] (0x0400): gpo_guid: {34EDA8E3-E495-4AAB-ABD7-075E7E13DEF8}
(Tue Aug 11 17:31:03 2015) [sssd[be[]]] [ad_gpo_store_policy_settings] (0x0020): ini_config_parse failed [5][Input/output error]

The file with gpo could not be parsed with INI parse.
Could you provide content of the "{34EDA8E3-E495-4AAB-ABD7-075E7E13DEF8}"? sssd caches gpo in directory /var/lib/sss/gpo_cache/. But in your case it might not be in this directory because sssd try to parse GPO from memory and then it sores it to htat directory (IIRC)

_comment0: I would like to apologise for late response.

The most interesting part of log file is:
{{{
(Tue Aug 11 17:31:03 2015) [sssd[be[]]] [ad_gpo_cse_done] (0x0400): gpo_guid: {34EDA8E3-E495-4AAB-ABD7-075E7E13DEF8}
32 (Tue Aug 11 17:31:03 2015) [sssd[be[]]] [ad_gpo_store_policy_settings] (0x0020): ini_config_parse failed [5][Input/output error]
}}}

The file with gpo could not be parsed with INI parse.
Could you provide content of the "{34EDA8E3-E495-4AAB-ABD7-075E7E13DEF8}"? sssd caches gpo in directory /var/lib/sss/gpo_cache/. But in your case it might not be in this directory because sssd try to parse GPO from memory and then it sores it to htat directory (IIRC) => 1445585808882184

Comment from jhrozek at 2015-10-23 10:25:50

Since we are still investigating the ticket, I will demote it from 1.13.2 to 1.13.3

milestone: SSSD 1.13.2 => SSSD 1.13.3

Comment from puthi at 2015-10-26 05:55:36

hi lslebodn,

The machine that i used to test this, is already terminated, i can't provide you that ini file any more.

Puthi

Comment from lslebodn at 2015-10-26 07:52:53

Are you able to reproduce it on another machine?

Comment from puthi at 2015-10-26 08:03:58

Replying to [comment:12 lslebodn]:

Are you able to reproduce it on another machine?

Hi, the test GPO was also removed a few weeks back. Sure, I can reproduce it but it will takes me sometimes to setup everything back again. I will update this ticket once i have sometimes to work on it. it will take quite a bit of time though, as i'm quite busy with other task now.

Puthi

Comment from lslebodn at 2015-10-26 13:43:39

Replying to [comment:13 puthi]:

Replying to [comment:12 lslebodn]:

Are you able to reproduce it on another machine?

Hi, the test GPO was also removed a few weeks back. Sure, I can reproduce it but it will takes me sometimes to setup everything back again. I will update this ticket once i have sometimes to work on it. it will take quite a bit of time though, as i'm quite busy with other task now.

Puthi
You can ping me on IRC freenode #sssd when you will have time for troubleshooting.

Comment from jhrozek at 2015-12-10 09:58:53

I think we should defer this ticket until we know what GPO caused issues. When we have the faulty file again to dissect, we can plan the ticket again for a particular release.

Comment from jhrozek at 2015-12-10 16:37:31

Fields changed

milestone: SSSD 1.13.3 => SSSD Deferred

Comment from joopmartens at 2016-02-13 10:17:00

Failing gpo-cache file joopmartens
GptTmpl.inf

Comment from joopmartens at 2016-02-13 10:28:17

It seems that I'm suffering the same issue:

(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [child_sig_handler] (0x0100): child [4821] finished successfully.
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [gpo_cse_done] (0x0400): sysvol_gpt_version: 8847631
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_cse_done] (0x0400): gpo_guid: {4901DA9A-6B54-43AC-BF80-B6EF6C2CA64E}
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_store_policy_settings] (0x0020): ini_config_parse failed [5][Input/output error]
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_store_policy_settings] (0x0020): Error encountered: 5.
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_cse_done] (0x0040): ad_gpo_store_policy_settings failed: [5](Input/output error)
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, Input/output error) [Internal Error (System error)]

This issue is only occuring on my CentOs 7 server running sssd 1.13.0-40.el7_2.1.\
My servers running Cent-OS 7 sssd 1.12.2-58.el7_1.17 or all my CentOs 6 servers do not show this issue.\

It all started after creating a Fine-Grained Password Policy.

I have attached my GptTmpl.inf gpo cache file from the gpo_guid: {4901DA9A-6B54-43AC-BF80-B6EF6C2CA64E}

Comment from lslebodn at 2016-02-13 11:32:08

Replying to [comment:17 joopmartens]:

It seems that I'm suffering the same issue:
{{{
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [child_sig_handler] (0x0100): child [4821] finished successfully.
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [gpo_cse_done] (0x0400): sysvol_gpt_version: 8847631
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_cse_done] (0x0400): gpo_guid: {4901DA9A-6B54-43AC-BF80-B6EF6C2CA64E}
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_store_policy_settings] (0x0020): ini_config_parse failed [5][Input/output error]
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_store_policy_settings] (0x0020): Error encountered: 5.
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_cse_done] (0x0040): ad_gpo_store_policy_settings failed: [5](Input/output error)
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
(Fri Feb 12 16:09:09 2016) [sssd[be[X.LOCAL]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, Input/output error) [Internal Error (System error)]
}}}
This issue is only occuring on my CentOs 7 server running sssd 1.13.0-40.el7_2.1.\
My servers running Cent-OS 7 sssd 1.12.2-58.el7_1.17 or all my CentOs 6 servers do not show this issue.\

It all started after creating a Fine-Grained Password Policy.

I have attached my GptTmpl.inf gpo cache file from the gpo_guid: {4901DA9A-6B54-43AC-BF80-B6EF6C2CA64E}

I didn't try but it's very likely that it fails due to last two lines in GptTmpl.inf

[Service General Setting]
"RemoteRegistry",2,""

I think that INI format should be key = value
but I'm not expert in GPO format.

Comment from dpal at 2016-02-13 12:40:00

Regarding format Lukas is correct.

Comment from joopmartens at 2016-02-15 13:20:55

Then this could be related to the Computer Configuration > Policies > Windows Settings > Security Settings > System Services > Remote Registry setting that I have recently changed to "automatic". Since I used the regular group policy management console at my Windows server this seems to be way it is saved in the group-policy file.

I have checked the GptTmpl.inf files on my other machines that don't show any errors/problems (Running other verions of SSSD) and they also contain these 2 lines.

So the question still remains why does SSSD 1.13 has a problem with this?

Comment from lslebodn at 2016-02-15 14:19:54

gpo was not in enforcing by default in sssd-1.12
Therefore if sssd failed to parse GPO file (ini file)
then there was only error message in log files that access will be denied in GPO enforcing mode.

Another explanation might be that problematic ini files were not used on another machines.

Comment from dpal at 2016-02-15 14:37:01

When we developed the feature we were not aware that there might be fields that are not in the standard INI format. This seems strange that MSFT suddenly changed the format. May be it is a bug on their side? Have you tried changing it into the
RemoteRegistry=2 and seeing if the policy applies cleanly?
Is it even the field that matters on Linux? May be we should ignore and suppress some of the errors and use best effort parsing rather than choke on the errors?

Comment from joopmartens at 2016-02-15 15:23:56

Changing the line to {{{RemoteRegistry=2}}} solves the issue.\
Since the line {{{"RemoteRegistry",2,""}}} is generated by the original Microsoft tooling SSSD should rather not deny access on it (in my opinion).\

I'm not an expert in GPO format either though ignoring lines and using best effort parsing could be a security breach.\

I personally would rather support this particular line in the parsing process and add extra parsing support while applicable.\

It would also be helpful if lines with parse errors could be logged in the SSSD logging. This would save some time in troubleshooting future parsing errors.

Comment from joopmartens at 2016-02-15 15:26:49

I forgot to mention that this field does not matter on Linux. This value enables Windows machines to automatically start the remote registry service on startup.

Comment from lslebodn at 2016-02-15 15:29:05

Moving from deferred to need triage

cc: lslebodn@redhat.com => lslebodn
milestone: SSSD Deferred => NEEDS_TRIAGE

Comment from dpal at 2016-02-15 19:48:36

See ini_parse_ut.c for a better handling of the errors. The code in ad_gpo.c now does not check or print the errors detected during parsing. The code below does, it can be taken as an inspiration.
It seems that the code does not map GPO into memory, at least this code. I though the plan was to use memory mapped parsing. Please check that as the cleanup is a bit different in this case.

 error = ini_config_parse(file_ctx,
                             INI_STOP_ON_NONE,
                             0, /* TBD */
                             0,
                             ini_config);
    if (error) {
        INIOUT(printf("Failed to parse configuration. Error %d.\n", error));

        if (ini_config_error_count(ini_config)) {
            if (in_mem) {
                INIOUT(printf("Errors detected while parsing"
                              " configuration stored in memory: %s\n",
                              in_filename));
            }
            else {
                INIOUT(printf("Errors detected while parsing: %s\n",
                        ini_config_get_filename(file_ctx)));
            }
            ini_config_get_errors(ini_config, &error_list); <- after that you just got an array of strings that you can put into debug log.
            INIOUT(ini_config_print_errors(stdout, error_list)); <- see this as an example it is in the module ini_print.c
            ini_config_free_errors(error_list);
        }
        /* If we are testing memory mapped, return error */
        if (in_mem) {
            free(stream_data);
            ini_config_file_destroy(file_ctx);
            ini_config_destroy(ini_config);
            return error;
        }
    }

I will be glad to review the changes.

Comment from jhrozek at 2016-02-18 15:42:16

In the short term we can at least print a better debug message. But I'm also interested how exactly did you configure the GPO? I would like to reproduce in my local test environment..

Comment from jhrozek at 2016-02-26 11:03:20

Hi, do you mind helping us with some instruction on how could we reproduce the bug in-house?

Comment from joopmartens at 2016-03-02 14:30:17

Sure:

Open the Microsoft Windows Group Policy Management console on a domain controller.
Edit one of your Domain Policies. (E.g. Default Domain Policy)
Set value: Computer configuration - Policies - Windows Settings - Security Settings - System Services - Remote Registry: Startup mode Automatic

After the change this settings automatically ended up in the SSSD policy cache file.

Comment from sbose at 2016-03-03 15:30:58

I dug a bit in the MSFT documentation and found [MS-GPSB] "Group Policy: Security Protocol Extension" (https://msdn.microsoft.com/en-us/library/cc232743.aspx)where the syntax of the GPO files is described. Most interestingly here is section 2.2 and its subsection.

If I understood the syntax description correctly entries in the sections [Registry Keys], [Service General Settings] and [File Security] will not have an '=' character but three item separated by a ','.

So it looks those entries are completely valid and we have to fix the parsing of the GPO files by either ignoring the option above or only looking at the [Privilege Rights] section for processing the access control rules.

Comment from dpal at 2016-03-03 16:39:20

As I said the parser reports the errors but they can be ignored. The code of SSSD needs to be fixed. I gave the hint of what needs to be done. If it is not clear let me know and I will consult in a private mail.

Comment from lslebodn at 2016-03-23 22:22:08

Improved error reporting:

master:

dad416a

sssd-1-13:

148c12d

Comment from cwhits at 2016-03-24 18:25:19

Here's another example of valid GPO syntax:

[Service General Setting]
"SNMP",2,"D:AR(D;;DCRPWPDTSDRC;;;BU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BA)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

Comment from jhrozek at 2016-03-29 12:00:59

Moving to 1.14 alpha as agreed on Mar-17 triage.

milestone: NEEDS_TRIAGE => SSSD 1.14 alpha

Comment from mzidek at 2016-04-05 11:56:47

Fields changed

rhbz: todo => https://bugzilla.redhat.com/show_bug.cgi?id=1316164
summary: SSSD can't process GPO from Active Directory. => SSSD can't process GPO from Active Directory when it contains lines with no equal sign

Comment from mzidek at 2016-04-15 11:29:35

Fields changed

description: SSSD can download GPO from Active Directory but fail at the processing stat with the following error:

[ad_gpo_access_done] (0x0040): GPO-based access control failed.

[be_pam_handler_callback] (0x0100): Backend returned: (3, 4, No such file or directory) [Internal Error (System error)]

This problem happens in SSSD 1.12.5, 1.12.90 and 1.13.0 => '''Updated description''':[[BR]]
The problem was that libini parser could not handle non key-value lines and the GPO file can contain them. These lines are not interesting for us in the GPO processing but they made the whole parsing fail. This problem will be solved by adding new parser flag to libini to ignore these lines. SSSD will use this flag when parsing GPO files.

'''Original description'''[[BR]]

SSSD can download GPO from Active Directory but fail at the processing stat with the following error:

[ad_gpo_access_done] (0x0040): GPO-based access control failed.

[be_pam_handler_callback] (0x0100): Backend returned: (3, 4, No such file or directory) [Internal Error (System error)]

This problem happens in SSSD 1.12.5, 1.12.90 and 1.13.0

Comment from jhrozek at 2016-06-20 12:00:14

The patches are on review, but I would like to release 1.14 alpha today, therefore moving to 1.14 beta.

milestone: SSSD 1.14 alpha => SSSD 1.14 beta

Comment from jhrozek at 2016-06-22 10:45:42

The ding-libs patches have been pushed as:
- fbaaf491afd199e2c401037a448052494d0f5b40
- 9591b1d8adbf195c40c123b1b5125db82e049a56
- 8481bb7eebe761ceaedadb73d84045d86723d156
and the sssd patch that makes use of them was pushed as:
- 21a28c9

resolution: => fixed
status: reopened => closed

Comment from jhrozek at 2016-06-27 22:34:10

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1316164 (Red Hat Enterprise Linux 7)

rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=1316164 => https://bugzilla.redhat.com/show_bug.cgi?id=1316164, [https://bugzilla.redhat.com/show_bug.cgi?id=1316164 1316164]

Comment from jhrozek at 2016-09-19 11:23:16

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1377213 (Red Hat Enterprise Linux 6)

rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=1316164, [https://bugzilla.redhat.com/show_bug.cgi?id=1316164 1316164] => https://bugzilla.redhat.com/show_bug.cgi?id=1316164, [https://bugzilla.redhat.com/show_bug.cgi?id=1316164 1316164], [https://bugzilla.redhat.com/show_bug.cgi?id=1377213 1377213]

Comment from puthi at 2017-02-24 14:30:07

Metadata Update from @puthi:

Issue set to the milestone: SSSD 1.14 beta

The text was updated successfully, but these errors were encountered:

sssd-bot added Bugzilla Closed: Fixed Issue was closed as fixed. labels May 2, 2020

sssd-bot closed this as completed May 2, 2020

donovan-middleton mentioned this issue Sep 5, 2023

SSSD 2.8.2 in RHEL 8 and RHEL 9 can't process Group Policy from Active Directory when it contains lines with no equal sign. #6914

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SSSD can't process GPO from Active Directory when it contains lines with no equal sign #3792

SSSD can't process GPO from Active Directory when it contains lines with no equal sign #3792

sssd-bot commented May 2, 2020