>>It will get that password back immediately unless the PDC is really busy or otherwise unavailable The way I'm reading this is that you are saying password change will trigger immediate replication to the PDCE. Iin my experience (which I don't have to describe to you :)), this is not the case. Also, I may be misreading you here, because, further now, you said: >>What SHOULD happen is that the local DC should realize, hey this password isn't correct and will do what is called a PDC Chaining to ask the PDC what if the password specified is in fact ok [3] This is the way it works, I agree here. Now, you also said: >>Assuming the PDC is available to that site, you should be able to change a password anywhere on any DC and that password will get back to the DC. This, too, is correct. However the problem is the time it takes for the password change to get back to the PDCE and then onward to the rest of the DC. Where neither the HelpDesk (wo reset the password) no the User (whose password was reset) is in the site where the PDCE is located, the length of time it takes for the password change to travel across the wire is usually unacceptble. This is the reason one wuld want to reset the password at a DC local to the User. This is also one of the reasonss for ALToos, especially the AcctInfo.dll part. Theoretically, there should be no need for these tools, but in reality, chaining did not work as designed. One DC would lock out a user's account, after the user's password had been reset on another DC, before the locking out DC learns about the reset. Lastly, I have come across canned recommendations from "security consultants" telling clients to enable AvoidPDConWAN registry key. I am sure some companies would have heeded that recommendation. Sincerely,
Dèjì Akómöláfé, MCSE MCSA MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon ________________________________ From: [EMAIL PROTECTED] on behalf of joe Sent: Wed 4/28/2004 4:47 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Replication issues 1. What do you think your replication latency is supposed to be based upon your knowledge of your topology and your link configurations? This isn't something you have to guess at. Look at your DC placement and your replication topology and it will tell you the exact theoretical max replication period you have. 2. What do you want it to be? 30-60 minutes would be a time frame for replication that means you changed the default link settings. The default it 180 minutes per link (hop). This can be reduced to as low as 15 minutes without change notification and if you enable change notification it can go down to seconds (based on how busy the bridge heads between the sites are). As a rule, people don't generally set up change notification across a WAN [1]. 30-60 minutes could mean that you have 2-4 hops to get to the site with 15 minute delays or it could be you have 1-2 hops with 30 minute delays or it could be 1-2 hops with 15 minute delays with lots of DCs in each site and it taking 15 minutes to get to the proper outgoing bridgehead for each site. Lots of valid reasons for the timing, you need to understand what your theretical maxes could be and then decide if you are outside of that. If outside of that the first thing I would do is look at my DRA Pending Queue on my servers in the replication path to make sure it was zeroing out every replication period. [2] One thing I saw below I wanted to speak about... The out of band password force back to the PDC has been in W2K since RTM at least. It will get that password back immediately unless the PDC is really busy or otherwise unavailable (down, net down, PacMan on the ethernet line eating all of the packets, etc). Now after all of this I will say you should NOT have to worry about changing passwords at the specific site. Assuming the PDC is available to that site, you should be able to change a password anywhere on any DC and that password will get back to the DC. Then the client should be able to log on ANYWHERE. What SHOULD happen is that the local DC should realize, hey this password isn't correct and will do what is called a PDC Chaining to ask the PDC what if the password specified is in fact ok [3]. Assuming the password is ok, the PDC will say, that is fine and let the user log on. This functionality has been in Windows all the way back in NT. Without it, life in large companies would be miserable. Now there has been change in the functionality since 2K RTM to fix what I consider a design flaw / bug in this process. I can't recall when that exactly went in for 2K (SP3?) but was in K3 RC1; I have written previously about this fix on this list. Basically the issue was if the user needed to change the password on the next logon and the PDC chaining event occurred, the logon would succeed and client would be told to display the change password dialogue. The user would respond and use the "old password" of the password they just used to logon. Since that password wasn't yet at the local DC that was handling this change password request the local DC would say that the old password was incorrect and reject the change. I have already speculated in previous posts to this list about what was happening. Basically it was fixed by sending back key information to the remote DC during a PDC Chaining operation that brought that DC up to date for some critical authentication information so that it did indeed have the latest password information for that user. So all of that to say, that unless you have horrendous network connectivity, you should not have to set passwords on specific DCs if you are up to the current patch levels of Windows 2000 or on Windows 2003 for your domain controllers. joe [1] There are exceptions here so I am not looking for people to email say, we are and here'e why... There are a couple of special cases where I do it as well - to keep exchange in a good mood. The exceptions make the rule and show the beauty of the flexibility of the system. [2] Keep in mind there was a bug in a hotfix or two between SP2-3 that caused this queue to not have good values. It would increment sometimes and exit without remembering to decrement. Very unusual as it will look almost like you queue isn't clearing. In this case, you can pull out repadmin /queue or my adqueueloop to look at the actual queue and verify what it is doing. This is fixed in SP4 and actually one of the 4 new hotfixes that just came out also corrects it (obviously the bin with that code was replaced in one of the fixes and it has all of the previous fixes in it as well). So if you are at the minimum you should be for these last three crits, your counters should be working ok. [3] The DCs realize that they may not have the latest password and go ask the "master" for verification. This is one of the "big" functions of the PDC, being "master" of the passwords. It may not have the current right password, but it is final arbiter on whether or not a certain password can be used if another DC isn't sure. ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Tuesday, April 27, 2004 10:46 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Replication issues It's strictly a judgment call. You decide how important it is to have password changes replicate *now* and then weigh that against the costs of having very low replication latency. Costs might include available bandwidth, other applications using the same network, etc... In general, I'd stay away from letting this be the driving factor in determining your replication schedule. Change the password in the user's site, and 99% of the time the user should be fine within 15 minutes (default intrasite maximum replication period if you have 5 or more DCs in the site) or less. ________________________________ From: Rimmerman, Russ [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 7:40 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Replication issues What does changing the replication schedules explicitly for password resets entail, and is it recommended? ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Tuesday, April 27, 2004 8:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Replication issues Unless you want to start changing your replication schedules explicitly for password resets, you're doing the right thing. Change the password on a DC in the user's site. If you're at SP4 (I think, could have been SP3) then the password change will also get sent on to the PDC emulator immediately. Anytime a user enters an incorrect password, the local DC will pass on the request to the PDCE in case the password had changed on a different DC. The Account Lockout Status tool is probably the best utility for checking on password replication. Among other things, it will show the timestamp for password last set on each domain controller, so you can have a good idea of the replication state on the change. http://www.microsoft.com/downloads/details.aspx?FamilyID=d1a5ed1d-cd55-4829-a 189-99515b0e90f7&DisplayLang=en (watch for URL wrap) Hunter ________________________________ From: Rimmerman, Russ [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 27, 2004 7:07 AM To: '[EMAIL PROTECTED]' Subject: [ActiveDir] Replication issues We have always been having weird issues with replication. We have about 30 AD sites all over the world. When we change or reset a password here for a user at a remote site, it takes quite a long time (30-60 minutes or more) to replicate to the users site. So, we are having to connect to their local domain contoller and reset the password there. What is the best practice for setting up and tuning replication and resetting passwords, and what tools are recommended (replmon?) for "testing" it, and how long should it take? 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/
