It confirms that we live on a thing that we think solid earth taht in really it is not.
I think that the solution immediately ready is have what you have (the bug not the supposed project feature ) simply because there are not alternatives.
In my experience I known a real solution used in NT in a leader italian bank that can solves this problem, but it is a long a complex process because re-invent the securiy access by a strong customized logon way.
Stefano
From: "Joe" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
Subject: RE: [ActiveDir] q812499
Date: Sat, 22 Nov 2003 11:22:53 -0500
MIME-Version: 1.0
Received: from mail.activedir.org ([64.245.160.7]) by mc8-f18.hotmail.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 22 Nov 2003 08:23:44 -0800
Received: from grenada.globat.com [203.22.204.108] by mail.activedir.org with ESMTP (SMTPD32-8.04) id AD7DAB010C; Sat, 22 Nov 2003 11:23:25 -0500
Received: from cayman.globat.com (cayman.globat.com [203.22.204.96])by grenada.globat.com (8.12.6p3/8.12.6) with SMTP id hAMGNAPO007703for <[EMAIL PROTECTED]>; Sat, 22 Nov 2003 08:23:10 -0800 (PST)(envelope-from [EMAIL PROTECTED])
Received: (qmail 25201 invoked from network); 22 Nov 2003 16:23:24 -0000
Received: from d14-69-29-13.try.wideopenwest.com (HELO mainpro) (69.14.13.29) by cayman.globat.com with SMTP; 22 Nov 2003 16:23:24 -0000
X-Message-Info: yilqo4+6kc6XK4gKM9hXEV8yuQsuq29p
Message-Id: <[EMAIL PROTECTED]>
X-Mailer: Microsoft Outlook, Build 11.0.4920
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[EMAIL PROTECTED]>
Thread-Index: AcOvfSE+mbE4BWE0Q4mSqXgvn3KidQBlCGqw
Precedence: bulk
Sender: [EMAIL PROTECTED]
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 22 Nov 2003 16:23:44.0602 (UTC) FILETIME=[FFD383A0:01C3B114]
I will speak to this one as I was one of the primary instigators kicking MS to fix it. If I didn't have a large company behind me I don't think I could have pulled it off...
Basically when you change the password centrally and someone at a remote
site wants to log in the users password is authenticated at the local site.
If the password isn't correct, the DC will go through an operation called
PDC Chaining. This means it will forward the request to the PDC and ask if
the password is correct. If the password is correct at the PDC, the PDC will
send an ok response back the DC will allow the user to log on...
Now lets say the password was also set to have to be changed immediately...
That information is sent back as well so you get logged on and THEN the
workstation is told to prompt you to change your password. You have the old
password which worked autofilled into the old password box, you simply need
to enter a new valid password two times and hit ok and you should be on your
way... Wrong... The changepassword routine on the local DC will see the old
password and even though it just chained it to the PDC and was told it was
good, it will only check its local database and consider itself
authoritative so since the replication hasn't occurred yet, your change
password request is denied.
What that fix does is force an immediate out of band replication of some of the users information down to the authenticating domain controller so that that DC won't have any issues around the new password.
If you clear that registry entry, you disable this functionality and Windows
acts like it did prior to the hot fix.
Now for supposition on my part as to why this does that because one of the
questions asked a lot around here and one of the reasons I like this list so
much is WHY? Why did it work that way before, all DC's are equal right? PDC
chaining is a known thing and has worked for a long time even in NT4 right?
Consider this, in NT4 days you had one machine that could master changes
(the PDC) and all the rest could only get read only copies of data from the
PDC (well for most things there were exceptions such as bad password count,
last logon, etc). Also keep in mind that in NT4 you didn't have to load any
special software on a PDC, you just told the domain which machine was the
PDC and voila, it all worked. This means that every machine had the
necessary software to be a PDC.
Now you can implement that in two ways... You can have a special PDC Service
that spins up on the PDC machine or you can have some basic checks in the
main code that says, hey if you aren't the PDC, don't allow this specific
type of change...
Obviously the second is MUCH easier to deal with and troubleshoot. MS went that way.
So now you have a piece of code that says, oh this is a password change, let
me check to see if I am the PDC? Yes, ok lets try to process it, is the old
password good? Well I am the PDC so I know I have to have the right one all
of the time and no it doesn't match, send back a failure....
Ok... You probably see where I am going... The change to the W2K code wasn't
to rewrite the password change process for machines now that a password
change could be mastered anywhere. The change was to remove the check to see
if the machine was the PDC. So now you have the case of the password change
coming in, it doesn't matter if the machine is the PDC because any DC can
take the change. However, they never modified the code to make it realize it
wasn't the authority location for the password anymore... So even though you
had gone through a PDC Chaining process previously and the password is known
good, this change password function doesn't know that happened so it does a
check of the password, assumes it has to have the correct one locally, and
then makes a decision to do it or not do it based on that information.
Bam.... I call that a bug. MS called it part of the design. I think I argued
that that wasn't the design for a couple of weeks with PSS because that
obviously wasn't the intent and they weren't specifically looking for that
functionality to work that way. Either way we finally got to a QFE guy who
felt pretty strongly that it needed to be fixed as well and he fixed it by
forcing the quick replication of the information needed. He fixed it, we got
a buddy drop to test out, our Dev guys checked it and said, cool! It became
a hot fix. Prior to that the answer from MS to anyone who complained about
it was that this was by design and if you had a problem with it, you should
change the password on the domain controller that the user will use to
authenticate. I didn't like that answer much when they gave it to me... :op
Again that is all supposition, it could be entirely wrong... But I don't think so. I haven't taken the time to dig into the code to doublecheck yet but at some point when I get some spare time I will as long as E2K doesn't kill me first... Actually I am in the same sort of debate with MS right now over how Exchange gives out GC's to the clients. Like last time I am being told up front that MS wouldn't change the functionality and I had to live with it... However there is now a lot of work going on in the background around it...
To be continued...
joe
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Thursday, November 20, 2003 10:44 AM To: [EMAIL PROTECTED]
have just read up on the fix provided by Q812499 / and also SP4
i see it enables a registry value but any further detail on what it does / how it works seems to be a little bit elusive
any one care to elaborate on what it "actually" does ?
GT
List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
