none
Errors after MS16-072 Updates

    Question

  • Hello,

    we are having some problems after the MS16-072 updates for Microsoft Windows, regarding GPO.

    After updating the client computers, they did not apply several GPOs which had group security filtering, regarding:

    • Network shares mapping
    • Shared printers mapping
    • Remote configuration of scheduled tasks

    The workaround given by the MS16-072 issue, basically set read permissions fro 'Authenticated Users' and 'Domain Computers', did not solve the problem.

    Our infrastructure consists of:

    • Domain Controller: Samba 4 over Ubuntu Server, upgraded to latest version (4.1.6)
    • File Server: Windows Server 2012R2, domain member
    • Printer Server: Windows Server 2012R2, domain member

    When we run a GPResult /h we get this 3 error messages:

    Group Policy Drive Maps failed due to the error listed below.
    Access is denied.
    Additional information may have been logged. Review the Policy Events tab in the console or the applications event log for events between ..

    Group Policy Printers failed due to the error listed below.
    Access is denied.
    Additional information may have been logged. Review the Policy Events tab in the console or the applications event log for events between ..

    Group Policy Scheduled Tasks failed due to the error listed below.
    Access is denied.
    Additional information may have been logged. Review the Policy Events tab in the console or the applications event log for events between ..

    And, in the Event Viewer, we are getting '0x80070005 Access is denied' errors, as can be seen here:

    The client-side extension could not apply user policy settings for 'Mapejat Printers Grup CaminsTECH {CAA6C767-68BB-42C2-A1E3-175AXXXXXXXX}' because it failed with error code '0x80070005 Access is denied.' See trace file for more details.

    Log Name: Application
    Source: Group Policy Printers
    Event ID: 8194
    Task Category: (2)

    We tried to set the correct permissons. RSOT is working OK, we have deleted in clients \Programdata\Microsoft\Group Policy\History, and without success.

    The only thing that solves the problem is by removing the updates that change the GPO behavior ( KB3159398 for Windows 7 and KB3163622 for Windows 10), but is a mess to remove them from all the domain computers.

    Any ideas or suggestions will be really appreciated.


    Thursday, June 30, 2016 10:49 AM

Answers

  • Hi,
     
    Am 30.06.2016 um 12:49 schrieb Albert Marques:
    > The workaround given by the MS16-072 issue, basically set read
    > permissions fro 'Authenticated Users' and 'Domain Computers',
     
    It is not a workaround(!). It is the new permission ruleset, thats need
    to be set for the new GP INfrastructure proces.
     
    The computer object needs read access to the Group Policy Object and the
    User Object itself, including the whole path (DN), otherwise the
    computer can not collect the GPOs (read gPLink Attribute) or read the
    content of the GPO.
     
    Thats it. If this is applied by using AuthUsers or Domain Computers
    makes no difference in this concept.
     
    > did not solve the problem.
     
    Then, you did something wrong. And you can see this in your errorcode:
    '0x80070005 Access is denied'
     
    the object is still not allowed to read the source -> Access denied.
     
    Make sure the computer can read the userobjects DN and the GPOs aswell.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 11:03 AM
  • Hello,

    I've solved the problem.

    Following the links given, I've arrived to this post: https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/ where explains how to deep-log the GPP system.

    Once done I've found that the folder per-GPO created in the SYSVOL\Domain\Policies have the correct set of permissions, although they are not expanded to the content of the folders. Forcing 'Replace all child object permission entries..." via NTFS ACL the correct permissions have been set, and the GPP are working.

    I don't know why this happened this way. Maybe is because the Domain Controller is a Samba Linux computer.

    But now, the problem is solved.

    Thank you very much for your help!



    Friday, July 1, 2016 11:58 AM

All replies

  • Hi,
     
    Am 30.06.2016 um 12:49 schrieb Albert Marques:
    > The workaround given by the MS16-072 issue, basically set read
    > permissions fro 'Authenticated Users' and 'Domain Computers',
     
    It is not a workaround(!). It is the new permission ruleset, thats need
    to be set for the new GP INfrastructure proces.
     
    The computer object needs read access to the Group Policy Object and the
    User Object itself, including the whole path (DN), otherwise the
    computer can not collect the GPOs (read gPLink Attribute) or read the
    content of the GPO.
     
    Thats it. If this is applied by using AuthUsers or Domain Computers
    makes no difference in this concept.
     
    > did not solve the problem.
     
    Then, you did something wrong. And you can see this in your errorcode:
    '0x80070005 Access is denied'
     
    the object is still not allowed to read the source -> Access denied.
     
    Make sure the computer can read the userobjects DN and the GPOs aswell.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Thursday, June 30, 2016 11:03 AM
  • Refer the following thread and check for the solutions given by Brent Hu. Hope it helps.

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/144389b7-dda7-4de5-b218-ee02d9031299/gpp-scheduled-tasks-security-principals-and-sids-functionality-change?forum=winserverGP

    Thursday, June 30, 2016 11:17 AM
  • Hi Albert,

    Thanks for your post.

    For the problem of MS16-072, I suggest you run PowerShell to check if the problem caused by permission of Authenticated Users or domain computers.

    For detailed information, you could refer to the article below.

    MS16-072 – Known Issue – Use PowerShell to Check GPOs

    https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/

    Here is an article below about how to resolved the problem of MS16-072 updates and FAQs may be helpful to you.

    Deploying Group Policy Security Update MS16-072 \ KB3163622

    https://blogs.technet.microsoft.com/askds/2016/06/22/deploying-group-policy-security-update-ms16-072-kb3163622/

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, July 1, 2016 6:42 AM
    Moderator
  • Hello,

    I've solved the problem.

    Following the links given, I've arrived to this post: https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/ where explains how to deep-log the GPP system.

    Once done I've found that the folder per-GPO created in the SYSVOL\Domain\Policies have the correct set of permissions, although they are not expanded to the content of the folders. Forcing 'Replace all child object permission entries..." via NTFS ACL the correct permissions have been set, and the GPP are working.

    I don't know why this happened this way. Maybe is because the Domain Controller is a Samba Linux computer.

    But now, the problem is solved.

    Thank you very much for your help!



    Friday, July 1, 2016 11:58 AM
  • > I don't know why this happened this way. Maybe because the Domain
    > Controller is a Samba Linux computer.
     
    Wrong default ACLs and inheritance on the "Policies" Folder, most
    probably :-)
     
    Friday, July 1, 2016 2:01 PM