I'm just guessing but they probably fixed it this way because they probably do have other methods that do authentication in "different" ways and forcing this immediate replication took the least amount of "touching" of a very key area of Windows while "correcting" (actually make consistent) all of the different methods that would be used for authentication.
I agree that there should be one channel for the authentication though. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Monday, November 24, 2003 7:48 AM To: '[EMAIL PROTECTED]' >From reading your description, which sounds right, I wonder if the >issue wasn't even more simple than you describe. Seems to me that there should be one authentication process for any authentication event. It sounds like there are at least two. I'm guessing there is an underlying provider that does domain authentication including PDC chaining and returns a set of values concerning its success or failure, as well as ancillary items such as forced password changed, etc. I have a hard time understanding why the password change process doesn't call that same provider to validate the "old" password - why did someone reinvent the wheel there? Roger -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -----Original Message----- > From: Joe [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 22, 2003 11:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] q812499 > > > 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/ > 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/
