• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 715
  • Last Modified:

default domain policy failed warning

our outsourced monitoring service sent us an alert stating that it has "discovered problems with the Default Domain Policy. This policy contain Password Policy, Account Lockout Policy and Kerberos Policy settings.Users will not get home folders and logon scripts will not work properly.And they may face permissions issue while accessing domain resources."

Earlier today we changed the password policy through GPO on our PDC to enforce changes every 60 days, with 7 days between changes, and 4 passwords remembered. 30 minutes later, we received this alert. I see nothing in the event viewer on that PDC. Some users have already been prompted to change their password. Some have not. No one has reported not being able to logon or access shares. I am able to get to and open the netlogon and sysvol shares from my desktop. Ran set logonserver and it showed the PDC in question. What else should I check top ensure the GPO is OK?

Any ideas to the meaning of this, and more specifically - do I need to worry about it, are greatly appreciated.
0
rpliner
Asked:
rpliner
  • 5
  • 4
  • 4
2 Solutions
 
merkageCommented:
Very common problem you have here. Default domain policy should NEVER be touched. NOTHING should be configured in this policy. It is the top level policy that defines your organization, and if it becomes corrupt you can lose your entire AD database, so I suggest removing all configured policies and then making a new one with the settings you have applied in the default.

I can tell you from past experience it is an absolute nightmare when a DDGPO gets corrupt.

0
 
rplinerAuthor Commented:
merkage - I printed out an html report from group policy just so I had it in case anything went awry. The company that managed the network before I was brought on has a lot of things configured in the default policy. I need to figure out how to back it up and then create a new one without disrupting business or worse. Is there any way to "roll it back" so-to-speak? Thanks.


0
 
Rant32Commented:
merkage: that is not correct. Password policies should always be defined in the Default Domain Policy.

Source: http://support.microsoft.com/kb/269236
Source: http://technet.microsoft.com/en-us/library/dd378987%28WS.10%29.aspx

For all other computer and user settings, yes, you should create a new policy.

rpliner, I can't tell from here if this warning/error is going to give more problems.

If you want to be sure, I'd first inventory the settings in the Default Domain Policy. Any settings other than Security settings (Administrative Templates and such) must be transferred to a new GPO. If there are only security settings, then:
1) record the settings in the Default Domain Policy and Default DC Policy
2) restore the default domain policy with the help of DcGpoFix:
 http://www.windowsitpro.com/article/tips/jsi-tip-6493-window-server-2003-default-group-policy-restore-utility-v5-1-.aspx
3) re-create the security settings in the Default Domain Policy.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
merkageCommented:
Well, a roll back would only be possible if you had a backup system in place. The easiest thing you can do is use Microsoft GPO editor, take a screen shot or 3 of the configuration within the policy, then start making your new policies but keep them disable for now. When you are ready to go live, you'll want to go into your default policy, change everything back to not configured, and then enable the new policies you created. In general, you'll want to have a 'security' policy that defines Password Policy, Account Lockout Policy and Kerberos Policy settings. you'll then want to create other policies for any other configurations made within your existing default domain policy.
0
 
rplinerAuthor Commented:
rant32 - I will check that tool out. Can't hurt to run it. Worst case is I still get a warning. Thanks.
0
 
Rant32Commented:
Do you have an Event ID, source and error codes of the relevant messages in your Event Viewer?
0
 
rplinerAuthor Commented:
rant32 - nothing shows up in the event viewer.
0
 
Rant32Commented:
Then that makes you wonder what generated the ticket? Do that monitoring service check for specific options in the password policy, so they generate a warning if the policy changes?

Modifying the default domain GPO is not wise in case you have to restore it to defaults, and in case someone badly screws up the settings, but changing the password policy is normally not "omg-epic outage" bad like the alert pretends it is.
0
 
merkageCommented:
Rant32 - I still keep all mine separate. I had a default domain GPO become corrupt once, and it was hell getting it back. Microsoft was involved and actually had me configure it in that way to avoid ever having to worry about corruption again (ie, we would never touch/modify the default again). you always run the risk of corruption when your modifying, so the less you can do to the policy, the better off you are. this was done by a Microsoft engineer that assist us with the 2 day long recovery process.


0
 
Rant32Commented:
Yes, it can work for you if the Link order is set correctly and if you have no downlevel clients.

From http://technet.microsoft.com/en-us/library/cc772803%28WS.10%29.aspx:

You can make changes to Group Policy by modifying the default GPO or by creating a new GPO. The recommendation for making changes to domain security policy is to always modify the default GPO. The primary reason for this recommendation is that APIs that were developed for earlier versions of the operating system update policy settings in the Default Domain Policy GPO. For this reason, make all changes to domain security policy settings by editing this GPO.

Note that it says 'primary reason'. That suggests that there are others involved, I don't know which.
I'm trying to educate on the factors involved, not prove your methods wrong. However, the statement to never touch the Default Domain policy is just not true as generic advice.
0
 
merkageCommented:
Thank you for that explanation, I won't argue with that coming directly from Microsoft. I did want to offer my experience up though :)

0
 
Rant32Commented:
Yes, I saw that. Welcome to EE :)
0
 
rplinerAuthor Commented:
rant32 -the alert has gone away. I will still investigate the DCGPOfix tool though. Thanks for your assistance.

merkage - thanks for sharing your experience.




0

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 5
  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now