>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/
