Active Directory replication is not instantaneous. Intra-site replication is usually quite fast but changes on one Domain Controller may still take several minutes to be replicated to other Domain Controllers. Inter-site replication may be quite slow – an hour or more between replications is common.
Replication occurs when more than one Domain Controller exists in a domain.
2.4.1 Old Data Used After Attribute Modified
The time period between replications becomes a problem where information is changed on one Domain Controller (for example, a Digipass User's Server PIN is reset), but old information is used on another Domain Controller before the changed information has been replicated to it.
There are a few scenarios where this may occur. These are listed below:
2.4.1.1 Single IDENTIKEY Server using more than one Domain Controller
A single IDENTIKEY Server may make a change to a record, have to switch to another Domain Controller, and read the same record – where the change has not yet been applied.
Example
A User logs in with an OTP, and the IDENTIKEY Server connects to DC-01 to retrieve and update the Digipass data. The connection to the DC-01 fails soon after login, before replication has occurred. The User needs to log in again, and the IDENTIKEY Server connects to DC-02 this time. The User can log in using the same OTP as the last login – the login should fail (OTP replay) but instead succeeds, because DC-02 does not yet know that the OTP has been previously used.
Time DC-01 DC-02
8:32 Replication occurs
8:34 User logs in with OTP 10457920.
The IDENTIKEY Server records the use of the OTP in the Digipass record.
8:35 Connection to DC-01 is broken, and the IDENTIKEY Server switches to DC-02.
8:35 User retries login using same OTP
10457920. The login succeeds where it should have failed (OTP replay).
The IDENTIKEY Server records the use of the OTP in the Digipass record.
8:37 Replication occurs
Digipass record changes are replicated between DC-01 and DC-02.
The example timeline above shows the sequence of events.
The administrator may not be connected to the same Domain Controller (via the Administration Interfaces) as the IDENTIKEY Server.
Example
An administrator changes a User's Server PIN through the Active Directory Users and Computers extension, which is connected to DC-01. The IDENTIKEY Server connects to DC-03. The User attempts a login using the new PIN, which fails because DC-03 is not yet aware of the change of Server PIN.
Time DC-01 DC-03
9:02 Replication occurs
9:03 Administrator changes a User's Server PIN from 1234 to 9876.
9:04 User attempts to log in using new PIN (9876) and the
login fails.
9:05 Replication occurs
Digipass record changes are replicated between DC-01 and DC-03.
The example timeline above shows the sequence of events.
2.4.1.3 Multiple IDENTIKEY Servers Using Different Domain Controllers
Multiple IDENTIKEY Servers may connect to different Domain Controllers in a domain or site.
Example
A User changes their own PIN during a login through one IDENTIKEY Server which connects to DC-01. The server on which the IDENTIKEY Server is installed becomes unavailable, and the User attempts another login via the IDENTIKEY Server on a backup server, which connects to DC-02. The login fails because DC-02 is not yet aware of the change of Server PIN.
Time DC-01 DC-02
11:54 Replication occurs
11:55 User changes their Server PIN from 1234 to 9876 during login.
The IDENTIKEY Server records the PIN change in the Digipass record.
11:57 User attempts to log in using new PIN (9876) and the
login fails.
11:59 Replication occurs
Digipass record changes are replicated between DC-01 and DC-02.
The example timeline above shows the sequence of events.
2.4.1.4 Two Administrators Modifying the Same Attribute
Two administrators attempt to modify the same attribute on a single User account or Digipass record within the same replication interval. The later modification will overwrite the earlier when replication occurs.
2.4.2 Old Data Used Overwrites New Data
The problems above are exacerbated when the old information used on the second Domain Controller is updated based on the old information. As the updated record on the second Domain Controller now has a later modification date, the end result is that the changed information on the first Domain Controller is overwritten incorrectly.
Example
An administrator connects to DC-01 and sets a User's PIN from '1234' to '9876'. The User logs in through the IDENTIKEY Server, which connects to DC-02. The User enters the new Server PIN and his One Time Password. However, the PIN set on DC-01 has not yet been replicated to 02, so because the PIN entered does not match the old PIN still recorded in the Digipass record on DC-02, the login fails.
Because the Policy setting of Identification Threshold is in use, his login failure is written back to the Digipass record. When replication occurs, the Digipass record on DC-02 has the latest modification date – and is copied to DC-01, wiping out the original PIN setting made by the administrator. Both DC-01 and DC-02 now consider '1234' to be the correct Server PIN for the Digipass.
Time DC-01 DC-02
10:45 Replication
10:46 Administrator changes User's PIN from 9876 to 1234.
10:48 User login (with new PIN of 1234) fails.
IDENTIKEY Server writes failure information to Digipass record.
10:50 Replication
Active Directory finds last instance of the Digipass blob having been modified.
Active Directory overwrites DC-01 Digipass record with DC-02 Digipass record.
The example timeline above shows how the problem can occur.
The problem shown in the example above may also occur in a Force PIN Change set by an administrator.
2.4.3 Factors Affecting Replication Issues
A number of factors determine the likelihood and severity of the Active Directory issues described:
Redundancy and load-balancing settings for the IDENTIKEY Server
There are a number of IDENTIKEY Server configuration settings which may affect replication issues:
Preferred Server
The IDENTIKEY Server will attempt to connect to the named Domain Controller, rather than simply polling the domain for an available Domain Controller.
Preferred Server Only
setting. If this is enabled, the IDENTIKEY Server will not switch to any other Domain Controller, so it will never retrieve data older than its own.
Max. Bind Lifetime
The maximum bind lifetime controls how long the IDENTIKEY Server will stay connected to a Domain Controller before polling the domain for a Domain Controller connection.
Replication Interval
On Windows Server 2003 and Windows 2008, the intra-site replication interval is not configurable, but is set to approximately 15 seconds, as replication is much more efficient.
Inter-site replication is fully configurable on Windows Server 2003 and Windows 2008.
The longer the replication interval, the more likelihood of these problems occurring.
Number of Domain Controllers in the Site
Each Domain Controller regularly requires replication with all other local Domain Controllers. As this is done sequentially, it will affect the amount of time between replications.
2.4.4 Solutions and Mitigations
2.4.4.1 Digipass Cache
The Digipass cache collects Digipass records as they are modified, and keeps them in memory for a certain length of time. A newer entry from the cache is always used in preference to an older record from Active Directory. The cache age should be a little longer than the typical replication interval. The default is 10 minutes (600 seconds).
This option will help in problems caused by a single IDENTIKEY Server accessing more than one Domain Controller in a domain – see 2.4.1.1 Single IDENTIKEY Server using more than one Domain Controller . It will also assist in problems caused by having multiple Authentication Servers accessing more than one Domain Controller in a domain, if IDENTIKEY Server replication is enabled between the servers. However, it will not affect the scenario of an Administration Interface being connected to a different Domain Controller to the IDENTIKEY Server.
If you calculate that your typical replication interval will be more than ten minutes, the cache age may be increased by modifying the Blob-Cache Max-Age setting in the configuration file (<install dir>\bin\identikeyconfig.xml):
<Blob-Cache>
<Max-Age type="unsigned" data="600"/>
<Max-Size type="unsigned" data="0"/>
<Clean-Threshold type="unsigned" data="10"/>
<Min-Clean-Interval type="unsigned" data="60"/>
</Blob-Cache>
A large cache may slow down processing slightly for the IDENTIKEY Server, so monitor performance to check the impact caused after modifying the cache age.
Warning
If the IDENTIKEY Server is installed on a Member Server, this server must be closely time-synchronized with the Domain Controller(s). If the server is not time-time-synchronized, the Policy may select an older record when comparing records in the Digipass cache with those on the Domain Controller.
If the IDENTIKEY Server is installed on a Domain Controller, time-synchronization is assumed.