Re: AD intersite replication lag - security problem?

From: Tim Hines, MCSE [MVP] (nupe009@carolina.rr.com)
Date: 01/11/03 

From: "Tim Hines, MCSE [MVP]" <nupe009@carolina.rr.com>
Date: Sat, 11 Jan 2003 00:12:36 GMT

Here's the low down. Read all of this

Change Notification Between Sites
By default, changes are replicated between sites according to a schedule and
not according to when changes occur. For this reason, the greatest
replication latency across the forest is the sum of the greatest replication
latencies along the single longest replication path of any directory
partition.

For special circumstances, you can configure change notifications on
connections between sites. By modifying the site link object, you can enable
change notification between sites for all connections that occur over that
link. Use ADSI Edit to enable change notification between sites.

To enable change notification between sites

  1.. In ADSI Edit, expand the Configuration container.
  2.. Navigate to the Inter-Site Transports container, and select CN=IP.
(You cannot enable change notification for SMTP links.)
  3.. Right-click the site link object for the sites for which you want to
enable change notification, and then click Properties.
  4.. In the Select a property to view box, select options.
  5.. In the Edit Attribute box, if the Value(s) box shows <not set>, type 1
in the Edit Attribute box. If the Value(s) box contains a value, you must
derive the new value by using a Boolean BITWISE-OR calculation on the old
value, as follows: old_value BITWISE-OR 1. For example, if the value in the
Value(s) box is 2, calculate 0010 OR 0001 to equal 0011. Type the integer
value of the result in the Edit Attribute box; for this example, the value
is 3.
  6.. Click OK.
Enabling change notifications across site links propagates all change
notifications. With change notification between sites set, changes propagate
to the remote site with the same frequency that they are propagated within
the source site, including changes that warrant urgent replication.

Note Do not enable change notification on demand-dial IP site links or on
SMTP site links.

Urgent Replication
Urgent replication is implemented by immediately notifying replication
partners over RPC/IP that changes have occurred on a source domain
controller. Urgent replication uses regular change notification between
destination and source domain controller pairs that otherwise use change
notification, but notification is sent immediately in response to urgent
events instead of waiting the default period of five minutes. Therefore, if
you have change notification enabled on a site link, urgent replication is
possible between sites for events that trigger it.

Events That Trigger Urgent Replication
Urgent Active Directory replication is always triggered by certain events on
all domain controllers within the same site. When you have enabled change
notification between sites, these triggering events also replicate
immediately between sites.

Immediate replication between Windows 2000-based domain controllers in the
same site is prompted by the following:

  a.. Assigning an account lockout, which prohibits a user from logging on
after a certain number of failed attempts.
  b.. Changing a Local Security Authority (LSA) secret, which is a secure
form in which private data is stored by the LSA.
  c.. Change in the relative identifier (known as a "RID") master role
owner, which is the single domain controller in a domain that assigns
relative identifiers to all domain controllers in that domain.
Urgent Replication of Account Lockout Changes
Account lockout is a security feature that sets a limit on the number of
failed authentication attempts that are allowed before the account is
"locked out" from a further attempt to log on, in addition to a time limit
for how long the lockout is in effect.

In Windows 2000, account lockout is urgently replicated to the primary
domain controller (PDC) emulator role owner and is then urgently replicated
to the following:

  a.. Domain controllers in the same domain that are located in the same
site as the PDC emulator.
  b.. Domain controllers in the same domain that are located in the same
site as the domain controller that handled the account lockout.
  c.. Domain controllers in the same domain that are located in sites that
have been configured to allow change notification between sites (and,
therefore, urgent replication) with the site that contains the PDC emulator
or with the site where the account lockout was handled. These sites include
any site that is included in the same site link as the site that contains
the PDC emulator or in the same site link as the site that contains the
domain controller that handled the account lockout.
In addition, when authentication fails at a domain controller other than the
PDC emulator, the authentication is retried at the PDC emulator. For this
reason, the PDC emulator locks the account before the domain controller that
handled the failed-password attempt if the bad-password-attempt threshold is
reached. For more information about how the PDC emulator role owner manages
password changes and account lockouts, see "Managing Flexible Single-Master
Operations" in this book.

Managing Urgent Replication
The following guidelines can be useful when deciding whether to enable
change notification between sites relative to achieving urgent replication.

  a.. If you want urgent replication everywhere, put all domain controllers
for the specific domain in a single site (this option might not be
realistic).
  b.. If you want urgent replication everywhere but still want the benefits
of site affinity, use multiple sites and enable change notification on all
site links.
  c.. By default, a user lockout prompts urgent replication at the site that
contains the domain controller that handled the authentication and the site
that contains the PDC emulator role owner.
Forced Replication Between Two Servers
You can use a connection object to force replication from the inbound
server. In Active Directory Sites and Services, right-click a connection
object, and then click Replicate Now. For information about how to force
replication between two servers by using a connection object, see Windows
2000 Server Help. For more information about forcing replication by using
other tools, see "Active Directory Diagnostics, Troubleshooting, and
Recovery" in this book. 

--
Tim Hines, MCSA, MCSE (2000 & NT4)
MVP - Active Directory
"Kev" <this-doesnt-exist@any-mailserver.com> wrote in message
news:#NzoA0MuCHA.432@TK2MSFTNGP10...
> Yesterday I discovered something that worries me.  Here's the scenario:
>
> User JDOE was terminated from my company (let's say) ACME Corp.
> This user worked in one of ACME's offices overseas.  This office is part
of
> the Active Directory Site 'B'.
> JDOE's account was disabled on a domain controller that also resides in
Site
> 'B'.
> Site 'A' has a VPN Server, and a domain controller.  Site 'A' and Site 'B'
> use the DEFAULTIPSITELINK for replication.
> Now here's the kicker.  The disabled user was still able to log onto the
> network at Site 'A' using VPN and had normal access to everything for a
> period of 3 hours!
> I realize that the replication interval for DEFAULTIPSITELINK is 180
> minutes, but I assumed (wrongly)that an event such as disabling a user
would
> trigger a replication.
>
> Am I overlooking something?  I don't think that I should have to force
> replication between all of my sites after an employee is terminated.  I
also
> don't think that I should have to set the replication interval to such a
> small amount that it will possibly clog up the link.  Any insights on this
> will be appreciated.
>
> Thanks,
> Kev
>
>

Relevant Pages

  • Re: Replication of password resets/unlocks
    ... First off, I know it isn't your fault, but the name urgent replication implies something that it isn't guaranteed to be. ... So if you hit a bridgehead that is backed up with inbound replication requests, even though the request was urgently queued, it can take awhile for that information to get into the bridgehead and then replicated back out. ... Urgent replication is implemented immediately by using RPC/IP to notify replication partners that changes have occurred on a source domain controller. ... In Active Directory domains, a single domain controller in each domain holds the role of PDC emulator, which simulates the behavior of a Windows NT version 3.x-based or Windows NT 4.0-based PDC. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Replication of password resets/unlocks
    ... Certain important events trigger replication immediately, ... Urgent replication is implemented immediately ... a source domain controller. ... The PDC emulator receives urgent replication of account lockouts. ...
    (microsoft.public.windows.server.active_directory)
  • Re: AD intersite replication lag - security problem?
    ... > Note that some recent hot fixes change the urgent replication items. ... >> change notification between sites for all connections that occur over ... >> destination and source domain controller pairs that otherwise use change ...
    (microsoft.public.win2000.security)
  • Re: AD intersite replication lag - security problem?
    ... Note that some recent hot fixes change the urgent replication items. ... > change notification between sites for all connections that occur over that ... > destination and source domain controller pairs that otherwise use change ...
    (microsoft.public.win2000.security)
  • Re: Force inter-site replication of urgent AD updates?
    ... Urgent replication is implented as a flag governed by regular old ... Look for "To enable change notification between sites" ... > site connector that is specific to urgent updates? ...
    (microsoft.public.windows.server.active_directory)