On Mon, Aug 3, 2009 at 8:24 PM, Richard Stovall <[email protected]> wrote:
> On a theoretical level, how could Ben's request work? If Group Policy
> is AD-based, then you're stuck with the SDOU part unless I'm missing
> something.
Well, for domain-based user accounts, one could posit an attribute
for user objects which specifies a GUID for the GPO. Keep the files
for these hypothetical per-user GPOs in the same SYSVOL folder
structure that we have now. Then modify USERENV.DLL to look for that
attribute and process the GPO if it exists. You'd need something in
ADUC to launch GPEDIT.MSC against that GPO. Tweak the RSOP/GPRESULT
stuff to know about this per-user GPO. Maybe other stuff, too.
Windows is a complicated beast. But as changes go, I think this would
be comparatively minor.
Conventional SDOU GPOs work much the same way: An AD attribute
specifying a GUID, a folder with that GUID for a name in a standard
location, and files in that folder. You can see yours by
copy-and-pasting the following into a shell "Run" box:
\\%UserDnsDomain%\SYSVOL\%UserDnsDomain%\policies\
The local-machine GPO (if it exists) is just another GPO folder:
%SystemRoot%\system32\GroupPolicy\
The idea that GPOs are stored entirely in Active Directory is a
fiction maintained by the management tools for human convenience. :)
I wasn't thinking about stand-alone workstations (no domain
membership), but I suppose there could be some local directory
structure under %SystemRoot% somewhere, to contain GPOs for each user,
either with a field in the registry SAM, or SID and file existence as
above. I doubt Microsoft would want to do this, though. It would
enable running a managed Windows network without a genuine Microsoft
Windows Server.
But if I'm already running AD, then there's no Microsoft leverage
downside I can think of.
-- Ben
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
