There’s a counter argument that says that if you are going to have policies you’re better off applying them as part of a domain policy that has its own security and change control process rather than by scripting/individual file change; which could be more open to abuse and/or misconfiguration
From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf Of Stefan Timmermans
Sent: 04 February 2009 10:59
To: thin@freelists.org
Subject: [THIN] FW: GPO Debate
Greg
As indeed some have suggested earlier on, if your system had already booted, the netlogon kicks in and
the computer policy was already applied. Of course users that log on after the system gets disconnected or
alternatively if the system gets disconnected from its dc’s , users will be unable to logon to the domain.
Only local logons will be processed.
If however the system restarts after its disconnected from its dc’s, then even the domain computerpolicy or any policy
you made that applies to you computers won’t get applied.
Regards,
Stefan
From: Stefan Timmermans [mailto:stefan.timmermans@gmail.com]
Sent: zondag 1 februari 2009 22:02
To: 'thin@freelists.org'
Subject: RE: [THIN] GPO Debate
Greg,
If the computer is unplugged from the network, then the system can’t get attacked via the network does it ?
So then the only weak spot is to log on locally , and having physical access to the system. Which brings us
to securing physical access to the system/serverroom/datacenter.
Remember the GPO’s are basically registry hacks that travel the network from your site DC to your member server
Or PC.
Actually the GPO’s are stored on the PDC (yes one of the single master roles in a ‘multimaster’ directory service) on one
Hand on the filesystem, actually the \sysvol\sysvol\GUID of GPO
and the directory service itself.
You may of course set local policies to the nodes itself, these of course will get overridden by GPO’s applied
To the OU or domain (according to the LSDOU principle) .
However you could still set a local password policy to all your servers. I would recommend
to apply the exact same settings as you apply at the Default Domain Policy.
Actually I work for Big blue and that’s what we do. Securing all systems with local security policies (in addition).
The most noteable security settings are locking down filessystem, registry , system services, userright assignments and
Account/Password policies.
Once you’ve created you local policies via a template , you can easily import them using secedit …
If you need the exact syntax for importing an *.inf template secedit…. Just give me a ring, but
I leave it up to your creative spirit.
With the help of psexec,(Ex-Sysinternals) and using a FOR/DO filelist of all you members you could even execute it from
A central location on all you systems from the prompt..
Regards,
Stefan
From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf Of Greg Reese
Sent: zondag 1 februari 2009 21:02
To: Thin
Subject: [THIN] GPO Debate
I admit that as I have been in this career for over 15 years, there may be some things that I still don't understand, or worse, some things that I don't understand as well as I think i do. But keeping an open mind and being willing to learn something from everyone I meet has served me pretty well.
currently, I am having a debate over GPO use with a colleague (for those of you in government work, think "IA asshole").
anyway, the debate is that setting a GPO at the domain or OU level does not properly protect a server because as soon as the the server is unplugged from the network, the settings disappear leaving the server in an unprotected state. So this person nwants us to make all adjustments by hand with local policies. As much as my gut tells me this is wrong, I really don't have anything to back it up with.
I say the settings will stay applied in the absence of the rest of the domain structure or servers being present. But the more I thnk about it, I really don't know how it really works. I am going to setup a test next week but figured it was worth throwing out to all of you.
Thanks!
Greg
No comments:
Post a Comment