Samba gpo moving foward

David Mulder dmulder at suse.com
Fri Mar 23 19:12:43 UTC 2018


First off, sorry for the long email, but I feel it's necessary to give
some background.

I'd like to start a discussion on how the GPO code should be
designed/implemented. I'd like to get comments and feedback so we can
get some consensus about how to move forward.

If you don't already know what Group Policy is, you could start here:
https://en.wikipedia.org/wiki/Group_Policy

First off, I'll explain how Group Policy works in Windows (or as best I
understand it, anyway).


How GPO Works on Windows
-----------------------------------------------------------------------
At startup, and at a variable interval during runtime, the gpupdate
command is executed, which determines the list of applicable gpos for
the machine, then copies (via smb) those gpos from the sysvol share and
stores them in a Group Policy Template (GPT), which is just a local
cache of applicable gpos. This local cache allows the offline apply of
policies (to enforce policies even when a machine is off a company
network, etc).

User policy apply is similar. User policy is only applied when the user
authenticates. It is also applied by the gpupdate command, which will
check applicable gpos for the user, then store them in the GPT.

After storing gpos in the local GPT cache (if online), the group policy
client side extensions (CSE's) are called for each gpo to search for
policy to apply.

CSEs are compartmentalized modules for applying individual policies.
Essentially, a CSE will read a single file stored on the sysvol share,
and know where in the system to apply that policy.

Another important aspect of group policy is not leaving policy behind
when removed (tattooing). A list of prior settings needs to be kept on
the client to ensure policies are reverted if, for example, a gpo is
deleted, or the machine is removed from the domain, etc.

CSEs can be added or removed. On windows, a list of current extensions
is kept in the registry at HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon\GPExtensions

The extensions are listed via a unique guid that identifies the
extensions. Vendors can write their own client side extensions and add
them to this list (I don't know where on a Windows system these CSEs are
stored).

Group policies are set via the Group Policy Management console (gpmc),
which is an mmc plugin in Windows. Vendors can create custom gpmc
extensions for modifying policies which can be applied via custom CSEs.
So, a gpmc extension allows assigning custom policy, while a client side
extension allows applying that custom policy.

That's a general overview, if I've missed something, feel free to
correct me.


Proprietary unix gpo
-----------------------------------------------------------------------
Now, there are current proprietary programs that implement group policy
for unix/linux systems (such as vintela and centrify). I know one of
these vendors implements gpupdate in a way very similar to windows
(except they store the list of enabled client side extensions in a
static text file, since there is no registry).


So, how should we go about this in Samba?
-----------------------------------------------------------------------
Currently we have a samba_gpoupdate command, which can apply machine
policy at startup and at a variable interval. Client side extensions are
being implemented as python files that inherit from a base class
gp_ext(). There is no way to register/unregister client side extensions
(currently they are statically imported, requiring a code change to
add/remove).
We don't have user policy code yet (although I have some wip code).
There is a cache setup of previous settings, intended to prevent policy
tattooing, although this cache needs some work.

I have some WIP patches that allow us to easily add/remove client side
extensions, but it doesn't follow the way MS does it in windows. My
patches enable/disable extensions based on their presence in a specific
directory.
I suggest we designate a directory where client side extensions should
reside, and enable them individually by name via a list, maybe stored as
a smb.conf param, with a set of default extensions? We could use the ±
smb.conf syntax for adding or removing from the list of default extensions.
I also think the samba_gpoupdate command should mimic MS gpupdate (and
maybe be renamed), similar to how the net command mimics the windows net
command.

Thoughts, comments?

-- 
David Mulder
SUSE Labs Software Engineer - Samba
dmulder at suse.com
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)





More information about the samba-technical mailing list