Default Dom Policy vs Custom Dom Policy - thoughts?

Bob_the_Goon

Just wondering what server admins do in the real world r.e. default domain policies? Do you configure the out of the box "Default dom policy" or do you make your own GPO and apply it to the domain? Any pros and cons for either way?

Essendon

IMO, you shouldnt mess with the Default Domain Policy. The settings you configure here are applied en masse, including domain controllers, unless you have other settings in other GPos that override them.

I wanted to write more, but have an exam tomorrow >>

Bob_the_Goon

But if you linked the custom dom GPO to the domain itself e.g. contoso.com, wouldn't this apply these settings to the DCs anyway?

Essendon

Yeah it would. Why I prefer a custom Domain GPO is that if you mess up then atleast you have your Default Domain Policy in pristine condition. So have it at the top of the order of GPOs linked to the OU.

I have this good article bookmarked. Best Practices for Designing Group Policy

dynamik

It also makes things a bit easier to manage if you create GPOs for one, or a small group of related settings, instead of just configuring everything in a single policy. It's pretty obvious to tell what "Software Restriction Policies" is, as opposed to having to sort through a single GPO and figure out everything that's set there.

Bob_the_Goon

Cool. Sometimes you're just unsure of what's the best way of doing things in the real world. Thanks for the link.

HeroPsycho

Some settings however cannot be applied unless they're in the default domain policy. Password policies are an example.

RTmarc

HeroPsycho wrote: »

Some settings however cannot be applied unless they're in the default domain policy. Password policies are an example.

Password policies can be applied using other policies as long as they at the domain root. I've done it.

HeroPsycho

RTmarc wrote: »

Password policies can be applied using other policies as long as they at the domain root. I've done it.

To accommodate APIs from previous versions of the operating system that make changes directly to default GPOs, changes to the following security policy settings must be made directly in the Default Domain Policy GPO or in the Default Domain Controllers Policy GPO:

• Default Domain Security Policy Settings:
  
  
  • Password Policy
  • Domain Account Lockout Policy
  • Domain Kerberos Policy
• Default Domain Controller Security Policy Settings:
  
  
  • User Rights Assignment Policy
  • Audit Policy

Applying Selected Domain and Domain Controller Policy Settings

Hyper-Me

Password policy is the only thing ive ever changed in the DDP.

Its just a good idea to leave it alone except for the instances that psycho posted.

royal

HeroPsycho wrote: »

Some settings however cannot be applied unless they're in the default domain policy. Password policies are an example.

Not entirely true although I know what you are saying.

Password policies can be applied anywhere. Domain user accounts will only apply password policies at the root. Domain joined machines will still apply password policies located anywhere but they will only apply to local user accounts.

HeroPsycho

royal wrote: »

Not entirely true although I know what you are saying.

Password policies can be applied anywhere. Domain user accounts will only apply password policies at the root. Domain joined machines will still apply password policies located anywhere but they will only apply to local user accounts.

I know what you're saying, but technically, domain users can get password policies other than from the root with fine grained password policies feature in Windows 2008.

BYAAAAAAAAAAH!

blargoe

RTmarc wrote: »

Password policies can be applied using other policies as long as they at the domain root. I've done it.

You "can"... And things can get messed up doing it there too... eventually. I've done it.

RTmarc

blargoe wrote: »

You "can"... And things can get messed up doing it there too... eventually. I've done it.

You're right. It is certainly not a best practice but it can be done.

HeroPsycho

RTmarc wrote: »

You're right. It is certainly not a best practice but it can be done.

But you shouldn't do it.