|
What we did in our environment was: -
disabled the links of DDP/DDCP to domain object and Domain
Controllers OU -
remove “Group Policy Creator Owners” from the ACL of “CN=Policies,CN=System,DC=domain,DC=com”
and added our own group with permissions to create objects in the container. -
changed the defaultSecurityDescriptor attribute of Group-Policy-Container
object, trimmed the Domain Admins to read-only and introduced a new security
group with full permissions over newly created GPOs (SDDL is an ugly thing to
work with, so if you are interested in quick and dirty SDDL parser I wrote,
grab it from here: http://www.petri.co.il/forums/download.php?id=43
). This way the GPOs are created with ACL which does not allow default groups
to change it (see http://www.jsiinc.com/SUBL/tip5500/rh5528.htm
for details) -
created new GPOs to replace DDP/DDCP (those were created with the
adjusted ACL) Guy From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Willem Kasdorp I have had similar issues before at
customer sites with apps modifying the DDP and DDCP, although none this bad.
ADMT is a notorious offender. I am seriously tempted to fix it in the
following way: -
create a new DDP/DDCP (new name of course) with highest prio. Edit
any additional settings in the new policies. -
Remove write for Domain Admins on the DDP/DDCP, and instead create
an additional group for write permissions. This group is empty by default. This story might just trigger me to do
it… -- Regards, Willem From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hello folks, I've just had a very
curious issue at a customer, which took us a while to figure out. You should
all be aware of this as it could hurt you as well. After testing
everything successfully in the lab (and ADPREPing the production forest +
domains), we've inplace-upgraded the first production DC from Win2000 to
Win2003 and it failed with errors such as a crashing LSASS and a DHCP service,
which couldn't start due to access violation etc. It turns out that this
was caused due to a lengthy list of policy settings on the
Def Domain and Def DC Policy, which configured Security (ACL) over one
hundred registry
keys and File System folders and files. The
resulting permissions were ok for Windows 2000, but incompatible
with Windows Server 2003 - e.g. the DHCP Client Service and the TCPIP Service
require specific permissions on their respective registry keys for the DHCP
service to start via the new Network Service account.
I see other's in this list have also had issues with the DCHP service,
which may be related to the same thing. Although we
now fixed the issue by cleaning the policies and un-promoting the DC and
reinstalling it from scratch (since the 2003 OS's default permissions were
effectively overwritten due to the policy), I am looking for
clues on how these weird settings were introduced to the Def Dom and
the Def DC policy in the first place? The settings were
definitely not added manually "by accident" - more likely by
some whacky setup routine. Does anybody have an ideas or
experience with respect to services/apps which could have changed the domain
policies in this way? Thanks for any
feedback, Guido |
- RE: [ActiveDir] Issues with Win 2k3 Inplace Upgrade - ... Guy Teverovsky
- RE: [ActiveDir] Issues with Win 2k3 Inplace Upgra... Grillenmeier, Guido
- RE: [ActiveDir] Issues with Win 2k3 Inplace Upgra... Fugleberg, David A
