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

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

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

But the problem specify in #2750 is still there.

Thank you for confirmation.

resolution: => worksforme
status: new => closed

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.

attachment
GPO_failed_1.13.1_alpha.log

Fields changed

resolution: worksforme =>
status: closed => reopened

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.2

Fields changed

rhbz: => todo

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

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

hi lslebodn,

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

Puthi

Are you able to reproduce it on another machine?

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

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.

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.

Fields changed

milestone: SSSD 1.13.3 => SSSD Deferred

Failing gpo-cache file joopmartens
GptTmpl.inf

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}

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
(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.

Regarding format Lukas is correct.

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?

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.

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?

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.

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.

Moving from deferred to need triage

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

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.

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..

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

Sure:

1. Open the Microsoft Windows Group Policy Management console on a domain controller.
2. Edit one of your Domain Policies. (E.g. Default Domain Policy)
3. 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.

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.

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.

Improved error reporting:

master:

• dad416a

sssd-1-13:

• 148c12d

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)"

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

milestone: NEEDS_TRIAGE => SSSD 1.14 alpha

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

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

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

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

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]

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]

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/3792

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.