Re: [ActiveDir] Strange password issue

Mon, 11 Sep 2006 08:32:58 -0700

The only way that I'm aware of where you can have different lengths (without your own filters, etc.) is if you deny the domain controllers from reading the necessary attributes on the NC head.  By doing this, and then having multiple policies, I believe you can achieve what you are talking about.  I've not tested this - I'm basing this on a conversation I had with someone who has tested this (Mr. Wells) -although we had had a lot to drink at the time, and I might have got things muddled up (very possible).
 
Under those circumstances, I assume the values defined in the GPO work.  It seems to be that the DCs favour the values on the NC head.  The values on the NC head are written by the PDCe -that reads the domain polcies and applies the values to the domain.
 
I haven't got round to getting my source access sorted yet, so can't verify.  Hopefully someone with access to the code can chip in here.
 
I'm not disputing what you're saying re. blocking.  That will probably stop the PDCe applying this.  However, I don't think the other DCs process this in the same way.  Unless there's a fall back, and you're achieving that via specific filtering, e.g. DC computer objects or custom groups, i.e. some DCs getting one, and others getting another...
 
Interesting.  I'll have to try and repro (which is going to take some time with the current work load).
 
 
--Paul
----- Original Message -----
Sent: Monday, September 11, 2006 3:02 PM
Subject: Re: [ActiveDir] Strange password issue

 
My understanding was that the Password Policies are applied similarly to any other Group Policy. I do recall doing some testing some time ago where by using various security filtering on Group Policies I was able to set up two DC's with two different effective policies and so two different values for Password length.
 
The thing to remember is that domain password changes etc are processed by a domain controller. You therefore need to check whether the Password policy is being applied to all of the domain controllers. As Larry said, if there is blocking on the OU for Domain Controllers and the Default Domain Policy does not have "No Override" then the DC will not get the policy. Similarly, it is possible that security filtering has been applied to the Default Domain Policy that stops it from getting applied etc. However these things would be "permanent" so you would still have a DC with the Policy not applied.
 
However, my guess is that something was wrong a month ago on a Domain Controller which processed the Password reset. It is possible that it is still a problem (i.e. if blocking was the culprit), but it is more likely to have cleared up. Is it possible that there was a DC added briefly at the time that was not processing Policies for some reason?
 
Is it feasible to check all of the event logs on all DC's at the time the password was created? It may show Group Policy Processing errors at the time.
 
Sent: Monday, September 11, 2006 7:06 PM
Subject: Re: [ActiveDir] Strange password issue

Have you actually seen this behaviour?  As it was my understanding that this particular policy is processed by SCE outside of normal policy application (by the PDCe - I can't remember how often, 60 minutes comes to mind but I don't know why).  I've tried to document this here:
 
 
--Paul
----- Original Message -----
Sent: Sunday, September 10, 2006 3:19 AM
Subject: RE: [ActiveDir] Strange password issue

If the Domain Controllers OU is set to block GPO inheritance, and the domain GPO that sets the password policy isn't set for No Override, then the domain policies might not get set properly.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of [EMAIL PROTECTED]
Sent: Friday, September 08, 2006 1:16 AM
To: [email protected]
Subject: RE: [ActiveDir] Strange password issue

err, actually the password policy is stored in the machine portion of the GPO and thus applies to all machines and therefore all local user objects too.
 
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laura A. Robinson
Sent: 06 September 2006 17:27
To: [email protected]
Subject: RE: [ActiveDir] Strange password issue

Impossible/irrelevant. If it's a domain account, the policy applies regardless, because the account is stored in AD. If it's a local account, then the policy doesn't apply regardless; domain account policies don't apply to local accounts. Is this a local account or a domain account?
 
Laura

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern
Sent: Wednesday, September 06, 2006 11:44 AM
To: [email protected]
Subject: Re: [ActiveDir] Strange password issue

If you mean before the policy was set up, then, no.
This policy has been in effect for a couple of years and the account was created a month ago..
 
Maybe the PC is not getting the Default Domain Policy?
 


 
On 9/6/06, Williams, Robert <[EMAIL PROTECTED]> wrote:

Tom,

 

This is just a stab in the dark but is it possible that this user's password was set prior to the Default Domain Policy being in effect?

Robert Williams

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: Wednesday, September 06, 2006 9:39 AM
To: activedirectory
Subject: [ActiveDir] Strange password issue

 

I'm having this weird  issue where I have a user account who is able to log in with a blank password.

The Default Domain Policy is set to a min password length of 6 characters.

The userAccountControl on the user is set to 512.

 

The Domain is at win2k3 DFL and FFL.

 

Is there any other way besides a migration tool like Quest that could circumvent this policy and allow blank passwords?

 

Thanks

2006-09-06, 11:32:05
The information contained in this e-mail message and any attachments may be privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to this e-mail and delete the message and any attachments from your computer.
 

PLEASE READ: The information contained in this email is confidential and
intended for the named recipient(s) only. If you are not an intended
recipient of this email please notify the sender immediately and delete your
copy from your system. You must not copy, distribute or take any further
action in reliance on it. Email is not a secure method of communication and
Nomura International plc ('NIplc') will not, to the extent permitted by law,
accept responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence of any virus, worm or similar malicious or disabling
code in, this message or any attachment(s) to it. If verification of this
email is sought then please request a hard copy. Unless otherwise stated
this email: (1) is not, and should not be treated or relied upon as,
investment research; (2) contains views or opinions that are solely those of
the author and do not necessarily represent those of NIplc; (3) is intended
for informational purposes only and is not a recommendation, solicitation or
offer to buy or sell securities or related financial instruments. NIplc
does not provide investment services to private customers. Authorised and
regulated by the Financial Services Authority. Registered in England
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A member of the Nomura group of companies.

Reply via email to