samba-gpoupdate

Wed May 8 16:03:45 UTC 2024

On 5/8/24 9:46 AM, Stefan Metzmacher via samba-technical wrote:
> Hi David,
>
>>>>> Do we really want to apply all those gp_extensions by default?
>>>>> I would have assumed that the admin needs to configure them 
>>>>> explicitly.
>>>>>
>>>>> Pure ad dc samba internal stuff like gp_access_ext, gp_krb_ext
>>>>> and my new gp_privilege_rights_ext should run by default on an ad dc
>>>>> and only there (the server role is checked in the code).
>>>>>
>>>>> But all others messing with critical stuff in /etc looks dangerous
>>>>> without explicitly selecting them.
>>>>>
>>>>> I'm also not sure how the things from 
>>>>> get_gp_client_side_extensions() work.
>>>>
>>>> That's for loading custom client extensions (for example, if a 
>>>> company has internal policies they want applied). I'm not sure if 
>>>> anyone is using this.
>>>>
>>>> See 
>>>> https://dmulder.github.io/group-policy-book/writing-group-policy-extensions.html#cse
>>>>
>>>> The `register_gp_extension` and `unregister_gp_extension` functions 
>>>> control the policies added by get_gp_client_side_extensions().
>>>>
>>>> Notice the `samba-tool gpo cse register` and `samba-tool gpo cse 
>>>> unregister` commands also.
>>>
>>> Ok, I think it would be useful if all extensions would go via this 
>>> and would
>>> be listed by 'samba-tool gpo cse list'.
>>  >
>>> In addition something like 'samba-tool gpo cse enable' and
>>> 'samba-tool gpo cse disable' would be useful in order to give the 
>>> admin more control
>>> over it. Then 'samba-tool gpo cse list' could list all active once
>>> and 'samba-tool gpo cse list-available' would list all possible once.
>>>
>>> The only question is how this could be done in a compatible way 
>>> compared
>>> to released samba versions.
>>
>> I'm currently working on auto register builtin cses in 
>> parse_gpext_conf()
>>
>> There I'll try to work out if the registration should enable or disable
>> them based on 'apply group policies = yes' and the existence of gpo.tdb
>>
>> And instead of a absolute filepath I think a python module name like
>> "samba.gp.gp_sec_ext" should be possible, that makes it much easier
>> to test without changes with 'bin/samba-gpoupdate' without make install.
>> And also with packaging changes.
>>
>> All registered cses in gpext.conf will also get MachinePolicyDisabled
>> and UserPolicyDisabled.'samba-tool gpo cse update' will let admins 
>> change it explicitly.
>> And get_gp_client_side_extensions() will only return enabled policies.
>
> Ok, I now found that cse GUID are wellknown things.
>
> E.g. MS-GPSB specifies:
>
> CSE GUID{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
> Tool extension GUID (computer policy 
> settings){803E14A0-B4FB-11D0-A0D0-00A0C90F574B}
>
> And these are stored in the gPCMachineExtensionNames and 
> gPCUserExtensionNames attributes.
> And our client completely ignores them.
>
> I also found that we only process single changed policies unless 
> samba-gpupdate --force is used,
> but it's important to process all policies related to a cse in the 
> correct order.
>
> For the [Privilege Rights] feature it's extremely important to get the 
> order correct,
> as per Right/Privilege only the first processed policy should be 
> applied and all others are
> ignored. So 'SeUndockPrivilege = *S-1-5-32-544' in the first policy 
> and 'SeUndockPrivilege = *S-1-5-32-545'
> as well as 'SeEnableDelegationPrivilege = *S-1-5-32-545' in the 2nd 
> policy means that the
> effective result looks like this:
>
> SeUndockPrivilege = *S-1-5-32-544
> SeEnableDelegationPrivilege = *S-1-5-32-544
>
> and the 'SeUndockPrivilege = *S-1-5-32-545' from the 2nd policy is 
> ignored.
>
> While researching on this I found that we apply the policies in the 
> wrong order,
> assume the following:
>
>
> DC=domain,DC=example
> - DomainGPO1
> - DomainGP02
> - DomainGP03 (enforced)
> - DomainGP04 (enforced)
> OU=SomeOU,DC=domain,DC=example
> - SomeOUGPO1
> - SomeOUGPO2
> - SomeOUGPO3 (enforced)
> - SomeOUGPO4 (enforced)
> OU=Computers,OU=SomeOU,DC=domain,DC=example
> - ComputersGPO1
> - ComputersGPO2
> - ComputersGPO3 (enforced)
> - ComputersGPO4 (enforced)
>
> Default-first-Site-Name:
> - SiteGPO1
> - SiteGPO2
> - SiteGPO3 (enforced)
> - SiteGPO4 (enforced)
>
> Gives the following order for CN=computer,OU=SomeOU,DC=domain,DC=example:
>
> SiteGPO3
> SiteGPO4
> DomainGPO3
> DomainGPO4
> SomeOUGPO3
> SomeOUGPO4
> ComputersGPO3
> ComputersGPO4
> ComputersGPO1
> ComputersGP02
> SomeOUGPO1
> SomeOUGPO2
> DomainGPO1
> DomainGPO2
> SiteGPO1
> SiteGPO2
>
> While samba-gpupdate --rsop shows this:
>
> GPO: SiteGPO2
> GPO: SiteGPO1
> GPO: DomainGPO2
> GPO: DomainGPO1
> GPO: SomeOUGPO2
> GPO: SomeOUGPO1
> GPO: ComputersGPO2
> GPO: ComputersGPO1
> GPO: SiteGPO4
> GPO: SiteGPO3
> GPO: DomainGPO4
> GPO: DomainGPO3
> GPO: SomeOUGPO4
> GPO: SomeOUGPO3
> GPO: ComputersGPO4
> GPO: ComputersGPO3
Well that's odd. The GPO order is determined by get_gpo_list, which I 
thought followed [MS-GPOL] 3.2.5.1 pretty closely. It looks like we're 
doing it backwards at first, then have some of them mixed up.

-- 
David Mulder
Labs Software Engineer, Samba
SUSE
1221 S Valley Grove Way, Suite 500
Pleasant Grove, UT 84062
(P)+1 385.208.2989
dmulder at suse.com
http://www.suse.com