Hi folks,
Seems like thank you notes are in order all around:
Dave, for the kind words. :-)
Dean, for the update regarding Windows 2003, and in particular the fact
that it can replicate 'cleared intruder lockout' urgently.
Dèjì, for the pointer to acctinfo.dll, which lets administrators reset a
user's password and clear lockout on the user's home site, rather than
centrally.
Two more short notes:
1) acctinfo.dll is very good at what it does: letting an administrator
reset a user's password and clear lockouts on the user's home site.
If the user interface is not MMC, or there is a self-service
UI involved, or there is need to clear the lockout on multiple
DCs, rather than just on the home site, then acctinfo.dll is not
quite enough.
2) While looking for more details about acctinfo.dll, I ran across
this helpful presentation, and would recommend it as follow-on
reading for anyone interested in the topic of lockouts and
passwords in AD:
support.microsoft.com/servicedesks/ webcasts/en/wc022703/WC022703.ppt
Cheers,
- Idan
On Mon, 4 Aug 2003, Fugleberg, David A wrote:
> Thanks for the post, Idan. When I started this thread in the first place, I had
> absolutely no intention of knocking your product, so if anybody got a bad impression
> of it because of this thread, I sincerely apologize. In fact, that's why I didn't
> mention the product or vendor in the post - but I guess the cat is out of the bag,
> probably because you're the only vendor that even seems to recognize that there's an
> issue with AD replication in specific environments that needs to be addressed to
> make such a password management solution truly useful.
>
> My intent in posting the question in the first place (sans specific vendor/product
> info) was to learn from this community what their experience has been with such
> simultaneous changes in AD. I suspect that even some organizations without P-Synch
> have tried similar things on their own through scripting or other means...I know
> that a similar scheme was suggested here long before we heard about P-Synch. Our
> environment is pretty much exactly what you described in your post.
>
> Good point that there's no 'free lunch', and that the advantages come with the price
> of some additional replication. I was just trying to quantify that tradeoff a bit.
> I knew that with all the experts on this list I could get some good, objective
> viewpoints to help me with that.
>
> Again, thanks for your informative post - I've been most impressed with the quality
> of the technical support at M-Tech, and your post is a good example.
>
> Oh, one more thing - Deji asked why anybody would need more that acctinfo.dll - my
> answer would be that P-Synch does way more than manage AD passwords; it can manage
> passwords across many platforms, provide self-service resets, etc. Since one of its
> targets happens to be AD, it has all kinds of configurable features to work well in
> different AD scenarios. One of those optional features is the ability to figure out
> where the user is and target their local DC. The person doing the change is using a
> browser at that point, so acctinfo.dll does them no good.
>
> Dave
>
> -----Original Message-----
> From: Dummy account for mailing lists [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 03, 2003 7:48 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs
>
>
> Hi guys,
>
> At the risk of getting a bit flamed, let me wade into this. :-)
>
> I work for the vendor that makes this software (P-Synch from M-Tech), and
> I think a bit of clarification would be helpful:
>
> * The problem we address with the facility than supports writing a
> new password to multiple DCs is slow replication of the transition
> of the intruder lockout attribute on AD user objects from the locked
> to the unlocked state. The following scenario is the one and only
> situation in which we would suggest to a customer to write password
> updates to more than one DC at a time:
>
> - There is a large, distributed AD domain (one production example is
> 400 DCs spread over 70 countries).
>
> - Users throughout the distributed domain access either a central
> help desk or a central password-reset web application to reset
> forgotten passwords, and in particular to clear intruder lockouts.
>
> - The central server or help desk facility by default sets paswords
> and clears lockouts on a central DC (typically not the FSMO).
>
> - Users must subsequently and immediately access resources from
> DCs other than the one where the password reset / intruder unlock
> happened.
>
> - The AD domain runs Windows 2000 (slow replication of intruder
> unlocks was supposedly fixed for 2003, but I haven't verified
> yet).
>
> * If any of these is false for your organization - don't write
> password updates / intruder unlocks to multiple DCs. There *will* be
> extra replication traffic, and you should not introduce that without
> good reason. Our product certainly doesn't write to multiple DCs
> by default -- you have to explicitly configure it to do that.
>
> * If every one of these conditions is true for you, then depending on
> where your users are, your network infrastructure, bandwidth, latency,
> replication schedule, etc., you may be getting complaints from the IT
> support organization that an intruder unlock made by the central help
> desk or web GUI can take hours to effectively reach every resource
> the user needs to access.
>
> This is pretty awful user service, and short of Windows 2003, Microsoft
> tells us that there is no automated fix planned for this.
>
> * If you're still reading, you're either just curious or you have this
> problem in your organization. With our software (http://psynch.com/),
> you can make password updates, combined with clearing intruder
> lockouts, on a few select DCs at a time. We have site-aware logic,
> plus some manually-defined rules to figure out which DCs to touch
> for a given user at run-time. In practice, we'll touch from 2 to 5.
>
> We don't, and you should never, reset a user's password on every DC
> in the domain. A handful of DCs, judiciously selected based on the
> user's current IP address, the IP of the user's home directory
> hosting server, and DCs near resources like mail and web servers the
> user is likely to sign into are more than enough.
>
> * When we reset passwords / clear lockouts for a user on multiple DCs,
> that user gets "back in business" immediately, rather than waiting
> for AD replication of the cleared intruder lockout attribute. This
> is a big deal to affected users, and to global IT support groups.
>
> * Faster user service comes at the cost of some extra replication
> packets. There is no free lunch, unfortunately.
>
> * Total replication traffic is not very large, and the FSMO is not
> slammed. This is because DCs are smart enough to not replicate
> attribute changes where the final value is the same as the initial
> value. We only know the latter from empirical evidence, but we do
> have this in production at some very large global enterprises, and
> they are quite happy with this (admittedly aggressive) strategy.
>
> So the bottom line from this long message is:
>
> * Never write to multiple DCs unless you have a compelling reason to.
>
> * Such reasons do exist, but are not the norm.
>
> * The impact of doing this is quite manageable, but should be
> considered carefully.
>
> I hope this helps!
>
> Cheers,
>
> -- Idan
>
> On Fri, 1 Aug 2003, Rick Kingslan wrote:
>
> > Yep - I won't disagree on the PDCE needing to be in good health and quite
> > ready for some reasonable update traffic - local or cross-site.
> >
> > Rick Kingslan MCSE, MCSA, MCT
> > Microsoft MVP - Active Directory
> > Associate Expert
> > Expert Zone - www.microsoft.com/windowsxp/expertzone
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
> > Sent: Friday, August 01, 2003 8:50 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs
> >
> > I'm starting to see where you're coming from - in the end, its still a bad
> > idea, at least from a replication standpoint.
> >
> > At the very least, you'll get n-1 DC's worth of updates to the PDCE - as I
> > said, I'd hate to be the PDCE in that envrionment....
> >
> > --------------------------------------------------------------
> > Roger D. Seielstad - MTS MCSE MS-MVP
> > Sr. Systems Administrator
> > Inovis Inc.
> >
> >
> > > -----Original Message-----
> > > From: Rick Kingslan [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, August 01, 2003 9:20 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs
> > >
> > >
> > > Roger,
> > >
> > > If each DC is connected to a given DC, and the topology is laid out
> > > even remotely properly, the max hops that a replication are going to
> > > take is 3.
> > > The connected partners are going to replicate, and then the event is
> > > going to be done. There is not going to any need to replicate changes
> > > to a DC that already has seen it - as the USNs should certainly
> > > accommodate, and prevent.
> > >
> > > Consider this from Q225511:
> > > ------------
> > > By default, machine account password and user password changes are
> > > sent immediately to the PDC FSMO. In a mixed-mode domain, if a
> > > Microsoft Windows NT 4.0 domain controller receives the request, the
> > > client is sent to the PDC FSMO role owner (which must be a Windows
> > > 2000-based computer) to make the password change. This change is then
> > > replicated to other Windows 2000 domain controllers using Active
> > > Directory replication, and to down-level domain controllers through
> > > the down-level replication process. If a Windows 2000 domain
> > > controller receives the request (either in mixed or native mode), the
> > > password change is made locally, sent immediately to the PDC FSMO role
> > > owner using the Netlogon service in the form of a Remote Procedure
> > > Call (RPC), and the password change is then replicated to its partners
> > > using the Active Directory replication process. Down-level domain
> > > controllers replicate the change directly from the PDC FSMO role
> > > owner.
> > >
> > > If the AvoidPdcOnWan value is set to TRUE and the PDC FSMO is located
> > > at another site, the password change is not sent immediately to the
> > > PDC.
> > > However, it is notified of the change through normal Active Directory
> > > replication, which in turn replicates it to down-level domain
> > > controllers (if the domain is in mixed mode). If the PDC FSMO is at
> > > the same site, the AvoidPdcOnWan value is disregarded and the password
> > > change is immediately communicated to the PDC.
> > >
> > > -----------
> > >
> > > The default clearly states that the local DC receives the change, and
> > > then the PDC-E is immediately notified via RPC - Not normal
> > > replication. Then, the PDC-E changes the rest of the DC's via the
> > > normal replication cycle.
> > > This will, in effect, reduce the overall impact of replication to some
> > > degree, but again, to directly connected partners (max of three hops).
> > >
> > > Now, if AvoidPdcOnWan is modified to be TRUE, then normal replication
> > > is the mechanism of change, but from the site DC if the PDCE is not in
> > > the same site. But, it's still going to be a max of three hop
> > > replication to directly connected partners.
> > >
> > > In now way am I saying that each DC doesn't need the update - they do.
> > > I just suggest that it would not necessarily be a storm of updates.
> > > In a 10 DC structure, the local is going to be changed. The PDCE is
> > > going to be notified and is going to change itself with a call via RPC
> > > from the changed local DC - not replication. The PDCE is then going
> > > to send change notification to it's directly connected partners, which
> > > could be done, theoretically, in two replication notices from the
> > > PDCE, with two other DCs being responsible for two partners. Each of
> > > the others would only have one.
> > > In 3 hops maximum, you would have all 10 DC changed - 2 of those
> > > almost immediately and not participating in replication at all.
> > >
> > > Rick Kingslan MCSE, MCSA, MCT
> > > Microsoft MVP - Active Directory
> > > Associate Expert
> > > Expert Zone - www.microsoft.com/windowsxp/expertzone
> > >
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger
> > > Seielstad
> > > Sent: Friday, August 01, 2003 6:04 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: [ActiveDir] Simultaneous password change on multiple DCs
> > >
> > > I guess I'm trying to figure out why replication would be limited to
> > > just the connected partners. Wouldn't the change on each DC cause the
> > > USN to be incremented for that DC's replica? In that case, every other
> > > DC would see it as a change which needs to be acquired during
> > > replication?
> > >
> > > I guess there would be some consolidation at the site bridgeheads, but
> > > even then, there should still be 1 change per DC being replicated to
> > > N-1 domain controllers.
> > >
> > > --------------------------------------------------------------
> > > Roger D. Seielstad - MTS MCSE MS-MVP
> > > Sr. Systems Administrator
> > > Inovis Inc.
> > >
> > >
> > > > -----Original Message-----
> > > > From: Rick Kingslan [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, July 31, 2003 10:10 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: RE: [ActiveDir] Simultaneous password change on
> > > multiple DCs
> > > >
> > > >
> > > > Roger,
> > > >
> > > > Apparently, I need to clarify what I meant. In relation to the
> > > > product that was proposed, the normal password replication would be
> > > > minimized to immediate connected partners - so, IMHO, this
> > > wouldn't be
> > > > a storm but a bit of a burst (squall???)
> > > >
> > > > Rick Kingslan MCSE, MCSA, MCT
> > > > Microsoft MVP - Active Directory
> > > > Associate Expert
> > > > Expert Zone - www.microsoft.com/windowsxp/expertzone
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of Roger
> > > > Seielstad
> > > > Sent: Thursday, July 31, 2003 5:59 AM
> > > > To: '[EMAIL PROTECTED]'
> > > > Subject: RE: [ActiveDir] Simultaneous password change on
> > > multiple DCs
> > > >
> > > > Actually, why would it be minimized? The password change is
> > > happening
> > > > on every domain controller, and as suck looks like a
> > > discreet change
> > > > to the PDCE - meaning its gonna kill the PDCE.
> > > >
> > > > --------------------------------------------------------------
> > > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator
> > > > Inovis Inc.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Rick Kingslan [mailto:[EMAIL PROTECTED]
> > > > > Sent: Wednesday, July 30, 2003 10:12 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: RE: [ActiveDir] Simultaneous password change on
> > > > multiple DCs
> > > > >
> > > > >
> > > > > Gil,
> > > > >
> > > > > > Making the same change on multiple DCs is bone-headed
> > > > > As anyone who has had to clean up or troubleshoot the
> > > appearance of
> > > > > CNF:
> > > > > objects can attest to....
> > > > >
> > > > > And, yes - I concur that the password changes are all
> > > > propagated via
> > > > > the PDCE and the replication traffic would be minimized
> > > because of
> > > > > such.
> > > > >
> > > > > Rick Kingslan MCSE, MCSA, MCT
> > > > > Microsoft MVP - Active Directory
> > > > > Associate Expert
> > > > > Expert Zone - www.microsoft.com/windowsxp/expertzone
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Gil
> > > > > Kirkpatrick
> > > > > Sent: Wednesday, July 30, 2003 8:43 PM
> > > > > To: '[EMAIL PROTECTED]'
> > > > > Subject: RE: [ActiveDir] Simultaneous password change on
> > > > multiple DCs
> > > > >
> > > > > Making the same change on multiple DCs is bone-headed,
> > > but I don't
> > > > > think it will generate much additional replication traffic.
> > > > Aren't the
> > > > > password changes forwarded to the PDC FSMO role owner for
> > > > the domain
> > > > > and then replicated from there? If that's true, then the
> > > redundant
> > > > > changes coming into the PDCE should be dropped (generally,
> > > > changing an
> > > > > attribute to its current value has no effect). So the additional
> > > > > password changes will each generate a message to the PDCE, but
> > > > > otherwise not much else.
> > > > >
> > > > > Or am I missing something?
> > > > >
> > > > > -gil
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Roger Seielstad [mailto:[EMAIL PROTECTED]
> > > > > Sent: Wednesday, July 30, 2003 1:22 PM
> > > > > To: '[EMAIL PROTECTED]'
> > > > > Subject: RE: [ActiveDir] Simultaneous password change on
> > > > multiple DCs
> > > > >
> > > > >
> > > > > That strikes me as a way to cause replication storms in a flash,
> > > > > depending on how the application is written. Say you have
> > > > 10 DC's, and
> > > > > this app changes the password on all 10 dc's. That's at least 81
> > > > > different replication messages, since each DC will
> > > > recongnize that as
> > > > > a different change.
> > > > >
> > > > > Seems to me to be both overkill and unnecessary.
> > > > >
> > > > > --------------------------------------------------------------
> > > > > Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator
> > > > > Inovis Inc.
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Fugleberg, David A [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Wednesday, July 30, 2003 3:23 PM
> > > > > > To: [EMAIL PROTECTED]
> > > > > > Subject: [ActiveDir] Simultaneous password change on
> > > multiple DCs
> > > > > >
> > > > > >
> > > > > > We're looking at a product to manage passwords - it
> > > > enforces common
> > > > > > password policy and keeps passwords in sync across multiple
> > > > > > platforms (mainframe, AD, NDS, Unix, etc.), as well as provides
> > > > > > self-service password change/reset via a browser interface.
> > > > > >
> > > > > > One of its features on AD is that it's nominally
> > > > site-aware - it can
> > > > > > determine a browser's location based on IP address and
> > > > change the AD
> > > > > > password on a DC in that site. So far, so good. Now
> > > the tricky
> > > > > > part - it can also be configured to ALWAYS change the
> > > password on
> > > > > > one or more DCs that you specify on the config, in
> > > > addition to the
> > > > > > one it selects.
> > > > > > The idea is to specify DCs near resources at headquarters that
> > > > > > people access from branch offices. This is supposed to
> > > > ensure that
> > > > > > people can access the resources immediately rather than
> > > > waiting for
> > > > > > the new password to replicate.
> > > > > >
> > > > > > Net result is that the same password change is applied
> > > > directly at
> > > > > > multiple DCs in different sites at the same time.
> > > > > > My question is, what is the impact on the DCs and replication
> > > > > > traffic ? What are the caveats of such a scenario ?
> > > > > >
> > > > > > One other thing - the helpdesk can use the web interface
> > > > to assist
> > > > > > callers who choose not to use self-service. In that case, the
> > > > > > helpdesk can see a list of all DCs and select the
> > > > > > one(s) they wish to send the change to. This can be
> > > > disabled, but
> > > > > > is the default if you enable 'site-awareness'.
> > > > > > This bothers me a bit, since there's nothing to prevent a
> > > > helpdesk
> > > > > > person from selecting 'em all. Your thoughts ?
> > > > > >
> > > > > > Dave
> > > > > > 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/
> > > > >
> > > > 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/
> > >
> > 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/
>
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/
