Re: AD password chnange anomolie

From: Jims (biz_at_neocasa.net)
Date: 05/10/05 

Date: Tue, 10 May 2005 14:37:10 -0400

I've verified that the "Contact PDC on logon failure" GP is "Not Configured"
for both domains. I've also determined that the policy does not exist
(registry software/policies/microsoft/netlogon "AvoidPdcOnWan"=n does not
exist) on a workstation I can reproduce the issue from. We may open an ms
support call. I'll keep the thread updated.
Jim

"Glenn L" <the.only(delete)@gmail dot com> wrote in message
news:uqK9f1tUFHA.3188@TK2MSFTNGP09.phx.gbl...
> This is interesting.
> I would go the route Al has suggested.
> Perform an interactive logon with the new password after you set it.
> Run a set command to determine your authenticating DC.
> Then perform an LDAP bind to the authenticating DC with your old password.
> If this is successful, then we have a real problem.
>
>
>
>
> --
> Glenn L
> CCNA, MCSE 2000/2003 + Security
>
> "Al Mulnick" <amulnick_No_SPAM@ncDOTrr.com> wrote in message
> news:uEd%23xqjUFHA.2468@TK2MSFTNGP10.phx.gbl...
>> Hard to say, but have you seen this already:
>> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/df20bd3e-9914-4a8d-bd5b-3b987c73a34d.mspx
>>
>> Contact PDC on logon failure
>> Account lockout and domain password changes rely on contacting the
>> primary domain controller (PDC) emulator urgently to update the PDC
>> emulator with the change. If Contact PDC on logon failure is disabled,
>> replication of password changes to the PDC emulator occurs non-urgently.
>>
>>
>>
>> That leads me to ask where the account is located in terms of the server
>> the ldap bind is occuring to? And if you were to specify the PDCe as the
>> bind server, would you get the same results?
>>
>>
>>
>> Al
>>
>>
>> "Jims" <biz@neocasa.net> wrote in message
>> news:OTDGtpeUFHA.4056@TK2MSFTNGP15.phx.gbl...
>>> Headline: LDAP binds to AD after user password change allows for old
>>> password usage up to ~30 minutes after password change!
>>>
>>> This thread started as a potential ADAM problem but the ADAM common
>>> denominator has since been ruled out. We are are a two domain forest
>>> (parent and one child) that has many apps (mostly non-MS e.g. java,
>>> php,etc.) that authenticate users by performing simple ldap binds to AD
>>> (2003) via ADAM (but forget that detail because we've found it's not
>>> relavent). We have confirmed that users in the child AD domain are able
>>> to use their old password to bind to AD up to about ~30 minutes after
>>> changing their password AND those same users can also use their new
>>> password to bind to AD during that same ~30 period. This behavior is
>>> consistently reproduceable in the child domain but not reproduceable in
>>> the parent (forest root) domain where the old password is immediately
>>> rejected as expected. Both domains have the same domain password group
>>> policies. This behavior is not witnessed on workstation (interactive)
>>> logins - e.g.after password change you cannot log into a workstation
>>> with the old password - your get a bad username or password message.
>>> Seems to be LDAP protocol only. We don't think this is a SAM
>>> replication issue because the new passoword works fine and this should
>>> not be the case if the SAM db was replicating promptly between DCs.
>>> Any ideas appreciated?
>>> Jim Shattuck
>>>
>>>
>>> -------From
>>> Dimitri-------------------------------------------------------------------------------------------------------------------
>>> Curious. So, the same applies to direct binds to AD as well? But not for
>>> interactive binds?
>>>
>>> If so, I suggest you start another thread here with a different subject.
>>> Perhaps our AD MVPs will be able to shed some light on that.
>>>
>>> --
>>> Dmitri Gavrilov
>>> SDE, Active Directory Core
>>>
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>> Use of included script samples are subject to the terms specified at
>>> http://www.microsoft.com/info/cpyright.htm
>>>
>>> "Jims" <biz@neocasa.net> wrote in message
>>> news:ecCTmnbUFHA.928@TK2MSFTNGP15.phx.gbl...
>>>> Pure LDAP for 2 out of 3 apps we've tested (PeoplseSoft web on Solaris
>>>> and
>>>> Softerra LDAP Administrator) and one in-house ADSI app.
>>>> Jim
>>>>
>>>>
>>>> "Dmitri Gavrilov [MSFT]" <dmitrig@online.microsoft.com> wrote in
>>>> message
>>>> news:%231zBGVbUFHA.3544@TK2MSFTNGP12.phx.gbl...
>>>>> Pure LDAP or ADSI?
>>>>>
>>>>> --
>>>>> Dmitri Gavrilov
>>>>> SDE, Active Directory Core
>>>>>
>>>>> This posting is provided "AS IS" with no warranties, and confers no
>>>>> rights.
>>>>> Use of included script samples are subject to the terms specified at
>>>>> http://www.microsoft.com/info/cpyright.htm
>>>>>
>>>>> "Jims" <biz@neocasa.net> wrote in message
>>>>> news:%23LtfSTbUFHA.3056@TK2MSFTNGP14.phx.gbl...
>>>>>> The issue only seems to affect ldap binds. We cannot reproduce this
>>>>>> behavior when logging onto a workstation - only accepts the new
>>>>>> password. AD replication appears to be ok but I will investigate
>>>>>> further.
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>> "Dmitri Gavrilov [MSFT]" <dmitrig@online.microsoft.com> wrote in
>>>>>> message
>>>>>> news:%23kcBnDbUFHA.1508@tk2msftngp13.phx.gbl...
>>>>>>> Are you using LDAP or ADSI?
>>>>>>> Does interactive logon with old pwd still work, when the workstation
>>>>>>> is
>>>>>>> connected to the network?
>>>>>>> Is AD replication ok?
>>>>>>>
>>>>>>> --
>>>>>>> Dmitri Gavrilov
>>>>>>> SDE, Active Directory Core
>>>>>>>
>>>>>>> This posting is provided "AS IS" with no warranties, and confers no
>>>>>>> rights.
>>>>>>> Use of included script samples are subject to the terms specified at
>>>>>>> http://www.microsoft.com/info/cpyright.htm
>>>>>>>
>>>>>>> "Jims" <biz@neocasa.net> wrote in message
>>>>>>> news:%23SbIveaUFHA.580@TK2MSFTNGP15.phx.gbl...
>>>>>>>> Thanks for the response. After some additional testing we've found
>>>>>>>> this is definitely happening but appears to be an AD issue and not
>>>>>>>> ADAM. We also found it only happens to users of a particular child
>>>>>>>> domain in our forest and not users in the parent domain. Out
>>>>>>>> Tests: a
>>>>>>>> user in the child domain changed their AD password in the child
>>>>>>>> domain
>>>>>>>> and then performed several successful ldap binds to a dc in the
>>>>>>>> child
>>>>>>>> domain with their old and new passwords. The old password worked
>>>>>>>> for
>>>>>>>> up to ~30 minutes. The same test was performed with a user in the
>>>>>>>> parent (root) domain and the old password bind failed immediately.
>>>>>>>> Both tests were performed several times and the results were
>>>>>>>> consistent. Security group policy settings in both domains appear
>>>>>>>> to
>>>>>>>> be the same. It doesn't seem to be SAM replication because the new
>>>>>>>> password was also successful. We're stumped.
>>>>>>>>
>>>>>>>>
>>>>>>>> "Lee Flight" <lef@le.ac.uk-nospam> wrote in message
>>>>>>>> news:O0WmTRXUFHA.2472@TK2MSFTNGP10.phx.gbl...
>>>>>>>>> Hi Jim,
>>>>>>>>>
>>>>>>>>> "Jims" <biz@neocasa.net> wrote in message
>>>>>>>>> news:OD80caPUFHA.1432@TK2MSFTNGP09.phx.gbl...
>>>>>>>>>
>>>>>>>>>> Issue: We've been receiving reports from our users that after
>>>>>>>>>> resetting their AD domain passwords, they can still log into
>>>>>>>>>> applications (those that bind to adam) with their old password
>>>>>>>>>> for
>>>>>>>>>> up to an hour or so. Additionally, they can also use their new
>>>>>>>>>> password.
>>>>>>>>>> ??? - Is this possible or do my users hate me? I've seen this
>>>>>>>>>> behavior on an XP workstation after a password reset but never
>>>>>>>>>> with
>>>>>>>>>> adam. Any ideas appreciated.
>>>>>>>>>> Thanks,
>>>>>>>>>> Jim
>>>>>>>>>
>>>>>>>>> I have never seen that behavior but then I do not have your web
>>>>>>>>> application :)
>>>>>>>>> Have you manged to repro the problem with test account and keeping
>>>>>>>>> one eye
>>>>>>>>> on the security audit log on the ADAM instance and back-end DC? If
>>>>>>>>> you
>>>>>>>>> can repro it might be worth trying with a native ADAM user through
>>>>>>>>> the
>>>>>>>>> web application, if possible, and then resetting the password for
>>>>>>>>> that account
>>>>>>>>> to see if that also exhibits the behavior.
>>>>>>>>>
>>>>>>>>> I would not be surprised if this was being seen as I could well
>>>>>>>>> imagine that
>>>>>>>>> the application might maintain some sort of credential caching (is
>>>>>>>>> the web
>>>>>>>>> application using ADSI? Is it running under IIS?).
>>>>>>>>>
>>>>>>>>> Let us know what you find, thanks
>>>>>>>>>
>>>>>>>>> Lee Flight
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Relevant Pages

  • Prob w/ win 2K Networking
    ... Logon failure: The user has not been granted the requested ... Also, the PDC is unable to manage his computer, and cannot ... Microsoft Knowledge base article 249918 mentions this ... does not log into other networks, he does use a "Net Use" ...
    (microsoft.public.win2000.security)
  • Re: Replication of password resets/unlocks
    ... Contact PDC on Logon Failure ... our Windows 2003 AD structure has been configured to replicate between ... clientcomputer tries to contact the pdc emulator. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Contact PDC on Logon Failure
    ... the password change to the PDC and the check are enabled by default ... I'm having a problem where as my branch users will change their password and ... I understand there is a setting "Contact PDC on Logon Failure" which can be ... We are running a Windows 2003 Environment. ...
    (microsoft.public.windows.server.active_directory)