samba-gpoupdate

[Stefan Metzmacher]

Am 29.04.24 um 17:52 schrieb Stefan Metzmacher via samba-technical:
> Hi David,
> 
> thanks for the feedback so far!
> 
>>> 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.

>>> Also note this seems to fail badly for users not from the primary domain...
>> I wasn't aware of that. What error are you getting?
> 
> As far as I can see we're using the machine credentials to fetch the user gpos
> and try fetch them from a dc in the servers domain not in the users domain.
> 
> I think windows fetch user gpos as user from the users domain.
> I also think the servers machine credentials may not have permissions to fetch the users gpos,
> even in the same domain.

It seems windows uses a strange mix of using user and machine credentials,
I need to analyse this further.

> I also saw that we use the account name as key into the apply logs (and maybe other stuff),
> I guess we want to use the account sid instead as that can never change, while the name can.
> 
> Also change get_gplog() to take the sid (maybe in addition)
> and use the sid as primary index.
> 
> With all that how can we make that compatible with current releases?
> Any idea?

I haven't looked at the get_gplog with sid case, so let me know
if you have ideas.

Thanks!
metze