Starting with Samba version 4.20.0, when using the Group Policy Management app included with Windows RSAT, under "Delegation", it is not possible to set "Apply group policy" to more than one group, because the app silently quits immediately. When executed again, the app presents "The specified server cannot perform the requested operation". After a "samba-tool ntacl sysvolreset", this message disappears but the recently created Group Policy Object is corrupt and delegation of permissions cannot be performed, with the error "The security ID structure is invalid". The only solution is to delete the newly created Group Policy Object. It is thus impossible to create Group Policy Objects applicable to more than one group, which pretty much makes GPOs way less useful. The same issue is still present in versions 4.21.0 and 4.21.1. Reverting to Samba 4.19.8 solves the issue and GPOs work correctly again. I classified this bug as critical because it is critical for our use. GPOs are one of the most useful features of an AD environment, being indispensable in many cases. Our Samba AD servers are running on AlmaLinux 9.4. Best regards and thank you.
seems to be a problem of your samba installation, I can't reproduce this, tested with sernet samba+ 4.20.5 here...
ah, setting the "Apply group policy" *permission* for delegated group shows the problem that you describe, okay I can confirm that fails here, too.
Confirmed same exact behavior with different 4.21.1 installations on Debian 12.
Are Samba developers aware that the only way to create practically usable GPOs is to use a Samba version (4.19.x) that is two versions behind the current one and that, according to "Samba Release Planning and Supported Release Lifetime", is scheduled for discontinuation in March 2025? https://wiki.samba.org/index.php/Samba_Release_Planning Please note that I am not bitching or demanding anything, I am grateful for what we have and I truly appreciate the hard work of the Samba team members. I am just calling attention to this fact. I really wish I could help.
Has anyone tried to bisect this? How to reproduce it easily? Say, if I configure GPO (applying to two groups) in samba 4.19, install 4.20 and do <what?> in windows?
If you configure a GPO applying to two groups in samba 4.19, it will work on Samba 4.20.x and 4.21.x. If you configure a GPO applying to two groups in samba 4.20.x and 4.21.x, the described behavior can be observed. In sum, if you use Samba 4.20.0 and newer, you cannot create a GPO applying to more than one group.
If you configure a GPO applying to two groups in samba 4.19, it will work on Samba 4.20.x and 4.21.x. If you configure a GPO applying to two groups in samba 4.20.x and 4.21.x, the described behavior can be observed. In sum, if you use Samba 4.20.0 and newer, you cannot create a GPO applying to more than one group. If my AD has lots of groups and I need to apply a particular GPO to a number of those groups, it's not really practical having to create a separate GPO with the exact same content for each one of those groups. It quickly becomes an unmanageable mess. I tested all the 4.20.x and 4.21.x versions, and they all exhibit the same behavior. The last version working correctly is 4.19.9.
I thought that my comment could be edited, but instead a whole new comment was created. Sorry for the duplicate content.
Douglas, can you take a look?
This looks like a rather unusual usage of GRO. I'm definitely not an expert in group policies, but I didn't even know about this permission until now, despite we're using group policies heavily for various things. At first I thought you can't *link* the same GRO into different places in the forest, which is not the case here. I tried to reproduce the issue, - I succeeded after actually finding the "Apply policy" permission. I don't yet see how this can be used to bisect the thing though, - at least not easily.
The first bad commit appears to be commit 7f338d6119acd5a3129248d4e61df626f4087560 Author: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Date: Mon Jan 8 15:05:35 2024 +1300 ndr: ignore trailing bytes in ndr_pull_security_ace() This returns the behaviour with ordinary ACEs to where it was with 4.19. Signed-off-by: Douglas Bagnall <douglas.bagnall@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org> BUG: https://bugzilla.samba.org/show_bug.cgi?id=15574 (cherry picked from commit 0c1f421c107be3156b3f1db75aced24a1bca3d2f)
Reverting 0c1f421c107 (and 6fb98f70c62) from 4.21.2 fixes that one too.
I see that the Release Notes for Samba 4.20.0 contain several references to changes and new functionality pertaining to ACLs/ACEs. https://www.samba.org/samba/history/samba-4.20.0.html This is the version that introduced the bug.
Thanks for the diagnostic work. I will look into it later this week.
(In reply to Douglas Bagnall from comment #14) Notes mostly to myself I suspect: 0c1f421c107be3156b3f1db75aced24a1bca3d2f was in https://gitlab.com/samba-team/samba/-/merge_requests/3489 and I think without it we fail some tests. 6fb98f70c62 is from https://bugzilla.samba.org/show_bug.cgi?id=15613 That bug casts aspersions on ndr_subcontext_size_of_ace_coda() which maybe should be looked at.
(In reply to Miguel Medalha from comment #0) Does anyone have examples of the ACLs that are causing the trouble?
Created attachment 18553 [details] acls of GPO object in sysvol folder before and after sysvolreset here is the output of samba-tool ntacl get of the GPO on sysvol
Thanks Björn. I think https://gitlab.com/samba-team/samba/-/merge_requests/3958 fixes the issue, and it also adds tests showing the failure.
Created attachment 18557 [details] patch for 4.20
Created attachment 18558 [details] patch for 4.21
Created attachment 18559 [details] patch for 4.22rc The backports are identical.
I applied the patch to version 4.21.3 and rebuilt it. Looks like it is working correctly now. Thank you, Douglas, for the good work!
Pushed to autobuild-v4-{22,21,20}-test.
This bug was referenced in samba v4-21-test: b222d6ec73af27caa4e946887059096aceaea07e e3b3db36171954d3ffdf7386f7b61c39a74b8bb9
This bug was referenced in samba v4-21-stable (Release samba-4.21.4): b222d6ec73af27caa4e946887059096aceaea07e e3b3db36171954d3ffdf7386f7b61c39a74b8bb9
This bug was referenced in samba v4-22-test: c10e71fb00479e0f7fe0933d98b9ce50e720270a e951675239b6c0071eaf34635ca2beac4d1a5c18
This bug was referenced in samba v4-20-test: a74d5beb2acac863007af1c7bd525b0e1403134a f3d65a377add30263a4d6cc71feecdfc4eb6009c
Closing out bug report. Thanks!
This bug was referenced in samba v4-22-stable (Release samba-4.22.0rc3): c10e71fb00479e0f7fe0933d98b9ce50e720270a e951675239b6c0071eaf34635ca2beac4d1a5c18
This bug was referenced in samba v4-20-stable (Release samba-4.20.8): a74d5beb2acac863007af1c7bd525b0e1403134a f3d65a377add30263a4d6cc71feecdfc4eb6009c