Problems with ineffective Password Expiration Policy
Bowulf
I initially modified the Default Domain Security Policy with the
updated password settings, but after 2 days of being ineffective on
domain accounts, I created a second GPO assigned it at the domain
level. I validated the GPO using the gpotool command, and ensured the
new "Domain Password Policy" was the same version on all domain
controllers. The policy is effective on workstation and member
servers as validated by checking the Local Security Policy and "net
accounts" command.
On domain controllers, it has not changed the net accounts setting
from Unlimited. I can manually set the net accounts using /maxpwage,
and that command is effective in expiring passwords. I have run
gpupdate /force on all domain controllers, validated FRS, and ran
gpresult /v to see what policies are being applied. Here are the
redacted results of that command:
Applied Group Policy Objects
-----------------------------
Domain Password Policy
Default Domain Controllers Policy
Default Domain Policy
AutoEnrollment
The following GPOs were not applied because they were filtered out
-------------------------------------------------------------------
Local Group Policy
Filtering: Not Applied (Empty)
Account Policies
----------------
GPO: Default Domain Policy
Policy: MaxServiceAge
Computer Setting: 600
GPO: Default Domain Policy
Policy: MaxTicketAge
Computer Setting: 10
GPO: Default Domain Policy
Policy: MaxClockSkew
Computer Setting: 5
GPO: Default Domain Policy
Policy: MaxRenewAge
Computer Setting: 7
As you can tell the "Domain Password Policy" is being applied, but
none of the account policies are being set. I have already attempted
to set the policy to "enforced" to prevent block inheritance, but that
did not change the gpresult output. Reverting back to the Default
Domain Policy was not effective either.
What could be preventing the GPO from being effective?
Harj
Hi,
The only place that the password policy can be placed for domain
accounts is in the default domain policy linked at the domain or any
other policy with the HIGHEST priority.
Verify that this new policy has the highest priority at the domain
level and verify that it first replicates and of coarse applies to the
domain controllers.
As you can see from net accounts it is still getting information from
the default domain policy
Good luck
Harj Singh
Password Policy done right
www.specopssoft.com
Rob (Microsoft)
You can run an RSOP.MSC on the DC to see if the group policy on the domain
level is applying.
If your default Domain Controllers group policy is blocking policy
inheritance, then it would never get the changes for the password policy.
I hope this helps,
Bowulf
> Hi,
>
> The only place that the password policy can be placed for domain
> accounts is in the default domain policy linked at the domain or any
> other policy with the HIGHEST priority.
> Verify that this new policy has the highest priority at the domain
> level and verify that it first replicates and of coarse applies to the
> domain controllers.
> As you can see from net accounts it is still getting information from
> the default domain policy
>
> Good luck
>
> Harj Singh
> Password Policy done rightwww.specopssoft.com
I moved the policy to the #1 priority level, and it did not change the
account policy on the domain controller. I have validated the GPO has
replicated to all domain controllers using the gpotool command.
>>If your default Domain Controllers group policy is blocking policy inheritance, then it would never get the changes for the password policy.
Would not the "enforced" check override any block inheritance?
The rsop.msc shows the Default Domain Policy still setting those
entries even after ensuring that policy is configured with account
password policies as "not defined."
Rob (Microsoft)
Bowulf
On Jul 26, 3:02 pm, Rob (Microsoft)
Rob (Microsoft)
Darren Mar-Elia
couple things to test. First, make sure that your PDC emulator DC is
functional and available. Despite the multi master nature of DCs, account
policy is only actually set on the PDC-e DC. Next, look at the attributes on
the domain NC head using ADSIEdit. Specifically, look at the maxpwdage
attribute and see what it says. Ultimately, account policy is enforced by
the PDC emulator writing to these NC head attributes, so if these are not
getting written, the account policy will not propagate.
Darren
--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Scripting Group Policy Settings with the GPExpert Scripting Toolkit for
PowerShell!
Find out more at http://www.sdmsoftware.com/products2.php
Visit the GPOGUY: http://www.gpoguy.com -- The Windows Group Policy
Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
"Bowulf" <bow...@gmail.com> wrote in message
news:1185488626....@l70g2000hse.googlegroups.com...
Bowulf
wrote:
> I'm admittedly a little confused by what all you are doing, but here are a
> couple things to test. First, make sure that your PDC emulator DC is
> functional and available. Despite the multi master nature of DCs, account
> policy is only actually set on the PDC-e DC. Next, look at the attributes on
> the domain NC head using ADSIEdit. Specifically, look at the maxpwdage
> attribute and see what it says. Ultimately, account policy is enforced by
> the PDC emulator writing to these NC head attributes, so if these are not
> getting written, the account policy will not propagate.
>
currently running and synchronizing with other DC's from the PDC
Emulator, I have a GPO that has not updated. The Default Domain
Policy reports a version mismatch hours after a change on one of the 7
Domain Controllers. The RSOP.msc reports the Default Domain Policy
old values from 6 days.
Friendly name: Default Domain Policy
Created: 3/25/2006 8:26:43 AM
Changed: 7/26/2007 10:28:14 PM
DS version: 3(user) 113(machine)
Sysvol version: 3(user) 81(machine)
Other GPO's have replicated in the mean time and are not similarly
"stuck." I believe even though the PDC Emulator reports the correct
machine version (113 in both DS and Sysvol) of the GPO, the
disagreement is causing version 81 to stay effective. I have tried
changing the GPO and forcing a new replication without success. What
is the best way to update this other DC if FRS refuses to update it?
Rob (Microsoft)
Take a look in your FRS event logs and give me the errors that you are
getting. This hopefully shouldn't take to long to fix.
On the problem server, point TCP to your PDC emulator for DNS.
Flush\Register DNS
Open Active Directory Sites and Services
Find the problem Server
Under the problem Server-highlight NTDS Settings
On it's Automatic or Manual connection object Right click and tell it to
replicate now.
If this works, depending on the FRS errors that you have, restart the FRS
and DFS services, and see if GP will update through Replication.
If that still doesn't work, we'll look at the errors and see which is the
best way to proceed.
Bowulf
SONAR FRS utility and replmon show current on replication after the
Replicate Now. A dummy txt file in Sysvol directory was created and
successfully replicated between the two servers during the test.
There are no errors in the FRS event log of any of the domain
controllers (including the PDC-E and problem child). The SONAR
utility shows no error conditions.
I checked the version of the gpt.ini in the problem DC, and it still
reported the old version.
On Jul 27, 6:28 am, Rob (Microsoft)
Bowulf
<FrsOpenSourceFile2W: 7148: 1580: S0: 09:51:25>
NtCreateFile failed : NTStatus: STATUS_SHARING_VIOLATION
<FrsOpenSourceFile2W: 7148: 1591: S0: 09:51:25> ++
CreateFile failed on file \??\D:\SYSVOL\domain\Policies
\{31B2F340-016D-11D2-945F-00C04FB984F9}\GPT.INI; WStatus:
ERROR_SHARING_VIOLATION
<StuOpenDestinationFile: 7148: 1161: S0: 09:51:25> ++ ERROR -
FrsOpenSourceFile2W(GPT.INI -> WStatus: ERROR_SHARING_VIOLATION
<StuOpenDestinationFile: 7148: 1201: S0: 09:51:25> :: CoG
b374cd13, CxtG 99fbb0f6, FV 5, FID 00020000 000002d8, FN:
GPT.INI , [FrsOpenSourceFile2W failed.]
<StuExecuteInstall: 7148: 2630: S1: 09:51:25> WARN -
StuOpenDestinationFile failed. WStatus: ERROR_SHARING_VIOLATION
Darren Mar-Elia
do you? Also, check out this article :
http://support.microsoft.com/kb/822300/en-us
But frankly I don't think this is the cause of your account policy issues.
Did you check the value on the Domain NC head for maxpwdage?
Darren
--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Scripting Group Policy Settings with the GPExpert Scripting Toolkit for
PowerShell!
Find out more at http://www.sdmsoftware.com/products2.php
Visit the GPOGUY: http://www.gpoguy.com -- The Windows Group Policy
Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
"Bowulf" <bow...@gmail.com> wrote in message
news:1185549634.3...@i13g2000prf.googlegroups.com...
Rob (Microsoft)
Bowulf
flag on the Sysvol container. Now all domain controllers are
reporting consistent versions of the GPO. (v113)
I re-ran RSOP for the password policy on the PDC-E, and it still
showing the old values for the Default Domain Policy. If I run RSOP
on the problem controller in the same site, it reports no GPO as being
defined. I checked two other domain controllers, and they reported no
GPO as being defined. I ran RSOP against a member server and a
workstation, and it shows the correct values for the Default Domain
Policy. I checked again for any Block Inheritance on the Domain
Controllers OU, and there was none. It still appears as if there GPO
weirdness happening with the PDC-Emulator.
Thank you for your help.
Kent
Bowulf
(after calculation) that I set using the "net accounts /maxpwage"
command.
I have stopped the AV scanning the Sysvol container. Clients were
consistently connected to the gpt.ini. Is there a negative to
InstallOverride frsflag for a Sysvol container?
On Jul 27, 10:58 am, "Darren Mar-Elia" <dmanonym...@microsoft.com>
wrote:
> You don't have anti-virus running against these SYSVOL folders on your DCs,
> do you? Also, check out this article :http://support.microsoft.com/kb/822300/en-us
>
> But frankly I don't think this is the cause of your account policy issues.
> Did you check the value on the Domain NC head for maxpwdage?
>
> Darren
>
> --
> Darren Mar-Elia
> MS-MVP-Windows Server--Group Policy
>
> Scripting Group Policy Settings with the GPExpert Scripting Toolkit for
> PowerShell!
> Find out more athttp://www.sdmsoftware.com/products2.php
>
> Visit the GPOGUY:http://www.gpoguy.com-- The Windows Group Policy
Darren Mar-Elia
Try this. Just go into the Default Domain Policy (assuming it is "winning
GPO" at the domain level for account policy) and try modifying the account
policy settings again. You don't have to necessarily change them. Just make
change and then commit it and then change it back. See if that helps.
Darren
--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Scripting Group Policy Settings with the GPExpert Scripting Toolkit for
PowerShell!
Find out more at http://www.sdmsoftware.com/products2.php
Visit the GPOGUY: http://www.gpoguy.com -- The Windows Group Policy
Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
"Bowulf" <bow...@gmail.com> wrote in message
news:1185552905.9...@j4g2000prf.googlegroups.com...
Bowulf
support. The problem ended up being security permissions on the HKLM
\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions key
on the PDC Emulator. The permissions were not set to inheritable
(have no idea when or how this changed), and therefore the client side
GPO extensions were not present. I added Authenticated users (Read),
System, and Administrators with permissions to key, and it populated
the extensions like it should.
Thanks for your help.
On Jul 27, 11:27 am, "Darren Mar-Elia" <dmanonym...@microsoft.com>
wrote: